• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

RAK Creator - сброс WiFi соединения

=AK=

New member
В тестовом проекте для RAK Creator (т.е. среда Ардуно) запрашиваю время у NTP сервера.

Для проверки наличия WiFi соединения у меня работает процесс, который раз в 100 мс проверяет
[inline] if (WiFi.status() != WL_CONNECTED)[/inline] и, если условие не выполняется, то он заново реконнектится к WiFi.

Если запрашиваю NTP время часто, раз в несколько секунд, проблем нет. Как только даю паузу между NTP запросами в 1 час, то почему-то теряется WiFi соединение и вследствие этго мой скетч реконнектится к WiFi.

Вставил регулярную (раз в 5 сек) посылку широковещательных UDP сообщений, в надежде что это не даст разорвать WiFi соединение. Не помогло. Пока запросы к NTP серверу идут часто, соединение держится. Как только пауза между NTP запросами увеличивается до 1 часа, то после запроса к NTP модуль выдает [inline]RTL8195A[Driver]: sta recv deauth reason code(6) sta:00:04:ed:48:4e:3a[/inline] При этом соединение пропадает и идет реконнект к WiFi.

Что это за фигня такая с RAK/Realtek? С ESP8266 таких проблем не было.
 
Последнее редактирование:

enjoynering

Well-known member
по стандарту NTP сервер нельзя опрашивать чаще чем 16 секунд. иначе забанят и пошлют в ответ kiss of death

Код:
if (packet[12] == 'R' && packet[13] == 'A' && packet[14] == 'T' && packet[15] == 'E') return 3;
.........................
else if (this->KissOfDeath(this->_packetBuffer) == 3) Serial.println("NTP_Client: Oops! kiss-of-death message, update rate is to high & access temporarily denied");
 
  • Like
Реакции: =AK=

=AK=

New member
возможно в роутере заканчивается время молчания станции он ее и разъединяет.
Я тоже подумал, что проблема в роутере. Действительно, в секции WiFi там стояла какая-то невнятная настройка на 3600 секунд. Изменил ее на 17000 секунд, но все осталось по-прежнему. Еще попробовал запрсы к NTP серверу слать чуть чаще, чем раз в час, тоже без разницы.
 

=AK=

New member
Например на роутере есть
Wan Connection Mode
В котором можно задать режимы разрыва связи с интернетом.
В т числе максимальное время простоя, после которого связь разрывается.
Я в своем модеме такого что-то не нахожу.
Есть Group Key Renewal, который был 3600, и который я увеличил, но не помогло.
Есть Idle Timeout, mins [1-1440], который установлен в 0.
Есть тикбокс Connection Always On, который тикнут.
 

nikolz

Well-known member
Я в своем модеме такого что-то не нахожу.
Есть Group Key Renewal, который был 3600, и который я увеличил, но не помогло.
Есть Idle Timeout, mins [1-1440], который установлен в 0.
Есть тикбокс Connection Always On, который тикнут.
возможно это:
Idle Timeout, mins [1-1440]
что означает 0 - бесконечность?
 
  • Like
Реакции: =AK=

=AK=

New member
возможно это:
Idle Timeout, mins [1-1440]
что означает 0 - бесконечность?
Наверное. Мануал на Billion BiPAC 7800(N) говорит нечто невнятное, a что означает 0 не описывает:

Idle Timeout: Auto-disconnect the broadband firewall gateway when there is no activity on the line for a predetermined period of time.
 

=AK=

New member
Перенес проект на NodeMCU. После часовой паузы запрос к NTP серверу прошел без малейших проблем, никакого реконнекта не наблюдается.

Код:
Sending NTP request
Round trip 410 NTP time accepted: 553350123.496
NTP finished, next request in 20 sec

Sending NTP request
Round trip 426  time diff 0 sec, COOS time 22 ms, NTC time 36 ms
NTP finished, next request in 20 sec

Sending NTP request
Round trip 382  time diff 0 sec, COOS time 505 ms, NTC time 456 ms
NTP finished, next request in 20 sec

Sending NTP request
Round trip 479  time diff 0 sec, COOS time 83 ms, NTC time 130 ms
NTP finished, next request in 20 sec

Sending NTP request
Round trip 483  time diff 0 sec, COOS time 667 ms, NTC time 708 ms
NTP finished, next request in 20 sec

Sending NTP request
Round trip 484  time diff 0 sec, COOS time 252 ms, NTC time 333 ms
NTP finished, next request in 3600 sec

Sending NTP request
Round trip 411  time diff 0 sec, COOS time 764 ms, NTC time 811 ms
NTP finished, next request in 3600 sec
Завтра еще раз все перепроверю, но пока что получается, что Realtek - это просто говно на палочке, несмотря на все сладкоголосные напевы записного вруна pvvx.
 

=AK=

New member
Продолжаю расследование. Принес RAK Creator на работу, залил в него слегка подтправленный его собственный пример WifiUdpNtpClient. В моем варианте если не получен ответ от NTP, то запрос повторяется через 10 сек. А если получен, то после получения 3-го ответа выдерживается пауза не менее 3600 сек. Пока считается пауза, на консоль выводится текущая минута ожидания и затeм печатается точка, если соединение есть
Код:
if (WiFi.status() == WL_CONNECTED)
или тире, если соединеня нет.

Парy раз вроде бы отработало нормально, но вот при очередном запуске показало следующее:
Код:
Sending request to NTP server packet received
Seconds since Jan 1 1900 = 3740697175
Unix time = 1531708375
The UTC time is 2:32:55
NTP finished
0............................................................
1............................................................

...  и т.д

26............................


RTL8195A[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1



RTL8195A[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1

................................
27............................................................

...  и т.д

35............................................................
36.................................................


RTL8195A[Driver]: sta recv deauth reason code(7) sta:xx:xx:xx:xx:xx:xx (циферки я убрал, МАС адрес роутера)

-----------
37------------------------------------------------------------
38------------------------------------------------------------

...  и т.д

59------------------------------------------------------------

Sending request to NTP server ........................................NTP retry in 10 sec

Sending request to NTP server ........................................NTP retry in 10 sec

...  и т.д
То есть, на 26-й минуте RAK переустановил групповой ключ, но соединения не разорвал. А на 37-й минуте соединение грохнулось "по причине получения фрейма класса 3 от неассоциированной станции".
 

=AK=

New member
Все-таки 100% уверенности нет. Сейчас работает уже несколько часов без проблем. Но я MTU в модеме уменьшил с 1492 до 1450, вполне может быть что из-за этого.
 
Сверху Снизу