Russian Users MikroTik | Форум пользователей MikroTik

Ну так оно ж просыпается каждые сколько-то миллисекунд, получить то, что ей отправлено.
Короче, по ссылке выше в одном из постов ссылка на другую тему именно про такую же проблему с ESP8266 и именно с микротиками в том числе.

Вот оттуда:

The general idea is the access point will buffer multicast/broadcast messages until the connected device can collect those messages.
The DTIM interval X, which can be set in some access points, is typically between 1...3, which means those buffered packets are kept for X beacon intervals.
It looks like the ESP is switching its own interval of waking up without taking into account the offered DTIM range of the access point.
For example, if the access point allows for a DTIM of 3, but the ESP does wake up every 4 beacon intervals, then it may miss those ARP requests (and also UDP traffic).

На микротике, как я понимаю, DTIM=1 и поменять его, увы, нельзя, а ESP возможно это игнорирует и просыпается не на каждый beacon, отсюда и вытекает решение не давать ей спать совсем.

имеются 2 устройства с esp, с микротиком rb2011 работают хорошо и стабильно, однако они сами генерируют поток данных, бывает что затыкаются через 12-15 дней непрерывной работы, но это не критично.
А в тп линке видимо как то помогает им не спать вот эта штука, которая показывает вам в вебморде сколько устройств и какие подрублены.

Может на микроте просто скрипт написать чтобы микрот к ним обращялся по расписанию, или Watchdog настроить.

xvo писал(а): ↑12 май 2021, 11:47

mafijs писал(а): ↑12 май 2021, 11:32 Просто стало интересно после прочтения проблемы у ТС.

Сорри, я не уточнил: про гугл - это все-таки камень в огород топикстартеру.
Уже давно вроде поняли, что проблема в arp, и как то странно не полезть и не почитать про arp у самого проблемного устройства.

Ребят, ну для меня же на момент создания темы проблемным устройством был Микротик, поскольку именно после замены роутера появились трудности. А знаний у меня не так много, чтобы сразу соображать, куда именно копать. Я поэтому к вам с просьбой помочь и пришёл. Опять же, кто ж знал, что ржавый Зухель обладает особенностью, которая эту проблему благополучно решает? Из-за этого я был полностью уверен, что дело, если и в ARP, то в конфиге ARP нового роутера, а не в особенностях ESP.

xvo писал(а): ↑12 май 2021, 18:24 вытекает решение не давать ей спать совсем.

По-моему, помогло. Я сегодня ещё погоняю все устройства, протестирую их общение между собой тоже, и отпишусь.
Да, proxy-arp я выставлял — безрезультатно.

nvr писал(а): ↑16 май 2021, 12:22
Да, proxy-arp я выставлял — безрезультатно.

proxy-arp или proxy-arp-local ?

mafijs писал(а): ↑16 май 2021, 13:45

nvr писал(а): ↑16 май 2021, 12:22
Да, proxy-arp я выставлял — безрезультатно.

proxy-arp или proxy-arp-local ?

Оба, кажется, пробовал, но сейчас понимаю, что не скажу наверняка. Будет время — переделаю всё назад и попробую, самому интересно. Вернусь и напишу.
Пока что могу с уверенностью сказать, что WiFi.setSleep(false); проблему решило.

nvr писал(а): ↑20 май 2021, 10:57 Будет время — переделаю всё назад и попробую, самому интересно. Вернусь и напишу.

Наконец руки дошли, поставил снова Микротик в качестве единственного роутера, выставил local-proxy-arp, а во все микрухи прописал nosleep. Работает. Но работает с задержками, каких на Zyxel не было.
Пингуется сразу, проблемы с host address unreachable нет, однако все первые запросы на esp32 — что через веб-интерфейс, что через Android-приложение — проходят медленно. Но проходят. Судя по всему, это лучший результат, которого можно достичь между Микротиком и esp32, будем жить с ним.

UPD: задержку также устранил, пересадив телефон на virtual wlan.