Genius

Так, core dump отдебажить так и не удалось, когда уменьшил размер отвечает просто что file format not recognised Поковырялся в коде и обнаружил одну вещь, в авторизации при разборе пакетов используется try catch конструкция, и на этом месте падений нет А вот в коде аккаунтинга такой конструкции нет и судя по логу падения именно в этом коде, переписал и добавил туда аналогичную конструкцию, посмотрим, если поможет - выложу патч. П.С. Патч не помог, сегодня с утра опять упал, думаю дальше.

Обнаружил еще один неожиданный баг: Иногда (пока не нашел после какого события) поля userdata меняются местами, у меня в поле userdata0 храниься MAC пользователя, так вот сегодня обнаружил его у некоторых пользователей в userdata5 и в userdata9 и еще в каких-то, ручное такое распределение невозможно, в логах таких изменений нет. Постараюсь сам поискать причину, но думаю что где-то в модуле FB ошибка.

Покопавшись решил что такой большой core dump gdb просто хавать не может, уменьшил максимальный размер и жду нового падения.

Упал сегодня без меня опять, лог падения не сохранился, есть корка, но почему-то gdb не хочет ее дебажить "/var/stargazer/core.13385" is not a core dump: Value too large for defined data type Корка весит 3Гб, судя по ошибке получается что корка создалась неправильно, правда почему - мне непонятно, кто значет в чем причина - напишите.

Появился некоторый баг, иногда когда отрубается NAS и массово отключается много пользователей, а потом быстро начинают подключатся stargazer вываливается с Ошибкой сегментирования: inetaccess.cpp > 19:22:15 > ALIVE_ACK_8 - OK inetaccess.cpp > 19:22:16 > Min8(sizeof(ALIVE_SYN)) = 368 inetaccess.cpp > 19:22:16 > 384 bytes sent to 10.50.7.134 len=384 inetaccess.cpp > 19:22:16 > Send_ALIVE_SYN_8 inetaccess.cpp > 19:22:16 > recv from 10.50.7.134 len=64 inetaccess.cpp > 19:22:16 > User colombo FOUND! inetaccess.cpp > 19:22:16 > ==

Ip адреса представлены в стандартном int отображении, самый просто способ перевода из строки в него inet_addr (). Новая ошибка в модуле ФБ: Если в базе есть пользователи, которым должен быть сменен тариф в начале следущего учетного периода то stg не запустится с ошибкой: *** IBPP::WrongType *** Context: RowImpl::GetValue Message: Incompatible types. INTEGER and std::string user.cpp > 18:48:25 > Cannot read conf for user test. user.cpp > 18:48:25 > Error connecting database! Суть ошибки в опечатке: { strError =

Новый баг модуля firebird Не удаляются пользователи, при удалении пользователя через несколько минут (при реальной попытке удаления) появляется в логе: При детальном рассмотре причина ошибки найдена и исправлена: файл filebird_store_users.cpp ищем SQL запрос на удаления stat данных пользователя: Если пользователь живет в базе более одного учетного периода, то на него в таблице tb_stats существует несколько записей (одна на каждый месяц + одна текущая), и поэтому подзапрос вернет несколько значений pk_stat и будет SQL ошибка в where. Для исправления необходимо поменять н

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

user_property.h там шаблон функции

Функция void USER::OnAdd()

C++ и user.cpp в руки, там это просто реализовать.

Нормальные адреса в int формате.

Вообщем со стороны stargazer все ок, косяк в check проверках в firebird, во всех местах где задано value between 'a' and 'z', interbase а не знаю, так что пока можно просто убрать проверку значений, все равно stargazer туда ничего неправильного не запишет.

Наличие глюка подтверждаю, при попытке создать - не создает. Причину пока не искал.

Я бы посоветовал все таки вот это http://v-lan.ru/projects/stargazer-2.4/Standart/ с модулями netflow и radius

Судя по всему это последняя тестовая версия старгейзера, читайте тему о последнем билде, там написано как его лучше запускать.

Как я понимаю это стандартное фиктивное отключение пользователей в конце дня для записи параметров сессии, на работу пользователей не отражается. Это норма.

Вот эта ошибка тоже возникает. Сколько успел разобратся старгейзер примерно через 1-2 минуты разрывает связь с firebird сервером (судя по netstat) и после этого не может сохранить никакие параметры. У меня такое происходило всегда когда убираешь #define NO_DAEMON чтобы собрать его в режиме демона. В варианте с #define NO_DAEMON такой ошибки не замечено.

Там действительно есть какая-то проблема, после долгих шаманств заработало после очередной компиляции и копировании .so На самом деле для тестов можно тупо запускать из директории projects/stargazer и оно нормально запустится.

IPQ или netflow метод подсчета решит все ваши проблемы на таком железе, потому что при стандартном методе захвата трафика весь траффик проходит через Stargazer даже если он NULL при подсчете.

Нашел ошибку в формате стандартной базы, поле freemb объявлено как int и поэтому сохраняет только целую часть, вполне разумно и логично использовать для него dm_money формат так как поля по сути одинаковые.

В процессе ковыряния исходников обнаружил 2 новых параметра доступных для использования в stargazer.conf FullFee = yes/no - позволяет всегда списывать полную АП, независимо от параметра passivetime, то есть например с подключенных в середине месяца. ShowFeeInCash = yes/no - позволяет настроить возможность резервирования АП у клиента на счете для списания в конце месяца, клиент не сможет работать на эти деньги и как я понимаю видеть их в авторизаторе. Работоспособность параметров не проверял, но судя по коду должны работать. Надеюсь что я не нарушил логику авторов по открытию но

господа, заделитесь пожалуйста скриптом переноса файловой БД в firebird если таковой уже имеется, на форуме не нашел.

Тогда лучше отдайте вот этот, тут еще добавлена проверка NASIPAddress чтобы клиент авторизовался именно на том NAS который указан у него в конфиге, без такой проверки довольно легко нарушить работу системы с несколькими НАСами и скриптами OnConnect/OnDisconnect --- radius_ia.cpp.proto 2007-04-10 22:21:51.000000000 +0400 +++ radius_ia.cpp 2007-08-24 17:20:37.000000000 +0400 @@ -108,7 +108,7 @@ //---------------------------------------------------------------- const string RADIUS_IA::GetVersion() const{ - return "Radius modul version 0.72alpha"; + return "Radius authorizator

Решил написать небольшой патч для привязки аккаунтов к CallingStationID. Используется поле UserData0 (можно поменять на любое другое), добавлять новое поле не стал, так как надо менять конфигуратор тогда. В поле можно вписывать любые значения через запятую или пробел (для pppoe передается MAC для pptp IP) при наличии полного соответствия доступ разрешается, если оставить поле пустым проверка не производится. --- radius_ia.cpp.proto 2007-04-10 22:21:51.000000000 +0400 +++ radius_ia.cpp 2007-08-24 13:39:06.000000000 +0400 @@ -108,7 +108,7 @@ //-------------------------------