madf

Можно попробовать. Свяжись со мной по почте (faust@stg.dp.ua) или через Jabber (JID: madf@jabber.kiev.ua)

Видимо, не с легкостью. По крайней мере от местного прова жалоб не поступало... Своего сервака нет.

При авторизации MAC не проверяется. Но можно сделать дополнительную проверку в OnConnect. Описываем MAC, например, в в одном из полей UserData. При вызове скрипта получаем реальный MAC с помощью arp -n $IP (ну там еще tail'ом и cut'ом немножко поработать), и вычитываем соответствующий UserData из БД (файловой или SQL'ной). Если совпадает - разрешаем юзера в файрволле.

Сложно найти глюк, если его невозможно повторить.

Спасибо, разместим! Проблема не в компиляции - проблема в отсутствии CentOS

Напомни, плиз, почту...

Если нет - то я и сам справлюсь. Правда это будет несколько медленно - занимаюсь проблемой по вечерам... Да и вобще, OpenSource-проекты всегда развивали энтузиасты, а не наемные работники

А готовую rpm'ку не можешь выложить? Мы бы на сайт поместили...

Широкий канал здесь и даром не нужен - нужен нормальный программист

Проблема трафкаунтера сейчас в том, что при любых операциях с деревом пакетов все действия блокируются. Так, например, как уже было верно подмечено den68, при FlushAndRemove лочится прием трафика. И наоборот - при приеме лочится FlushAndRemove. Решается эта проблема введением 2-х промежуточных буферов: на прием пакета и на его отдачу юзеру. При этом функции FlushAndRemove делегируются либо классу USER либо классу USERS. Этот вариант решения мы с Борей обсуждали на прошлой неделе. Сейчас он в процессе проектирования. Изменений все-таки надо будет много сделать. Кроме того я хочу полностью "о

Ну и при чем тут Stargazer?

Дабы выборка по таблице в милион записей не занимала много времени нужно индексы использовать.

Я вобще не вижу, почему тут может быть проблема. Возможно, совпадение?

Чем рандом не угодил? Он там всего-лишь распределяет нагрузку при записи в базу на промежуток времени - чтобы не писать сразу всех юзеров скопом и не тормозить зря систему...

Новая версия позволяет запускать несколько авторизаторов с одной машины. Проблему с IP решали алиасами. Тестировали на 600-800 рандомно переподключающихся "юзерах".

Точных цифр сейчас уже не приведу. Тестировали, так-же, и по inetacces - с помощью консольного авторизатора, случайными переконнектами. На форуме где-то даже есть скрин этого дела... Боря постил. Если бы я знал что происходит при падении - я бы исправил уже, наверное Бектрейсы выше в теме.

Естественно, stg-2.405.9.8. У меня сейчас просто нет времени заниматься чужими разработками...

Тогда скорее всего нарушение памяти. Прогони под valgrind.

Во первых, размер массива в С ограничен доступной памятью. Во вторых, тут не С а С++. В третьих, тут не массив а std::map. Но наблюдение, несомненно, интересное...

Тестирование проводим с помощью cap_debug, т.к. мы не являемся провайдером. Генерируем трафик более 100 Мбит. Возможно, проблемы появляются при определенных видах трафика. Например при активном использовании p2p. Что более странно - у местного провайдера stg работает стабильно (cap_nf, radius, store_files), в т.ч. и на безлимитных тарифах и при нагруженности порядка 4000 юзеров на сервер. Именно это я называю невозможностью воспроизведения ошибки.

Лишний открытый порт не может быть причиной непрохождения пакетов. Проблема в файрволле.

Если авторизатор не коннектится к биллингу - значит не ходят UDP-пакеты. Смотри цепочки файрволла.

Дело "примерно" в связке user - traffcounter - capturer. Может быть. Так как мы так и не нашли причину, почему может портиться ссылка на локально создаваемый обьект (или почему может портиться сам этот обьект). Я, конечно-же, имею в виду мьютекс юзера. Основная проблема в том что мы не можем повторить падение у себя. Так что будем благодарны если вы найдете решение.

Я бы озвучил, но у меня сейчас мысли в другом русле. Проблемой Боря занимается

Есть результаты по логу, представленному Keen. Не буду утверждать что мы нашли причину падений, но уже есть некоторые мысли. Постараюсь держать вас в курсе дела.