napTu

тоже самое. Может какой костыль вставить? Не совсем понял принцип bak файлов. Они сами не бекапятся, нужно вручную создавать? А то сегодня ребутнулся сервак, пришлось вручную возвращать некоторые stat файлы, их кстати вообще не было, в прошлой версии они обнулялись при некорректном выходе, а тут вообще нет. А тут еще Freeze по 300 раз после каждой попытки запуска.

а вот глюк с запуском второй копии остался, после запуска второй копии идет таймаут заданный в настройках как UserTimeout, а потом авторизатор шлет сигнал о переподключении. 16:18:01.760077 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 384 16:18:01.764829 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 ==== тут вторая копия отослала три пакета 16:18:09.771259 IP 192.168.11.11.1806 > 192.168.11.5.4321: UDP, length 96 16:18:09.791976 IP 192.168.11.11.1806 > 192.168.11.5.4321: UDP, length 64 16:18:09.816613 IP 192.168.11.11.1806 > 192.168.11.5.4321: UDP, lengt

Новую версию сервера(2407) не удается так обмануть. Закрытие-запуск авторизатора чаще приводит к нормальному подключению и продолжению работы, иногда подключится не удается, но через несколько попыток переподключения всё восстанавливается. И это с авторизатором 2.55.7 . Вот момент когда подключиться удается не сразу 12:12:44.318712 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 12:12:44.318895 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 24 12:12:47.340337 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 12:12:53.416792 IP 192.168.11.11.4321 > 192.

Пока игрался с авторизатором, заметил еще глюк, возможно он и устранен в новых версиях сервера. Авторизатор 2.61.8 запущен, запускаем вторую копию, на сервер уходит три пакета со случайного порта клиента (не с 5555), после этого (но не всегда) сервер перестает посылать пакеты авторизатору, пользователя не отключает. Но тут приходит на помощь умный авторизатор, после истечения таймаута ,по которому пользователь должен быть отключен, авторизатор переподключается восстанавливая нормальный обмен. Только вот если авторизатор закрыть в тот промежуток, то получим накладку.

похоже что удается сымитировать ситуацию путем закрытия одного авторизатора и запуском другого: 11:06:57.870417 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:06:57.939373 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64 11:07:22.690216 IP 192.168.11.11.1072 > icenet.net.ua.rplay: UDP, length 96 11:07:22.719112 IP 192.168.11.11.1072 > icenet.net.ua.rplay: UDP, length 64 11:07:22.754291 IP 192.168.11.11.1072 > icenet.net.ua.rplay: UDP, length 64 11:08:02.727398 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:08:02.770569 IP 192.16

23-07 - время Ч. Вроде и трафик уже на спад пошел и нагрузка. Прямо таки через день срабатывает. За полторы минуты 260 дисконнектов, до 10 в секунду. О! Поймал этот момент: 23:42:31.474839 IP 192.168.11.225.rplay > 192.168.11.5.rplay: UDP, length 64 23:43:11.407223 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:43:11.468222 IP 192.168.11.225.rplay > 192.168.11.5.rplay: UDP, length 64 23:43:51.409788 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:43:51.464963 IP 192.168.11.225.rplay > 192.168.11.5.rplay: UDP, length 64 23:44:31.410281 IP

Глюк в ситуации когда он зеленый и ничего не шлет, или в ситуации когда красный и что-то шлет после того как отключился? Второе - это, по моему, функция автопереподключения.

у меня на freebsd 4.10 тоже БД никогда не билась, а вот на 7.1 уже началось

Сегодня опять волны прокатили. После этого обмена нет, авторизатор зеленый. Провел эксперимент, блокирую посылку пакетов от сервера до тестового клиента my# tcpdump -i em0 udp and dst port 5555 and dst or src 192.168.11.11 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes === последний нормальный обмен 00:24:45.924406 IP my.net.ua.rplay > 192.168.11.11.rplay: UDP, length 368 00:24:45.952629 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 ==== с этого момента пакеты от сервера не о

Поковыряв вчера код тоже так подумал Еще раз спасибо за разъяснения

попробовал еще и паролю трим сделать, не вышло, даже размер выходного файла не изменился ... map<string, int>::iterator pi; SqueezeSpaces(packetName); pi = packetTypes.find(packetName); if (pi == packetTypes.end()) ...

Не совсем понимаю как происходит поиск здесь: user_iter user; if (users->FindByName(login, &user) == 0) Логин я переведу в нижний регистр, затем как сделать чтобы поиск производился по именам переведенным в нижний регистр? А затем, уже после найденного имени, укажу что login=user->GetLogin();

Спасибо! Со SqueezeSpaces собралось, чет предупредило только inetaccess.cpp: In function 'int SqueezeSpaces(char*)': inetaccess.cpp:722: warning: suggest parentheses around assignment used as truth value

это понятно что проще отмазаться чем помочь ))) я то нашел где, нашел реализацию alltrim, но в cpp - бум-бум и как воткнуть не знаю )) Вероятно в int AUTH_IA::RecvData(char * buffer, int bufferSize) { ... char login[PASSWD_LEN]; //TODO why PASSWD_LEN ? memset(login, 0, PASSWD_LEN); Decrypt(&ctxS, login, buffer + 8, PASSWD_LEN / 8); sip = *((uint32_t*)&outerAddr.sin_addr); sport = htons(outerAddr.sin_port); // ГДЕ ТО ТУТ =============================== user_iter user; if (users->FindByName(login, &user) == 0) { printfd(__FILE__, "User %s FOUND!\n", user->GetL

походу дело в ipfw было, или еще как вариант какая нить хрень по сети бродила, сегодня всё нормализовалось.

Подскажите, где поправить чтобы был тримминг пробелов имени пароля пришедшие от авторизатора? А еще и приведение имени к нижнему регистру.

дк смотрел, ничего Признаться не до конца смотрел, сразу не сообразил, tcpdump полный обмен не проконтролировал в моменты обрыва, только по trafshow от авторизатора смотрел и видел что там пусто

Вот перл скрипт ежедневного снятия абонки. Запускается из крона getdayfee.txt

хм, разрушил стройную теорию )) Как же тогда от авторизитора ничего не идет? С другой стороны, если сервер уже отрубил абонента, то чего бы ему алив пакеты слать? Версия авторизатора 2.55.7 кстати. да притерлось всё уже давно, собственных мелких исправлений несколько, о которых уже и забыл где и что исправлял, не очень охота рушить всё новой версией

мысли следующие: т.к. авторизатор пассивен по умолчанию, получается не доходят посылки от сервера. Вспомнил что накануне игрался с конструкцией iplen в ipfw: 01509 skipto 1600 ip from any to any out iplen 0-64 для обхода pipe. Фильтровать эта конструкция не должна, но пакеты от сервера к клиентам шли через неё, так что возможно здесь есть некий неописанный баг ipfw в freebsd8.1. Уточню завтра по повторным симптомам. Но всё же непонятно поведение авторизатора, хоть бы покраснел для разнообразия после некоторого внутреннего таймаута...

Нужна помощь, всё работает много лет, а тут такая бяка. stg2.405.9.7, FreeBSD 8.1 недавно переехал. Сегодня вечером многих, но не всех, рубануло. Авторизаторы зеленые, серевер отключает по таймауту т.к. нет посылок от авторизатора. Авторизатор бесконечно горит зеленым, посылок от него нет. Переподключение авторизатора помогает на следующие 5-10 минут. На моих трех машинах ничего не происходит, всё нормально подключено и переподключается при перезапусках сервера. таймауты выставлены так UserDelay = 30, UserTimeout = 125. Возможно что в момент отключения подскакивает нагрузка, то ли перед те

что ему еще делать кроме как коммутировать. 100-150Kpps с десятком ACL и десятком VLAN. Как вариант рассматривается раздача iptv

У ES3528 случайно не тот же самый чипсет как у DES3028? А еще подскажите, ES3528 потянет центр сети на 2000 компов?

а по 10usd слабо?

ой и не говорите! какие сложности прямо! Название Цена Linksys - SPS224G4-G5 —.—— грн. а потом в аське куча ответных вопросов -а что вас интересует, а какого размера, а какого цвета, а какого...