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, length 64 ==== тут сервер ничего не шлет, потом авторизатор переподключился ==== если авторизатор закрыть в этот момент, то подключение разрывается после таймаута 16:19:07.814107 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 96 16:19:07.814296 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 200 16:19:07.834823 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 16:19:07.834986 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 384 16:19:07.856922 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 В общем ничего страшного

Новую версию сервера(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.168.11.5.4321: UDP, length 64 12:12:59.353417 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 368 12:12:59.508882 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 12:12:59.508986 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 192 12:12:59.550787 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 12:12:59.550897 IP 192.168.11.5.4321 > 192.168.11.11.4321: UDP, length 368 12:12:59.596257 IP 192.168.11.11.4321 > 192.168.11.5.4321: UDP, length 64 Это случайно не антифлуд сработал? Но вроде по коду антифлуд на 500мс настроен. Первые две строчки - сообщение об отключении авторизатора. Ранее, на старой версии сервера, таких сообщений не наблюдалось.

Пока игрался с авторизатором, заметил еще глюк, возможно он и устранен в новых версиях сервера. Авторизатор 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.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64 ===== запуск нового авторизатора: 11:08:27.757153 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 96 11:08:27.757216 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 200 11:08:27.784891 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 64 ===== первый обмен: 11:08:27.784969 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:08:27.818617 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 64 ===== нет обмена: 11:09:07.788258 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:09:47.792722 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:10:27.812323 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:11:07.820924 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:11:47.826569 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:12:27.827462 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:13:07.845115 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 ==== переподключился сам: 11:13:33.909854 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 96 11:13:33.910046 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 200[/b] 11:13:33.941406 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 64 11:13:33.941584 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:13:33.974228 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 64 - в данном случае видно что авторизатор (новой версии) потерялся в начале, а потом успешно переподключился. А вот обмен старого ахтунгризатора(2.55.7) 11:49:03.838045 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:49:03.865496 IP 192.168.11.11.rplay > icenet.net.ua.rplay: UDP, length 64 ====== подключение: 11:49:29.298332 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64 11:49:29.298417 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 192 11:49:29.352078 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64 ===== первый обмен: 11:49:29.352158 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 368 11:49:29.415216 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64 ====== а дальше всё: 11:50:09.358225 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:50:49.376563 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:51:29.389158 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:52:09.395090 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:52:49.403371 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:53:29.410010 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 11:54:09.430727 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384 ===== сервер отключил. авторизатор висит зеленый.

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 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:44:31.464103 IP 192.168.11.225.rplay > 192.168.11.5.rplay: UDP, length 64 23:45:11.413923 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:45:51.418796 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:46:31.427417 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 23:47:11.433044 IP 192.168.11.5.rplay > 192.168.11.225.rplay: UDP, length 368 Ну точно глюк авторизатора. Но ведь повальный. А по содержимому пакетов от сервера можно что то определить если их полностью дампить? Сейчас около 300 онлайн осталось. И опять словил, а уже 23-56. Вложил файлик tcpdump-a с опцией -w, где должен попасться момент потери связи. территориальной зависимости нет, от ip зависимости нет, от порядкового номера вроде зависимости нет, от версии винды зависимости нет, от антивируса зависимости нет... Но рубит только определенных абонентов, каждый раз одних и тех же. Предложил нескольким таким абонентам обновить авторизатор. Получилось поймать у себя. Нажимаю отключиться - горит всё равно зеленым, не отрубается даже через пару минут. Подключиться - пошел запрос. authflow.txt

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

у меня на 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 ==== с этого момента пакеты от сервера не отправляются ==== через некоторое время авторизатор становится красным, НО продолжает слать live пакеты серверу 00:26:52.011822 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:27:23.080831 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:27:54.152130 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:28:25.217811 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:28:56.293602 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:29:27.349909 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:29:58.407291 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:30:29.511376 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:31:00.572297 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:31:31.639488 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:32:02.711635 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:32:33.811662 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:33:04.876806 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:33:35.955490 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:34:07.019588 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 00:34:38.095823 IP 192.168.11.11.rplay > my.net.ua.rplay: UDP, length 64 ... Правда этот тестовый клиент не подвержен отключениям. Всё же остается открытым вопрос: каким образом авторизатор остается зеленым и ничего не шлет в сеть? Может это какой то зловредный отправщик рассылает пакеты с бесконечным таймаутом? Но всё равно сервер повторяет несколько запросов и хоть какой то должен дойти и обновить таймаут. Нужно будет потрейсить сеть на предмет левых посылок. Хотя быстрее это какой то внутренний сбой сервера, когда внутри что то переполняется шлется авторизатору последний пакет с очень длинным таймаутом, а самого абонента отключает. У меня трафик собирает netflow коллектор, возможно что сбои начинают происходить при превышении некторого порога pps, что вечером, с множеством торентов, очень даже вероятно. А рубит как раз то активных абонентов, тех у кого ходит трафик, а мои тестовые стоят без потребления трафика. Под конец старгез вообще упал оставив только executers процессы, хотя такое иногда очень редко случается в любое время.

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

попробовал еще и паролю трим сделать, не вышло, даже размер выходного файла не изменился ... 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->GetLogin().c_str()); PacketProcessor(buffer, dataLen, sip, sport, protoVer, &user); ... способ трима нашел такой: #include <string.h> /* SqueezeSpaces: удаляет из s группы пробелов _по краям_ */ int SqueezeSpaces(char *s) { char *startp, *endp; if (s == NULL) return EOF; for (startp = s; *startp == ' '; startp++) ; if (startp-s > 0) { endp = startp; startp = s; while (*startp++ = *endp++) ; } endp = s+strlen(s); while (*--endp == ' ') *endp = '\0'; return 1; }

походу дело в 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. Возможно что в момент отключения подскакивает нагрузка, то ли перед тем как, то ли после. Началось всё в час пик, но проблема сильно сбила нагрузку, а отключения продолжились всё равно. Перезапуски сервера ничего не дали, в логах ничего нет. Время дисконнектов: 23-36, 23-15, 23-12, 22-49, 22-39, 22-35, 22-31, 22-28, 22-03... Потерь на пингах при этом нет.

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

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

а по 10usd слабо?

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