dhcp-клиент зависает в состоянии повторного присвоения адреса при переходе в новую сеть

Даже в версии rOS 6.40.3 я всё ещё наблюдаю проблему с rebinding на разных типах DHCP-серверов (то есть на разных устройствах, к которым rOS-устройство подключается как DHCP-клиент). Например, в одной конфигурации, если я перезагружаю кабельный модем, в rOS DHCP-клиент переходит в состояние rebinding сразу после того, как Ethernet-соединение падает и затем восстанавливается через 2-3 секунды (в момент загрузки модема). Однако даже после полной загрузки модема DHCP-клиент продолжает показывать rebinding и при этом остаётся на публичном IP, который был выдан до перезагрузки.

Если в любой момент отключить и заново включить DHCP-клиент в rOS, всё работает нормально — то есть он сначала получает IP из диапазона 192.168.100.x/24 с арендой на 20 секунд, пока модем синхронизируется; когда аренда истекает, DHCP-клиент заново обновляет её и получает уже публичный IP.

Проблема, в основном, возникает в ситуациях, когда Ethernet-подключение сначала падает, а потом восстанавливается. Хотя гораздо реже, я видел, что DHCP-клиент rOS застревает в rebinding даже после истечения стандартного долгого срока аренды (например, 1 или 3 дня).

Я понимаю, что можно как-то обойти это скриптами или планировщиком, но этой ошибки вообще не должно быть, по моим наблюдениям в ранних версиях 6.x и в pre 6.x такого не встречалось.

Спасибо!

Могу подтвердить эту проблему даже на свежем RouterOS 6.44.5 с модемом Sagemcom DOCSIS 3.0. Когда временно пропадает соединение из-за проблем у кабельного оператора, приходится явно освобождать и IPv4, и IPv6 DHCP, чтобы восстановить связь. Сейчас играюсь с двумя скриптами, которые могут её исправить, но пока не ставил их в продакшен — это просто «дикое размышление».

Один вариант — проверять реальную связь и освобождать DHCP, если пинг не проходит:

:if ([/ping 8.8.8.8 interface=ether1 count=6]=0 && [/ping 1.1.1.1 interface=ether1 count=6]=0) do={/ip dhcp-client release [find interface=ether1]; /ip cloud force-update; :log info "принудительное обновление DHCP IPv4 из-за потери связи"}
:if ([/ping 2001:4860:4860::8888 interface=ether1 count=6]=0 && [/ping 2606:4700:4700::1111 interface=ether1 count=6]=0) do={/ipv6 dhcp-client release [find interface=ether1]; /ip cloud force-update; :log info "принудительное обновление DHCP IPv6 из-за потери связи"}

Альтернатива — сканировать статус DHCP, но не уверен, что во время валидного обновления состояние тоже «bound»:

:foreach i in=[/ip dhcp-client find where interface=ether1 status!=bound disabled=no] do={/ip dhcp-client release $i; /ip cloud force-update; :log info "принудительное обновление DHCP IPv4 из-за потери связи"}
:foreach i in=[/ipv6 dhcp-client find where interface=ether1 status!=bound disabled=no] do={/ipv6 dhcp-client release $i; /ip cloud force-update; :log info "принудительное обновление DHCP IPv6 из-за потери связи"}

Возможно, любой из этих кодов можно запустить через планировщик, например:

/system script add name=conncheck policy=read,write,test source={ ...код выше... }  
/system scheduler add name=conncheck interval=5m on-event=conncheck

Относитесь к этому с большой осторожностью — скрипты не тестировались, я сейчас подыскиваю, как лучше всего их внедрить!

Та же проблема у меня. Есть новости по этой ситуации? MikroTik предоставил какое-то исправление или обходное решение? MikroTik RouterBOARD 3011UiAS OS / Firmware: 6.48 Спасибо.