Alexey Osipov

Релиз 2.4: https://github.com/lion-simba/purestg2/releases/tag/2.4 PS. Проект переехал на github.

Сердечно благодарю за мнения! Я таки почти одумался и вернулся к рассмотрению варианта с привязкой IP/MAC. Авторизатор старгейзера хорош, но опять же дополнительное ПО на конечных машинах. +, но по условиям задачи у нас неизвестно какие свичи. ВО! Я теперь знаю, по какому слову гуглить. Спасибо! +, а ещё я внезапно вспомнил про CGI. Но вообще изначально хотел заюзать вот это: https://www.gnu.org/software/libmicrohttpd/Вроде как раз для этих целей. Не C++ правда, но. Always online как-раз не очень по причинам, озвученным нашим пытателем единорогов.

Всем привет! Есть небольшая компания, которая хочет контролировать использование интернета своими сотрудниками (~30 пользователей). Авторизация пользователей по IP/MAC ненадежна. Поднятие PPPoE приведет к трудностям как для пользователей (надо "подключать" интернет), так и для админа (шлюз по умолчанию для пользователей после подключения PPPoE изменится и трафик пойдет через него => на сервере придется специальным образом обрабатывать доступ к внутренним ресурсам). squid-авторизация решает вопрос только для http-трафика и только если squid непрозрачный (а непрозрачный squid опять же гем

Есть. Разбить имеющийся диапазон на несколько по количеству вланов не вариант? Насколько обязательно иметь отдельный pppoe-server для каждого влана? В мане pppoe-server написано, что опцию -I можно давать несколько раз с разными интерфейсами, и он будет слушать их все. Выдаст. Как вариант использовать опцию -p, которая позволяет задать файл со списком адресов, которые будут выдаваться абонентам. Исключить из этого файла статические адреса. Можно, опять же, чисто организационно, статические адреса выдавать из одного пула, а динамические - из другого. Или, например, статические выда

Логично. А почему -N 500 тогда? Можно сделать -N 254 и тогда не будет выходить за диапазон. Сделать реально, по аналогии с тем, как сейчас плагин отслеживает номера ppp-интерфейсов. Но мне кажется, что способ с -N 254 проще.

Как оно там?

Есть. Реализовано в git. Теперь, если у пользователя в настройках стоит "*", то purestg2 не будет пытаться назначать IP пользователю. IP будет выбирать сам pppd. При этом после подключения пользователя, выбранный IP-адрес будет видно в старгейзере, и именно он придет в скрипт OnConnect. Через какое-то время планирую выпустить релиз 2.4, уже достаточно изменений набралось.

Как как? Допиливать purestg2. =) Как и говорил - это несложно. Попробую запланировать на ближайшие выходные.

Выдается 0.0.0.0, что конечно же ни к чему хорошему не приводит. Так и есть. А звездочка в поле IP интерпретируется старгейзером как 0.0.0.0. В принципе можно доработать purestg2, чтобы он использовал IP, который предлагает pppd. Это несложно.

И я кажется понял, от чего дважды запрос на коннект пришел. Коннект зовется в тот момент, когда у pppd происходит событие ip_up ("Протокол IP сконфигурирован и готов к использованию"). Я прогулялся по исходникам pppd, и похоже, что это событие может происходить сколько угодно раз за время существования соединения, а именно всякий раз, когда клиент запрашивает переконфигурацию параметров соединения. Однако, перед ip_up в pppd честно возникает событие ip_down, но беда в том, что это событие purestg2 никак не обрабатывает. А дисконнект юзера происходит на link_down, т.е. после разрыва соедин

madf, отличный анализ! Теперь бы ещё посмотреть логи pppd в окрестностях 2014-05-11 18:12:45.

А это вообще что-то жуткое и на первый взгляд не имеющее ни к Stargazer ни к тем более purestg2 никакого отношения. С этим разобрались? Или продолжает повторяться?

Вот это не имеет отношения к биллингу. Думаю гугл сможет подсказать, от чего это и как с этим бороться. git на то и git, что из него можно взять любую версию. Вот здесь: https://github.com/lion-simba/purestg2/commits/master можно выбрать понравившуюся версию, кликнуть рядом с ней Browse Code, а затем справа кнопочку Download ZIP. Кроме того, ни куда не делись стабильные релизы: http://code.google.com/p/purestg2/downloads/list

А это вообще что-то жуткое и на первый взгляд не имеющее ни к Stargazer ни к тем более purestg2 никакого отношения.

Не могу пока выделить достаточно времени. Тут надо вдумчиво смотреть. Желание есть, проект формально не остановлен. В качестве workaround предлагаю выключить в конфиге kickprevious.

Выложил в git, компилируется, но работоспособность я вообще не проверял. Если страшно, то жди, когда я проверю (на неделе).

Да, точняк. Поглядел код. Старгейзер запускает OnConnect и OnDisconnect асинхронно. И если после отключения пользователя, он снова подключится в пределах 0.1 с, то старгейзер будет считать, что пользователь никуда и не уходил, а следовательно OnDisconnect/OnConnect зваться не будут. В принципе, есть у меня одна идея, как это на уровне purestg2 можно разрулить. Попробую на выходных.

Такого не должно быть. Вставь в OnConnect/OnDisconnect в самое начало какие-нибудь логгеры типа echo "`date` User $user connected" >> /var/log/stgconnects.log в самое начало, чтобы убедиться, что эти скрипты выполняются. Заодно увидим, в каком порядке. Нет, эти таймауты точно ни при чем. Тут происходит какой-то race condition. Например, не гарантируется, что OnDisconnect будет выполнен до закрытия ppp-интерфейса. Однако OnConnect гарантированно выполняется после инициализации ppp-интрфейса. Но если ppp-интерфейс очень быстро отвалился, то OnConnect может отработать, когда интер

Нужен лог старгейзера за тот же промежуток времени.

Параметр keepalivetimeout добавляется к pppd модулем purestg2. Он опциональный. Если его не задать, то он считается равным 60 (секунд).

Это опция pppd. Откуда pppd берет конфиг с опциями - зависит от того, кто этот pppd запускает. Если, например, pppd запускается из pppoe-server, то эти опции лежат в /etc/ppp/pppoe-server-options

Нет, отключить совсем не получится. Если опцию убрать из конфига, то будет использоваться значение по умолчанию - 5 минут. Как watchdog он полезен. Я бы рекомендовал оставить значения по умолчанию.

В принципе любое больше нуля. Главное, чтобы pppdtimeout был больше (желательно минимум в 2 раза), чем keepalivetimeout в конфиге pppd. Слишком маленькие значения, впрочем, могут породить излишнюю активность соединения между pppd и stargazer'ом (через UNIX socket'ы). Не знаю чем это черевато. Если отклик старгейзера будет запаздывать, то процесс логина у пользователя будет тоже затягиваться. Думаю, если его черезчур сильно затянуть, то клиент (или его винда/линукс) не дождется ответа и сам разорвет ещё неустановленное соединение. Ещё это приведет к увеличению нагрузки на процессор, т.к.

Выложил.

Там довольно обширная переделка. В процессе. По поводу "2014-01-21 09:48:11 -- purestg2: BUG: can't find previous user socket for user "razor"" - предположительно пофиксил, ещё позавчера, но у меня слегка повредился локальный репозиторий с кодом, не смог сходу выложить на github. Это скорее всего завтра выложу.