Alexey Osipov

Естественно. Сейчас этот 'calling number' никак не учитывается при авторизации. Дописывать надобно. По образу и подобию ipparam.

а что если не мак? =) Там произвольная строка. Например, это может быть номер телефона, ip-адрес или вовсе пустая строка. В твоем случае MAC подставляет туда PPPoE сервер, которым ты пользуешься. Сменишь сервер - строка может содержать что-то другое или отсутствовать вовсе.

Поглядел. Возможно. Там, кстати, не обязательно MAC будет. Зависит от канального уровня, что там будет.

Совсем по-хорошему, надо таки реализовать мою давнюю хотелку в самом stg - чтобы можно было настраивать список параметров, передаваемых в OnConnect/OnDisconnect.

Так может тогда именно такую опцию и завести? Чтобы для номера интерфейса брался последний (предпоследний) октет IP-адреса. Интересно, есть ли ограничение на номер интерфейса?

Нет, отнюдь не сложная. Просто пытаюсь понять use case'ы для неё. Типа, среди всех пользователей есть некоторые (и их немного), которых хотелось бы посадить на отдельный интерфейс с определенным номером, чтобы... зачем?

А смысл тогда в привязке, если все-равно будет вероятность, что пользователь получит произвольный номер интерфейса?

Каждый раз обновляется. Теоретически можно. Но нужно, например, определиться, что делать, если пользователю назначен интерфейс, который уже занят другим пользователем?

Я для этого использую опцию purestg2 'pppunitsave'. А в OnConnect через sgconf добываю сохраненное значение. Насколько это эффективно не берусь судить, т. к. у меня клиентская база очень маленькая.

По идее - да.

Да ну нет же! На лицо, что плагины в конфигах прописаны дважды.

Это радует. Тот таймаут, который в настройках purestg2 - это таймаут на случай, если вдруг по какой-то причине пропадет связь между pppd и старгейзером. И он не имеет ничего общего с тем таймаутом, который использует pppd для обнаружения "живучести" канала. Погляди man pppd, там вроде были какие-то настройки нужных тебе таймаутов.

Ну и вот. Всё дело в ip-up. Гляди что происходит: 1. Первое подключение происходит штатно и переименовывается в vpn_varej1. 2. Потом начинается второе подключение, создается новый ppp-интерфейс. 3. Вызывается ip-up для нового интерфейса, который делает ему ifconfig down, новый интерфейс становится не RUNNING. 4(!). ip-up пытается переименовать новый интерфейс в vpn_varej1, но не может этого сделать, т.к. старый интерфейс с таким именем всё ещё существует. 5. Соответственно ifconfig vpn_$LOGIN up ни к чему не приводит, т.к. это имя относится к старому интерфейсу. 6. А новый интерфейс так и остается в состоянии не RUNNING. Думаю, можно его включить банальным ifconfig pppX up. Грабли в том, что имеющийся ip-up некорректно работает в такой ситуации. Причем, он будет точно так же некорректно работать и без purestg2. Я в принципе думал, что в подобных случаях могут возникать проблемы - у меня даже TODO в коде написан на этот счет - дожидаться при активной kickprevious завершения работы старого pppd. Хотя в данном случае даже это бы не помогло. Но у меня, поскольку я не использую переименование интерфейсов и уж тем более не делаю им down, все работает хорошо. У меня есть идея, как это проблему можно решить со стороны purestg2, но она пока окончательно не оформилась.

Так судя по логам, оно и переподключается. И даже IP выдает. Со стороны purestg2 проблемы не вижу. Пока единственная проблема, замеченная в логах, - это то, что сам роутер просит разорвать вновь установленное соединение (Connection reset by peer (User request)). Почему он это делает - вопрос. В последних логах с выключенной kickprevious эта строчка для pppd[23710] есть? Давай ещё покопаем с другой стороны: ты говорил, что у тебя там в ip-up какая-то черная магия с переименованием интерфейсов происходит? Можно взглянуть на содержимое скриптов?

Кусочек лога старгейзера, который я просил выше, подтверждает сказанное выше. В последних логах проблема, которую я отметил выше жирным шрифтом, не видна: тут все вообще хорошо. Давай вернемся к началу: в чем конкретно проблема?

У меня есть одно предоположение: Получается так, что клиенту приходится в определнный интервал времени держать одновременно два PPPoE подключения к твоему серверу (когда он уже начал новую сессию, а старая ещё не закрылась окончательно). Потом, когда старая сессия закрывается, сервер шлет клиенту пакет PADT (видно в логах), этот пакет означает буквально "завершить сессию". Возможно, клиент при этом считает, что этот пакет относится к новой сессии, а не к старой. И, отреагировав на пакет, закрывает новую сессию.

Воооот. Вот это уже интереснее. Хотелось бы ещё увидеть лог старгейзера в момент: Mar 18 14:05:56 skyprox pppd[8349]: local IP address 10.0.0.253 Mar 18 14:05:56 skyprox pppd[8349]: remote IP address 10.168.5.5 Mar 18 14:05:56 skyprox pppd[6054]: purestg2: stargazer socket has just been closed. Terminating connection. Mar 18 14:05:56 skyprox pppd[6054]: Terminating on signal 15 Mar 18 14:05:56 skyprox pppd[6054]: purestg2: Can't disconnect user varej1 Mar 18 14:05:56 skyprox pppd[8349]: purestg2: User varej1 connected. Пока похоже на то, что в конфиге purestg2 включена опция kickprevious. Когда новый pppd[8349] пытаеся в стг подключить пользователя с новой сессии, purestg2 со стороны старгейзера сначала разрывает соединение со старым pppd[6054]: Mar 18 14:05:56 skyprox pppd[6054]: purestg2: stargazer socket has just been closed. Terminating connection. а потом авторизовывает пользователя с нового pppd: Mar 18 14:05:56 skyprox pppd[8349]: purestg2: User varej1 connected. Старый pppd[6054], увидев, что соединение со старгейзером закрылось, начинает медленно умирать (штатным образом): Mar 18 14:05:56 skyprox pppd[6054]: Terminating on signal 15 По пути, он пытается снять авторизацию со старого пользователя в старгейзере, но не может этого сделать: Mar 18 14:05:56 skyprox pppd[6054]: purestg2: Can't disconnect user varej1 Но это и логично, ведь соединение со старгейзером было закрыто самим старгейзером. А перед закрытием соеднения старгейзер сам снял авторизацию со старого пользователя. Через 6 секунд закрывается и старая PPPoE сессия: Mar 18 14:06:02 skyprox pppd[6054]: Exit. Mar 18 14:06:02 skyprox pppoe-server[1910]: Session 25 closed for client dc:9f:db:0a:ab:b6 (10.0.0.154) on eth_varej1 Mar 18 14:06:02 skyprox pppoe-server[1910]: Sent PADT А вот дальше (через 20 секунд) происходит интересное - новый pppd[8349] получает сигнал на завершение соединения. Но получает он его не от purestg2, а от пользователя(!): Mar 18 14:06:26 skyprox pppd[8349]: LCP terminated by peer (User request) Дальше всё происходит штатно, purestg2 видит, что новое соединение закрывается и отключает пользователя в старгейзере: Mar 18 14:06:26 skyprox pppd[8349]: purestg2: User varej1 disconnected. Mar 18 14:06:26 skyprox pppd[8349]: purestg2: Disconnected from stargazer. Ну и в конце концов новый pppd умирает и новая PPPoE сессия тоже закрывается: Mar 18 14:06:29 skyprox pppd[8349]: Exit. Mar 18 14:06:29 skyprox pppoe-server[1910]: Session 28 closed for client dc:9f:db:0a:ab:b6 (10.0.0.157) on eth_varej1 Mar 18 14:06:29 skyprox pppoe-server[1910]: Sent PADT Внимание вопрос: почему пользователь (роутер или кто у тебя там на том конце?) просит разорвать соединение?

Это те самые недозакрытые интерфейсы, у которых IP уровень уже отключен (поэтому он не RUNNING), а канальный уровень (PPPoE) ещё жив. Рассмотрим, например, Семёна: 0. pppd решает, что Семён более недоступен ("клиент не отвечает") и начинает процесс закрытия соединения: Mar 15 10:09:34 skyprox pppd[14325]: LCP terminated by peer (Peer not responding) 1. purestg2 получает сигнал от pppd, что случился auth_down, отключает пользователя semen от старгейзера и сам отключается от старгейзерного сокета: Mar 15 10:09:34 skyprox pppd[14325]: purestg2: User semen disconnected. Mar 15 10:09:34 skyprox pppd[14325]: purestg2: Disconnected from stargazer. 2. Семён пытается переподключится, открывая тем самым новую PPPoE сессию: Mar 15 10:09:35 skyprox pppoe-server[28081]: Session 55 created for client 00:27:22:e2:7c:62 (10.0.0.184) on eth_vlan51 using Service-Name '' 3. pppoe-server стартует новый pppd, который в свою очередь создает новый интерфейс и грузит плагин purestg2: Mar 15 10:09:35 skyprox pppd[28081]: Plugin purestg2.so loaded. Mar 15 10:09:35 skyprox pppd[28081]: Stargazer (purestg2 2.4) auth plugin initialized. 4. purestg2, проверив пароль, подключает пользователя semen в старгейзере: Mar 15 10:09:35 skyprox pppd[28081]: purestg2: User semen connected. 5. старый pppd наконец умирает, забирая за собой и старый интерфейс: Mar 15 10:09:37 skyprox pppd[14325]: Exit. 6. закрывается предыдущая PPPoE сессия Семёна: Mar 15 10:09:37 skyprox pppoe-server[1910]: Session 53 closed for client 00:27:22:e2:7c:62 (10.0.0.182) on eth_vlan51 Mar 15 10:09:37 skyprox pppoe-server[1910]: Sent PADT На шагах 0-1 пользователь semen в старгейзере online. На шагах 2-3 пользователь semen в старгейзере offline. На шагах 4-6 пользователь semen в старгейзере снова online. На шагах 3-5 существует одновременно две PPPoE сессии с Семёном (и, соответственно, два pppd), что и порождает эти "непонятные интерфейсы". Аналогичный процесс прослеживается и для остальных пользователей, которых видно в логе. Интерфейс "падает", потому что происходит разрыв соединения. Но "падает" он не сразу, а поэтапно. В биллинге пользователь отключается ещё до того, как туннель полностью закрыт, поэтому наличие этого недозакрытого интерфейса не препятствует биллингу авторизовать пользователя по новому туннелю.

В логе, впрочем, тоже все хорошо со стороны purestg2 - все запрошенные подключения обслужены и пользователи подключены. Отлупов из-за повисших туннелей не наблюдается. Да и сама ситуация, судя по логу, немного отличается от той, что я описал выше: здесь отключение пользователя со стороны purestg2 происходит четко до новой попытки его подключения: Mar 15 10:09:34 skyprox pppd[14325]: purestg2: User semen disconnected. Mar 15 10:09:35 skyprox pppd[28081]: purestg2: User semen connected.

Раньше кстати отключение пользователя в стг висело как-раз на ip_down, а не на link_down. Потом я переделал. Не помню, почему. Надо будет поглядеть по git логам.

Значит надо искать потерянный интерфейс. По логу видно, что клиент вполне себе авторизовался и пока жив. Ты лог с grep-ом приводишь. Может быть там в соседних строчках от других частей системы есть какие-то сообщения, которые могут пролить свет на просиходящее? Тут ещё какой момент есть. Подключение PPP-интефрейса происходит в несколько этапов, среди которых есть auth_up, ip_up, ip_down и link_down. В процессе подключения сначала происходит auth_up (когда пароль пользователя уже проверен, но IP адрес на интерфейс ещё не назначен), потом ip_up (когда на интерфейс назначен IP адрес и он полностью работоспособен). В процесс отключения сначала происходит ip_down (с интерфейса снимается IP адрес, но интерфейс всё ещё существует, PPPoE или PPtP уровень ещё функционирует), а затем происходит link_down (всё, канальный уровень тоже отключен). Так вот: purestg2 выполняет подключение абонента в stg в момент ip_up, а отключение - в момент link_down, то есть после полного закрытия туннеля. Есть вероятность, что при переподключении пользователя, старый туннель ещё не полностью закрыт (ip_down произошел, поэтому ты не видишь туннель в ifconfig, а link_down ещё не произошел, поэтому старгейзер все ещё считает клиента онлайн), а пользователь открывает новый туннель, который полностью конфигурируется, доходит до ip_up, purestg2 пытается авторизовать пользователя в старгейзере, но тот ещё онлайн (т.к. старый тунель ещё не полностью закрылся), и purestg2 отказывает в подключении. Попробуй в сложившейся ситуации поискать пропавший интерфейс не командой "ifconfig", а командой "ifconfig -a", она показывает даже несконфигурированные (нерабочие) интерфейсы.

Такое возможно только в случае, если на каком-то из этих IP ещё запущен inetaccess, который авторизовался совместно с purestg2. Просто наличие "доступного" IP не должно приводить к автоматической авторизации с него.

Лог приведен на момент до "пустил роутер абонента в перезагрузку" или после?

Нормальные логи. В 17:10:07 Семён подключился. В 18:00:29 pppd понимает, что Семён куда-то пропал (peer not responding) и начинает закрывать соединение. purestg2 в этом месте отрабатывает правильно, посылая сигнал старгейзеру отключить Семёна (purestg2: User semen disconnected), этот момент ещё можно проконтролировать логом самого старгейзера. Дальше, в 18:00:31, Семён подключается повторно, ему открывается новая pppoe сессия, стартует новый pppd[16821]. Опять же, судя по логам, purestg2 отрабатывает правильно и успешно подключает Семёна в старгейзере (purestg2: User semen connected). Это тоже можно проконтролировать логом старгейзера. Наконец, в 18:00:32, окончательно умирает старый pppd[16443]. Потенциальная грабля - то, что старый pppd окончательно умирает уже после установки нового соединения. Но я пока не могу придумать, почему это должно быть проблемой. Тем более, что purestg2 успевает сообщить старгейзеру об отключении старой сессии (в 18:00:29) ещё перед тем, как началась новая (в 18:00:31). Если бы он не успевал, то второе подключение бы не прошло и сообщения "pppd[16821]: purestg2: User semen connected." не было бы. В любом случае, в приведенных логах не видно ничего похожего на "в stg статус online, авторизоваться не может".

Это уже при включенной kickprevious? А можно лог подключения для pppd[16443]? А то здесь только его смерть. Вообще, похоже на то, что при (плановом) рестарте старгейзера не убиваются активные pppd-подключения. Погляди, если остановить биллинг, все ли пользовательские pppd завершают работу? Хотя с другой стороны, даже если это не так, то ничего страшного из этого не следует: после ручного разрыва соединения пользователем повторное подключение должно пройти штатно.