Fetch по любому каждый раз устанавливает новое соединение, т.ч. результаты автоматизированной проверки сервисов с новым mss точно будут верными.
Но wifi клиенты могут использовать старые (текущие) сессии как вы верно заметили.
Если это будет проблемой, то можно килять все открытые сессии в сторону того сервиса с которым скрипт выявил проблему, в случае если снижение mss помогло (если сработал fetch с пониженным mss, а на исходном повышенном выдавал ошибку):
:local serviceIp "1.2.3.4" /ip firewall connection remove [find where dst-address~"$serviceIp"]
проверял на входящих пакетах вручную, MSS прилетает измененный
периодическая недоступность сервисов была до существования этих скриптов и послужила как раз основанием для данной работы и данных скриптов. По факту % недоступности в сутки стал существенно меньше, чем при статическом MTU и MSS. То что это DPI доказывает мгновенное восстановление доступности до сервисов после получения нового ip на LTE модеме
Fetch по любому каждый раз устанавливает новое соединение, т.ч. результаты автоматизированной проверки сервисов с новым mss точно будут верными.
Но wifi клиенты могут использовать старые (текущие) сессии как вы верно заметили.
Если это будет проблемой, то можно килять все открытые сессии в сторону того сервиса с которым скрипт выявил проблему, в случае если снижение mss помогло (если сработал fetch с пониженным mss, а на исходном повышенном выдавал ошибку):
:local serviceIp "1.2.3.4"
/ip firewall connection remove [find where dst-address~"$serviceIp"]
в курсе, он для новых соединений и работает
проверял на входящих пакетах вручную, MSS прилетает измененный
периодическая недоступность сервисов была до существования этих скриптов и послужила как раз основанием для данной работы и данных скриптов. По факту % недоступности в сутки стал существенно меньше, чем при статическом MTU и MSS. То что это DPI доказывает мгновенное восстановление доступности до сервисов после получения нового ip на LTE модеме