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

[=AK=]

В тестовом проекте для 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]

по стандарту 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");

 

[=AK=]

возможно в роутере заканчивается время молчания станции он ее и разъединяет.

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

 

[=AK=]

Например на роутере есть
Wan Connection Mode
В котором можно задать режимы разрыва связи с интернетом.
В т числе максимальное время простоя, после которого связь разрывается.

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

 

[nikolz]

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

возможно это:
Idle Timeout, mins [1-1440]
что означает 0 - бесконечность?

 

[=AK=]

возможно это:
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=]

Перенес проект на 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=]

Продолжаю расследование. Принес 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=]

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