Устройства в LAN видят друг друга с задержкой

nvr · 02 май 2021, 13:45

Всем привет.

Проблема кратко:
Устройства в локальной сети не видят друг друга, пока не начать долбиться с одного устройства на другое. Поясню: долбиться это пинговать или отправлять GET-запросы по HTTP.

Подробнее:
У меня довольно простая конфигурация сети:

Роутер hAP AC2

Порт Ethernet1: PPPoE (интернет). Наверное, можно вычеркнуть, т.к. к вопросу отношения не имеет.

Порты Ethernet2–5, а также интерфейсы wlan1 (на 2.4 ГГц) и wlan2 (на 5 ГГц) объединены в мост.

DNS на отдельном устройстве, DHCP на Mikrotik

Короче, обычная домашняя сеть типа 192.168.0.0/24.

Мои устройства:

ПК на Win10, подключён кабелем.

Мобильные телефоны на Android, подключены по Wi-Fi 5 ГГц.

Масса IoT-устройств, подключены по Wi-Fi 2.4 ГГц. Они не выходят в интернет, работают только в пределах локалки.

Всем в Микротике назначены статические IP.

Прежде чем меня отправят искать правду на форумы умных устройств, я подчеркну, что при замене роутера на простейший Zyxel 2013 года выпуска все проблемы моментально исчезают. Так что источник трудностей определённо в конфигурации Mikrotik и моих кривых руках (потому и прошу помощи).

Всё что мне нужно — это чтобы устройства постоянно друг друга видели и могли общаться друг с другом без танцев с бубном. Но так не получается. Как я писал выше, проблема следующая: устройства не видят друг друга, пока не начать активно отправлять запросы с одного на другое.
Пример: я хочу зайти на веб-интерфейс IoT-девайса с моего ПК через браузер. Не выходит (ERR_ADDRESS_UNREACHABLE). Я отправляю ping -t на адрес нужного устройства. Первые несколько секунд результат такой:
Reply from 192.168.0.XX (адрес, с которого отправляется пинг): Destination host unreachable.
Затем, спустя 5-20 повторных запросов (с ПК быстрее), всё становится прекрасно, пинг проходит, а само устройство становится доступно.

Но в этот же момент оно не будет доступно с любого другого устройства! Т.е. с какого ты его пингуешь или отправляешь GET-запросы, только с того и будет доступ. Я даже настроил один из IoT-девайсов на постоянный пинг другого, и — о чудо — между ними никогда нет проблем связи. Если остановить пинг или прекратить регулярно отправлять GET-запросы, танцы через какое-то время придётся повторять.

Заметил следующие мелочи:

После того как все устройства пропингованы с ПК (т.е. хотя бы раз после перезагрузки системы он получил к ним доступ), он очень редко испытывает трудности с повторным подключением.

С мобильного телефона же контакт теряется очень быстро, и повторять шаманство приходится часто.

Мне важно решить этот вопрос потому, что на моментальный доступ завязано управление умным домом с приложения. И нажимать кнопку включения чего-либо, пока оно не соизволит сконнектиться… ну проще уже до выключателя дойти. На всякий случай: если нет доступа с приложения, то нет и через браузер, к разработчику приложения отправлять тоже не надо, потому что разработчик приложения я, и под Зухелем всё работает идеально отовсюду.
Старый роутер ставить обратно я не хочу, потому что мне нужна беспроводная сеть 5 ГГц, ну и деньги за Микротик уже уплачены, что поделать

Что я уже менял в настройках после попыток решить проблему гуглом и что не принесло результатов:
Увеличен ARP timeout
В ARP-лист занесены все адреса (интерфейсом указывал мост)
Включал-выключал HW Protection
Обновлял RouterOS
Перепрошивал роутер через netinstall

Очень прошу помощи. Ощущение, что решение где-то на поверхности, но я за неимением знаний не понимаю, куда копать.

Выдача /export hide-sensitive:

Надеюсь, описал проблему достаточно подробно. Если нужно предоставить ещё какую-либо информацию, дайте знать.

Спасибо всем, кто дочитал.

Ca6ko · 02 май 2021, 23:31

nvr писал(а): ↑02 май 2021, 13:45 решение где-то на поверхности

Сброс в завод, минимальная настройка через квик сет и всё будет работать.
Потом частями переносить конфиг и искать кто виноват, или забить.

PS Устройство без фаервола может быть все что угодно.
Мощность увеличивать без думно не нужно. 20 это не правильное число

Использование wifi, с его не стабильностью, для управления - очень плохая идея.

Kostetyo · 04 май 2021, 17:13

Проверьте на всех устройствах: 1. Основной шлюз, даже если уже проверяли, проверьте еще раз, основной шлюз должен быть IP микротика.
2. Проверьте кто у вас является днс на всех устройствах (я думаю что проблема именно в этом), настройте корректно днс сервер.
3. Встречался с подобным на китайских датчиках, они как бы уходили в энергосберегающий режим и не просыпались до отправки пакетов в их сторону, причем web-сервер становился не доступен и api тоже. Помогал именно пинг, однако пинг будил это устройство и оно могло общаться с другими без проблем, не важно кто пингует. У Вас же какой-то затык в самой сети, сбросьте все под ноль. и настраивайте все на базе микротика, в том числе днс. Не используйте квик сетап, не используйте фаервол, пока что.

nvr · 05 май 2021, 21:59

Ca6ko писал(а): ↑02 май 2021, 23:31 Мощность увеличивать без думно не нужно. 20 это не правильное число

Не успел убрать, это было в качестве эксперимента :)

Ca6ko писал(а): ↑02 май 2021, 23:31 Использование wifi, с его не стабильностью, для управления - очень плохая идея.

Полностью согласен, но все устройства, которые работают нестабильно, у меня без Ethernet (это микроконтроллеры). Ну и всё-таки хорошо работали под другим роутером, за то время успел наклепать их порядочно по всему дому, а теперь вот такая ситуация.

Kostetyo писал(а): ↑04 май 2021, 17:13 1. Основной шлюз, даже если уже проверяли, проверьте еще раз, основной шлюз должен быть IP микротика.

Да, шлюз корректный, выставлен вручную.

Kostetyo писал(а): ↑04 май 2021, 17:13 2. Проверьте кто у вас является днс на всех устройствах (я думаю что проблема именно в этом), настройте корректно днс сервер.

Все обращения к устройствам в сети производятся с указанием только IP-адреса, по идее настройки DNS влиять не должны. В любом случае я перенастроил сеть на использование DNS на Микротике — безрезультатно.

Kostetyo писал(а): ↑04 май 2021, 17:13 3. Встречался с подобным на китайских датчиках, они как бы уходили в энергосберегающий режим и не просыпались до отправки пакетов в их сторону, причем web-сервер становился не доступен и api тоже. Помогал именно пинг, однако пинг будил это устройство и оно могло общаться с другими без проблем, не важно кто пингует. У Вас же какой-то затык в самой сети, сбросьте все под ноль. и настраивайте все на базе микротика, в том числе днс. Не используйте квик сетап, не используйте фаервол, пока что.

Попробовал с квиком, попробовал без. Фаерволл тоже выключал. Без эффекта.

Я производил поиск затыка, как вы и советовали, поэтапно. Найти конфиг, при котором проблема не проявляется, не могу.
Возможно, какая-то особенность моих устройств (это микроконтроллеры на базе чипа ESP32, если это важно) делает их несовместимыми с Микротиком (это я наверно глупость сказал) или требующими особой настройки роутера (возможно, ближе к правде).

Я всё ещё склоняюсь к версии, что что-то не так с резолвингом адресов. ПК прекрасно видит устройства длительное время после первого взаимодействия, а телефон — нет. Это не может быть ARP-кэш (т.е. на Винде он есть, на телефоне нет или работает по иному прицнипу, короткий таймаут итп)?
И прошу прощения за, возможно, комичный вопрос: на старом роутере в настройках вообще не было ничего связанного с ARP, а все устройства работали стабильно. Может ли быть это связано? Может, он по умолчанию использовал какой-то из режимов (?) ARP, который проблем не вызывал?

xvo · 05 май 2021, 22:10

Я бы попробовал удалить все ваши выкрутасы с arp - убрал все значения arp-timeout - на бридже, на wlan-интерфейсе и в ip settings, убрал все статические arp записи, и включил add-arp-for-leases на dhcp-server'е.

mafijs · 05 май 2021, 22:15

nvr писал(а): ↑05 май 2021, 21:59 это микроконтроллеры на базе чипа ESP32, если это важно

Тоже именно такие есть дома, работает исправно, посылает данные в InfluxDB.
Замечу, что через web подключится бывает не первого раза. Лнгче подключается с Ubuntu mozilla.
Но это мне редко надо. Всю информацию получаю с базы InfluxDB.
Подключены на hAP AC. соединение не падает.

Код: Выделить всё

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyg basic-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,48Mbps country=latvia disabled=no mode=ap-bridge security-profile=passwd ssid=esp32connect supported-rates-a/g=\
    6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps tx-power=4 tx-power-mode=all-rates-fixed

п.с. RouterOS старый. 6.40.3 , не хочется портить Uptime , уже 1314 суток.

nvr · 10 май 2021, 20:47

xvo писал(а): ↑05 май 2021, 22:10 Я бы попробовал удалить все ваши выкрутасы с arp - убрал все значения arp-timeout - на бридже, на wlan-интерфейсе и в ip settings, убрал все статические arp записи, и включил add-arp-for-leases на dhcp-server'е.

К сожалению, результат такой же. Первые обращения к устройству улетают в никуда, и только через какое-то количество обращений связь устанавливается.
Вот снимок экрана телефона, иллюстрирующий этот эффект:

Я всё больше склоняюсь к тому, что устройства несовместимы с Микротиком, как бы парадоксально это ни звучало.

mafijs · 10 май 2021, 21:14

Ну не знаю. У меня тоже не c первого раза ping проходит с портативного, но сервера (Ubuntu) с сразу.
И как уже писал, на прямую подключтся к ESP32 без надобности.

nvr · 10 май 2021, 22:13

mafijs писал(а): ↑10 май 2021, 21:14 И как уже писал, на прямую подключтся к ESP32 без надобности.

А мне вот это, наоборот, очень нужно, потому что управление реле, сигналами ИК-управления и прочим напрямую завязано на ноги микроконтроллеров.

В общем, вернул я старый роутер на место, Микротик подключил к нему по кабелю в режиме АР. DHCP на старом, вообще всё на старом, Микротик это теперь только WIFi с NAT. Подключаюсь с телефона что через сеть 2,4, что через 5 ггц — всё работает без проблем. Ничего не отваливается, доступ к устройствам моментальный. Что за дурь происходит, если использовать его как основной роутер, чёрт его знает. Наверное, уже и не буду дальше разбираться. Спасибо всем, кто попытался помочь!

xvo · 10 май 2021, 23:23

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

Я ESP32 подключал у себя только не на долго, для теста, так что не могу уверенно сказать, что проблем с ним не было.
На STM32 с ESP8266 в качестве wifi у меня какое-то время что-то крутилось с MQTT на борту, там такого не замечал.
Плюс на другой локации лампочки на основе ESP8266, на них вроде тоже никто не жаловался.

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

Устройства в LAN видят друг друга с задержкой

Вход • Регистрация