Перейти до

отключаются абоненты по таймауту, авторизаторы зеленые

napTu

Автор: napTu,
в Питання по Stargazer

 Share Подписчики 1

Рекомендованные сообщения

napTu

napTu 4

Опубликовано:
Опубликовано:

Нужна помощь, всё работает много лет, а тут такая бяка.

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...

Потерь на пингах при этом нет.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

мысли следующие:

т.к. авторизатор пассивен по умолчанию, получается не доходят посылки от сервера.

Вспомнил что накануне игрался с конструкцией iplen в ipfw:

01509 skipto 1600 ip from any to any out iplen 0-64

для обхода pipe.

Фильтровать эта конструкция не должна, но пакеты от сервера к клиентам шли через неё,

так что возможно здесь есть некий неописанный баг ipfw в freebsd8.1.

Уточню завтра по повторным симптомам.

 

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

Ссылка на сообщение
Поделиться на других сайтах
madf

madf 279

Опубліковано:
Опубліковано:

мысли следующие:

т.к. авторизатор пассивен по умолчанию, получается не доходят посылки от сервера.

...

 

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

Авторизатор полупассивен. Он посылает серверу запросы и подтверждения на соединение и разъединение, а все остальное время просто отвечает на alive. Судя по симптомам пакеты от сервера доходят (авторизатор-то зеленый), а вот к серверу не приходят.

А чего версия такая древняя-то?

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

Авторизатор полупассивен. Он посылает серверу запросы и подтверждения на соединение и разъединение, а все остальное время просто отвечает на alive. Судя по симптомам пакеты от сервера доходят (авторизатор-то зеленый), а вот к серверу не приходят.

хм, разрушил стройную теорию ))

Как же тогда от авторизитора ничего не идет? С другой стороны, если сервер уже отрубил абонента, то чего бы ему алив пакеты слать?

Версия авторизатора 2.55.7 кстати.

 

А чего версия такая древняя-то?

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

Ссылка на сообщение
Поделиться на других сайтах
madf

madf 279

Опубліковано:
Опубліковано:

Авторизатор полупассивен. Он посылает серверу запросы и подтверждения на соединение и разъединение, а все остальное время просто отвечает на alive. Судя по симптомам пакеты от сервера доходят (авторизатор-то зеленый), а вот к серверу не приходят.

хм, разрушил стройную теорию ))

Как же тогда от авторизитора ничего не идет? С другой стороны, если сервер уже отрубил абонента, то чего бы ему алив пакеты слать?

Версия авторизатора 2.55.7 кстати.

 

А чего версия такая древняя-то?

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

Если старгейзер отрубил абонента то он и не шлет ему пакеты.

В одной из старых версий были проблемы с авторизатором, только не помню в какой именно.

Для того чтоб ен запоминать какие делались правки существует замечательная утилита diff.

 

tcpdump смотрел? Что там с трафиком по порту авторизатора?

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

tcpdump смотрел? Что там с трафиком по порту авторизатора?

дк смотрел, ничего

Авторизаторы зеленые, серевер отключает по таймауту т.к. нет посылок от авторизатора. Авторизатор бесконечно горит зеленым, посылок от него нет.

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

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

Сегодня опять волны прокатили.

После этого обмена нет, авторизатор зеленый.

Провел эксперимент, блокирую посылку пакетов от сервера до тестового клиента

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 процессы, хотя такое иногда очень редко случается в любое время.

Ссылка на сообщение
Поделиться на других сайтах
madf

madf 279

Опубліковано:
Опубліковано:

Сегодня опять волны прокатили.

После этого обмена нет, авторизатор зеленый.

Провел эксперимент, блокирую посылку пакетов от сервера до тестового клиента

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 процессы, хотя такое иногда очень редко случается в любое время.

Я могу предположить только глюк в авторизаторе. Судя по размеру пакета это либо CONN_ACK, либо ALIVE_ACK, либо DISCONN_ACK. Все три требуют предварительного пакета от сервера. Тайм-аут в пакете берется непосредственно из настроек, по этому маловероятно что он вдруг становится большим.

Опять же, старая версия сервера, старая версия авторизатора. Мало что можно сделать.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:
Я могу предположить только глюк в авторизаторе.

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

Второе - это, по моему, функция автопереподключения.

Ссылка на сообщение
Поделиться на других сайтах
madf

madf 279

Опубліковано:
Опубліковано:
Я могу предположить только глюк в авторизаторе.

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

Второе - это, по моему, функция автопереподключения.

Первое, естественно.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

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

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

похоже что удается сымитировать ситуацию путем закрытия одного авторизатора и запуском другого:

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
===== сервер отключил.  авторизатор висит зеленый.

Ссылка на сообщение
Поделиться на других сайтах
morfey

morfey 82

Опубліковано:
Опубліковано:

До речі, на стг 2.406 зі старим авторизатором (2,55,7) є така проблема, але випадки були одиничні і я не звернув на це увагу

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

Пока игрался с авторизатором, заметил еще глюк, возможно он и устранен в новых версиях сервера.

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

Только вот если авторизатор закрыть в тот промежуток, то получим накладку.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

Новую версию сервера(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мс настроен.

Первые две строчки - сообщение об отключении авторизатора. Ранее, на старой версии сервера, таких сообщений не наблюдалось.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

а вот глюк с запуском второй копии остался, после запуска второй копии идет таймаут заданный в настройках как 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

В общем ничего страшного

Ссылка на сообщение
Поделиться на других сайтах
madf

madf 279

Опубліковано:
Опубліковано:

Новую версию сервера(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.4.* не существует.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

Новый глюк нарисовался - похоже в авторизаторе 2.61.8

Жалобы пошли что автопереподключение не срабатывает после падения сервера.

Провожу эсперимент:

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
======идет нормальный обмен
11:23:14.504296 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384
11:23:14.532478 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64
11:23:54.508692 IP 192.168.11.5.rplay > 192.168.11.11.rplay: UDP, length 384
11:23:54.519242 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 64
======в файерволе на сервере запретил обмен по udp между этими адресами в обе стороны
======авторизатор зеленый, ничего не шлет
======почти через час жму настройки, отмена, тут авторизатор раздупляется, краснеет и начинает слать пакеты
12:10:58.936177 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 96
12:11:39.985808 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 96
12:12:21.018419 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 96
12:13:02.067457 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 96
12:13:43.116487 IP 192.168.11.11.rplay > 192.168.11.5.rplay: UDP, length 96

 

После открытия фаервола произошло нормальное переподключение, повторное закрытие фаервола не дало вышеописанного эффекта - авторизатор начал сразу слать попытки переподключения.

Подключил авторизатор, свернул его, прошло 40-50 минут, блокирую в фаерволе, через заданный таймаут краснеет и начинаются посылки переподключения.

 

В основном проблема наблюдается если происходило падение сервера.

На другой машине запущен авторизатор 2.55.7, на нем проблемка не повторилась.

 

Еще моменты: автосворачивание в трей не работает на windows7, пароль не сохраняется если не произошло подключение или выполнена перезагрузка после успешного подключения. Если не произошло подключения, то выскакивает остаток денег - 0грн. , что приводит в панику абонента.

Ссылка на сообщение
Поделиться на других сайтах
Kucher2

Kucher2 122

Опубліковано:
Опубліковано:
Еще моменты: автосворачивание в трей не работает на windows7, пароль не сохраняется если не произошло подключение или выполнена перезагрузка после успешного подключения. Если не произошло подключения, то выскакивает остаток денег - 0грн. , что приводит в панику абонента.

2.61.8 - всё сворачивается на W7-64bit. По поводу пароля - так всегда было, надо настроить авторизатор, потом выйти из него и зайти.

Остаток денег и будет писаться "0", потому что авторизатор не получил данные от сервера.

Ссылка на сообщение
Поделиться на других сайтах
napTu

napTu 4

Опубліковано:
  • Автор
Опубліковано:

2.61.8 - всё сворачивается на W7-64bit. По поводу пароля - так всегда было, надо настроить авторизатор, потом выйти из него и зайти.

Остаток денег и будет писаться "0", потому что авторизатор не получил данные от сервера.

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

Если вы внимательно изучите вопрос с остатком 0, то в 2.55.7 эту проблему решили, до того как авторизатор подключится никакого остатка не выводится, только надпись "Остаток денег", и то абоненты умудряются считать что авторизатор не подключается из-за того что у них деньги слили, а в 2.61.8 после первой неудачной попытки подключения выскакивает снова остаток 0грн, и это уже точно полная паника и в 100 миллионов тридцать пять тысяч сто двадцать шестой раз приходится им объяснять что до подключения авторизатора никакой остаток не считывается, а ноль - это грубая ошибка кода.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
  • 2 weeks later...
madf

madf 279

Опубліковано:
Опубліковано:

А є якісь кардинальні зміни між авторизаторами 2.55.7 і 2.61.8 ?

Ну можна diff зробити і подивитись :blink:

Авторизатором займався Борис, я не в курсі що він там змінював.

Ссылка на сообщение
Поделиться на других сайтах
morfey

morfey 82

Опубліковано:
Опубліковано:

просто все було гут близько року, у всіх авторизатор 2.55.7. Пару тижнів назад почали відключатись авторизатори, сам авторизатор якби підключений у клієнта, а старгазер каже, що юзер офлайн (. У нас паніка, по 20 чел на день телефонують

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Share
Подписчики 1
Перейти до переліку тем

  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...