Roma (roma@kodeks.net) wrote:
: Anatoly A. Orehovsky wrote in message <7rog4e$eri@mpeks.tomsk.su>...
: >А вот использует ли кто user-level ppp глюкало для приема диалапщиков ?
: >Вкупе с PAP ? Нравятся ли вам постоянные залипания таймеров внутре сией
: >хитрой проги ?
: Вот я пытлся-пытался и плюнул в конце концов на это шило...
: >Если не нравятся - могу подсказать, как это очень легко побороть.
: >Кстати, оно у меня еще умеет и (почти) полный AAA TACACS+ для PAP.
: >И вышивать крестиком 8-))).
: Подскажи, у меня сейчас интерес чисто спортивный уже, но тем не менее...
: особенно про крестик интересно :)
Тогда сперва несколько сопутствующих слов о ppp. Все-таки, за примерно два
года активного юзания этой программки на сервере вместо pppd я, наверное,
дня два-три в общей сложности убил на копание в ней.
Ну так вот, программа сама по себе теоретически написана хорошо. Уровневая
структура, машина состояний, некое подобие объектов при работе, например, с
таймерами.
Однако, надо очень четко себе представлять внутрипрограммные пертурбации,
чтобы найти какой-нибудь мелкий глюк. Поскольку документировано все это дело
хуже некуда.
Как пример глюка - уже упоминавшееся залипание таймеров.
Как это выглядит ? Например (частный случай):
Настраиваемся на работу с PAP. Происходит вход по PPP/PAP и аутентификация не
проходит (например, клиент ошибся с паролем). Клиентская программа рвет
коннект. Серверный ppp продолжает спокойно висеть на порту - не отловил
падение CD.
А почему, спрашивается ?
А вот почему - ppp настраивает терминал в CLOCAL. Таким образом, если CD
пропадет, ppp не получит SIGHUP от системы. Поэтому, чтобы отловить все же
падение CD, ppp вынужден периодически самостоятельно с помощью ioctl(2)
проверять состояние порта.
И ведь отлавливает почти всегда ! Так почему же в данном случае этого не
происходит ?
Возможно, ppp перестает проверять CD ? Правильно.
Но почему ? А потому, что проверка организована периодически через систему
таймеров ppp (кстати, весьма хорошую систему), которую ppp ухитряется
остановить.
Как реализована система таймеров ? Примерно так: если какая-то из подсистем
ppp нуждается в некотором таймере, по истечению которого эта подсистема
хочет асинхронно произвести некоторое действие, ей (подсистеме) следует
зарегистрировать свой таймер в нужных инстанциях. После этого система
таймеров оптимальным образом мониторит все зарегистрированные таймеры и, как
только какой-нибудь из них протухнет, вызывает соответственное действие.
Действие в процессе своей работы может опять взвести таймер. И так до
бесконечности.
Когда происходит залипание, просмотр таймеров с помощью show timers выдает,
что таймеры в порядке, на взводе, но - они не идут, что можно увидеть
последовательными командами show timers.
Что значит "не идут" ? Их счетчики не изменяются. Изменения должны
происходить тогда, когда ppp получает SIGALRM, предварительно взведенный с
помощью setitimer(2).
Может быть, ppp блокирует SIGALRM ? Нет, если сказать kill -alrm процессу,
не поймавшему падение CD, ppp тут же его поймает и завершится.
Но ведь и таймеры взведены ? Да.
Так в чем же дело ? А в том, что система таймеров имеет специальную функцию
остановки тикания системного real-time таймера, который взводился до того с
помощью setitimer(2). То есть, в некоторых случаях ppp считает вредным
обращать внимание на таймеры,,,
Видимо, так оно и есть. Однако, места где это происходит я усиленно искать
не стал, а просто добавил одну строчку в систему таймеров. Теперь она
перезапускает real-time таймер каждый раз при очередной регистрации
подсистемного таймера.
А именно: в timer.c: timer_Start() вставил дополнительный вызов
timer_InitService(1) в районе строки:
/* Start the Timer Service */
Получилось:
if (pt) {
pt->next = tp;
timer_InitService(1); /* Restart the Timer Service */ <- вот !
} else {
TimerList = tp;
timer_InitService(0); /* Start the Timer Service */
}
После чего залипания прекратились.
Решение, пожалуй, не самое верное. Предположительно, в некоторых случаях
таймеры-кандидаты на протухание будут получать некоторое дополнительное
время жизни, чего не хотелось бы. Но зато - работает. И, внешне, правильно.
Теперь о "вышивании крестиком" :
ppp у меня еще умеет AAA TACACS+ для PAP входов (обычные login-входы через
TACACS+ обслуживает специальная login-программка). И только network-аккоунтинг
TACACS+ для любых своих запусков.
Что входит в AAA сейчас ? Ну, нормальная аутентификация PAP-юзеров,
совместимая и с tac+ia, и, например, с tac_plus 2.0. Выставление адреса
клиента через авторизацию (легко можно еще чего-нибудь добавить, например,
обработку timeout, благо, с таймерами разобрались). Ну и аккоунтинг по
bundle_Destroy. Аккоунтинг несколько урезан в связи с ненужностью таких
вещей, как packets_in, packets_out и т.п. Правильно выдается время поднятия
IPCP, количество октетов туда/оттуда для уровня IPCP, время между поднятием и
опусканием IPCP-уровня, ip-адрес клиента, его PAP-логин и временная зона.
Этого достаточно для наших задач.
Что еще из "крестиков" ? Да, в общем, ничего. Разве что, запрет на
мониторинг CD для -dedicated линков. Мне это оказалось нужным из-за
странного поведения то ли порта, то ли модема Zelax M-115.
Да, в общем, и вредным для -dedicated это дело не будет.
-- Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN http://www.tekmetrics.com/transcript.shtml?pid=6064 -- end of forwarded message --
-- С тем, что не помешает никогда, Kittle