Alexey Osipov

Памятка для себя: сначала обрабатывать POLLIN сокеты (кроме listening), затем POLLHUP, и только затем POLLIN listening сокет.

Да, фигня какая-то случилась. Сообщения с префиксом BUG по задумке если всё работает правильно не должны никогда выводиться. Буду посмотреть. Можно ещё логи предыдущего подключения пользователя razor?

Это значит, что пользователь "parubets" пытается подключиться дважды, то есть установить одновременно два подключения под одним логином. В этом случае поведение purestg2 определяется опцией 'kickprevious'. Если она установлена, то при попытке повторного подключения предыдущее будет разрываться, а новое устанавливаться (это как у вас сейчас). Если она не установлена, то при наличии одного подключения второе будет запрещаться.

Так, ага, я всё понял. Буду фиксить дальше.

yKpon, будь добр более подробную нарезку логов. В частности, интересует момент, когда ifunit 102 был в прошлый раз выдан. А также момент, когда тот старый 102-й pppd написал в логе "purestg2: Disconnected from stargazer" (ну и окрестности).

Ну вот потому и отваливается. Можно вообще убрать обе опции, там по умолчанию нормальные значения стоят: keepalive 60 секунд, а timeout в 5 минут. Итого, если за 5 минут не получили от pppd ни одной весточки, считаем что pppd пропал без вести и отключаем пользователя.

Убедитесь, что у вас 'pppdtimeout' в конфиге старгейзера больше, чем 'keepalivetimeout' в конфиге pppd.

А в логах старгейзера в этот момент что?

Это вы видимо старгейзер остановили. Это фича: когда старгейзер останавливается (или падает) все подключения разрываются.

О каком поле userdata идет речь? Что и в какой момент вы ему "назначаете"? И что такое "момент нового обновления"?

authsocket не задан. Должен быть тем же, что и authsocket в конфиге модуля для стг, то есть в вашем случае /var/run/purestg2.sock.

Уже сделано. В git. Опции callingnumbersave, callingnumberauth, allowemptycallingnumber. Всё по аналогии с ipparam. Можно использовать вместе или независимо от ipparam.

Да-да, вчера измучился, пока додумался, почему у меня его нет на тестовой машине. Причем, в Ubuntu 12.04 pppoe-server собран без поддержки этого ключа, так что вообще весело.

Угу. Это оно. Есть пара мыслей, как повесить отцепку плагина от старгейзера на чуть-чуть попозже. Посмотрю позже. Предположительно пофиксил. В git. И начал пилить доставку calling number'а (MAC-адреса) в старгейзер, а также аутентификацию по нему.

purestg2 не знал, что интерфейс всё ещё занят и выдал этот номер демону pppd. Демон pppd попытался его использовать, не смог и откатился к алгоритму по умолчанию, при котором берется первый свободный номер.

Угу. Это оно. Есть пара мыслей, как повесить отцепку плагина от старгейзера на чуть-чуть попозже. Посмотрю позже.

purestg2 назначил pppd номер 129, но pppd не смог использовать устройство ppp129, т.к. оно уже существовало в этот момент. purestg2 проверяет занятость номеров интерфейсов исключительно по своему внутреннему списку а-ля "если я этот номер ещё никому не выдавал, значит он свободен". Если этот интерфейс был создан кем-то мимо purestg2, то purestg2 о нем не узнает и с чистой совестью может выдать этот же номер. Ещё это могут быть результаты гонок. Если по логу вверх посмотреть, когда там был интерфейс ppp129 освобожден? Можно в принципе подумать в сторону, что если pppd не может испол

Да, было бы хорошо. В принципе, запилить-то не сложно, API tcp-сокетов не шибко от локальных отличается. Только вот придется тут уже подумать о правильности порядка байт в данных, передаваемых по сети, он вполне может не совпадать на машине, где стоит stg и где pppd. И ещё встает вопрос аутентификации. Хотя, этот вопрос можно в лучших традициях unix-way отдать на откуп SSH-туннелю. А ещё... надо будет configure скрипт допиливать, чтобы можно было собирать отдельно pppd-плагин и отдельно std-плагин. Вообщем, как обычно, конкретных дат обещать не могу. Если захотите сами реализовать -

Можно: http://local.com.ua/forum/topic/25760-purestg2/

А у вас пользователи в режиме alwaysonline? А то с netflow в stg есть один нюанс... если сенсор пошлет статистику по трафику в стг уже после того, как пользователь сделался offline, то стг такой траффик не учитывает. Я на это наступал и делал специальный патч к стг, который позволял учитывать такой "запоздалый" трафик.

А вот какая чудная штука нагуглилась: http://blog.sflow.com/2011/12/sflowtool.html Не спасет?

ipt_netflow на порядок шустрее, ибо ядерное.

А это тот-же самый sgconf, только без разбора XML. А, я его попутал с xmlrpc видимо. Правильный вопрос: конфигурирование через xmlrpc тоже подвержено этой проблеме?

А sgconfxml тоже подвержен этой проблеме?

И что делать, если они оба будут заданы? Впрочем, наверное можно. Скорее всего будет как сейчас с ipparam возможно указать, из какого поля брать данные.