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. А новый интерфейс так

Так судя по логам, оно и переподключается. И даже 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 включена опция kickp

Это те самые недозакрытые интерфейсы, у которых 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

В логе, впрочем, тоже все хорошо со стороны 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 ещё запущен 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). Это

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