Мониторинг и управление качеством мобильного интернета на микротике

[ALxMrk]

Отличное руководство по стабилизации мобильного интернета через LTE на микротике. Ты описал целую систему:

— Адаптивное управление MSS в реальном времени (скрипт каждые 5 сек проверяет ошибки TCP и подкручивает размер пакета) — Мониторинг ключевых сервисов с автоматической реакцией (если упал 4pda или базовые чеки — сброс MSS или перезагрузка модема) — Сбор статистики и отправка в телегу + гугл-таблицы для анализа эффективности разных версий скриптов

Главный плюс — подход не «включил и забыл», а с обратной связью: система сама подстраивается под качество канала, а ты видишь метрики и можешь оптимизировать параметры.

Единственное замечание: перезагрузка модема каждые 3 минуты при проблемах — это жёстко. Можно попробовать сначала мягче: режим полёта через AT-команду (AT+CFUN=0 / AT+CFUN=1) — быстрее и меньше раздражает подключённых пользователей.

А так — рабочая схема для тех, у кого в деревне только сотовый интернет. Респект за детализаци

[0ka]

Каким образом изменение MSS влияет на "качество интернета"? Только в худшую сторону? Вы в курсе протокола QUIC и того что MSS нельзя менять для уже установленных соединений? Вы проверяли что ваше изменение MSS работает? (В wireshark должно быть видно измененный MSS на входящих пакетах, обычно для этого нужно два правила, у вас одно, не знаю нужно ли в микроте второе)

Что ещё за за "DPI блокировка оператора"? Мне кажется тут не блокировка от оператора, а вы себе что-то сломали и скриптом только ухудшаете качество интернета

[occ2]

1. в курсе, он для новых соединений и работает

2. проверял на входящих пакетах вручную, MSS прилетает измененный

3. периодическая недоступность сервисов была до существования этих скриптов и послужила как раз основанием для данной работы и данных скриптов. По факту % недоступности в сутки стал существенно меньше, чем при статическом MTU и MSS. То что это DPI доказывает мгновенное восстановление доступности до сервисов после получения нового ip на LTE модеме

[occ2]

Fetch по любому каждый раз устанавливает новое соединение, т.ч. результаты автоматизированной проверки сервисов с новым mss точно будут верными.

Но wifi клиенты могут использовать старые (текущие) сессии как вы верно заметили.

Если это будет проблемой, то можно килять все открытые сессии в сторону того сервиса с которым скрипт выявил проблему, в случае если снижение mss помогло (если сработал fetch с пониженным mss, а на исходном повышенном выдавал ошибку):

:local serviceIp "1.2.3.4"
/ip firewall connection remove [find where dst-address~"$serviceIp"]