беспроводной мост между двумя Mikrotik для IPTV приставки

Всем привет. В попытках глубже разобраться я несколько недель тестировал разные схемы, чтобы получить надёжный беспроводной мост уровня L2. Успешные решения, которые я протестировал: BCP-бридж в PPTP-туннеле по Wi-Fi-соединению, мост с использованием WDS в режиме station-wds. К сожалению, тот вариант, с которого я интуитивно начал — режим station-bridge — похоже, не работает и не может установить беспроводной мост второго уровня, способный функционировать с моим IPTV-приставкой. Я пробовал неделями, но безуспешно. Конфигурация представлена в начале ветки. Хотелось бы понять, что я делаю не так или так и должно быть. Судя по инструкции, режим station-bridge должен работать в моём сетапе, но я никак не могу понять, почему нет. Буду очень благодарен за экспертную помощь в попытке разобраться, почему station-bridge не работает, а BCP-бридж в PPTP и station-wds оба функционируют. Под "работает" я имею в виду способность обеспечивать L2-мост для Ethernet-пакетов моему IPTV-приставке. Спасибо заранее!

Хочу верить, что я не сумасшедший, спасибо, что спросили! Возможно, я не совсем ясно объяснил, и поэтому у вас сложилось впечатление, что я требую каких-то «особенных» вещей… Попробую упростить до максимума. Я пытаюсь сделать надёжный беспроводной L2 мост внутри квартиры (расстояние пару метров), который сможет передавать Ethernet-пакеты для IPTV-приставки. Это IPTV от провайдера. Требуется около 3 Мбит/с. По стандартным рекомендациям провайдера приставка должна быть напрямую подключена к роутеру провайдера через Ethernet-кабель. Я же хочу сделать так, чтобы это работало по беспроводной связи внутри квартиры, поэтому мне нужен мост между приставкой и роутером провайдера. Для этого в середине стоят два Mikrotik. Как я уже сказал, это можно реализовать через BCP-бридж поверх PPTP или в режиме station-wds, но никак не получается через station-bridge. Я не на 100% уверен, что station-bridge вообще должен работать, но, насколько я понимаю, должен — поэтому пытаюсь понять, что не так с моей конфигурацией или…? Главное, что меня тревожит — почему этот мост не работает в режиме station-bridge? По технологиям, которые использует ISP, я правда не уверен. Возможно, кто-то здесь знает лучше. Сервис называется MaxTV, провайдер — Croatian Telekom.

Ты слишком упростил вопрос, и теперь я могу дать только общие советы, а не практическую помощь. Я не боюсь глубоких технических деталей — выкладывай. По рекомендациям провайдера, приставка должна быть напрямую подключена к роутеру провайдера по Ethernet-кабелю. Потому что твой провайдер понимает то, что я: традиционный IPTV в режиме реального времени по WiFi — это безумие. К тому же, у них есть гораздо больший и горький опыт, который подтверждает этот вывод.

Что касается технологии, которую использует провайдер, я точно не уверен. Запиши несколько секунд одного из этих потоков и выложи его где-нибудь на публичный сервер. Я или кто-то с моими навыками сможет тогда рассказать подробнее. Попробуй зафиксировать смену канала, если получится. С современными видеокодеками вопрос не «если», а «когда» это произойдет на практике.

Если предположить, что источник IPTV передает видео в HD качестве с битрейтом всего 3 Мбит/сек, то размер GOP (группа кадров) вероятно большой. Для современных интернет-видео 300 кадров — обычное дело. (Отсюда цифра «297» из моего предыдущего сообщения — потеря 3 кадров из 300 в GOP. Это 10 секунд видео при 30 кадрах в секунду, что дает среднюю потерю 5 секунд видео при случайной потере одного пакета.) В представленном рисунке указана «типичная» структура, но под этим понимается IPBB структура, а не GOP из 6 кадров, как показано.

Даже у MPEG-2 — технологии до эпохи DVD — размер GOP редко меньше полусекунды, то есть 12 кадров для 24/25 fps или 15 кадров для 30 fps. Этот полусекундный ориентир основан на тестах при создании MPEG-1 в конце 1980-х, которые показали, что длинные GOP нежелательны из-за накопления ошибок: межкадровые кодеки требуют периодической синхронизации I-кадрами для поддержания высокого качества воспроизведения. Большая часть улучшений, которые дают H.264, VP9 и подобные кодеки — это снижение накопления ошибок внутри GOP, что позволяет использовать более длинные GOP при сохранении качества и реже вставлять дорогие I-кадры. Для интернет-потоков 300 кадров в GOP — норма.

Мультикаст-пакеты передаются на самой низкой разрешенной скорости (в MT это называется базовой скоростью). А, вот это интересно. Я встречал другие WiFi-роутеры с такой функцией, но MT у меня только для проводных подключений, поэтому не знал, что они тоже так делают. Делается это для того, чтобы через сеть пропускались протоколы с низкой скоростью передачи данных, например mDNS, но при этом предотвращать засорение ценного общего канала вещания, которым является WiFi, такими нагрузками, как IPTV. Люди, которые проектируют эти WiFi-роутеры, тоже понимают, что IPTV по WiFi — это безумие.

Для тех, кто еще сомневается: вам никогда не попадалось плохое качество VoIP через WiFi? А ведь у него те же требования к реальному времени, что и у IPTV, но при гораздо меньших объемах данных и меньшей взаимозависимости между пакетами. Если вы не можете обеспечить стабильную и надежную VoIP-связь по WiFi, почему бы вам ожидать этого от IPTV?

Если интересно, почему работают YouTube, Netflix и тому подобные сервисы — это вовсе не IPTV. Это видео по запросу с большими буферами на стороне пользователя. Что касается Twitch, Zoom и подобных — это тоже системы хранения и пересылки, совершенно не такие, как потоковое вещание IPTV в реальном времени; как и VoD, они транслируют видео в режиме unicast с большими буферами по сравнению с теми, которые обычно используются в IPTV. IPTV создавался в эпоху, когда полусекундные GOP MPEG-2 занимали немало памяти, поэтому у IPTV-приставок не было мультисекундных буферов, как у Roku или аналогичных устройств.

Это точечные соединения, так что правила маршрутизатора для мультикаст-трафика тут не работают. Это юникаст-ссылки, на которые не влияют настройки «basic-rates», о которых говорил mkx. Так что да, можно убрать ограничения по скорости мультикаста — и, возможно, всё пойдёт… пока один из маршрутизаторов не уйдёт за линию прямой видимости, или дистанция не превысит пару метров, или в сеть не зайдёт больше клиентов, или кто-то не решит покопаться в Reddit на том же WiFi-канале, или мимо маршрутизаторов не пробежит кто-то из этих странных существ, состоящих в основном из воды, или… Но что я могу понять, я же всего лишь занимаюсь IPTV уже десятки лет…

Не совсем так, это ограничение не зависит от содержимого, оно одинаково для всех multicast и broadcast. И именно по той причине, что я уже писал: эти пакеты должны быть доставлены всем клиентам. Поскольку это широковещательная рассылка (multicast уровня L2 не существует — в ethernet/wireless, L3 - IP, multicast просто отображается в L2 broadcast), а адаптация канала (изменение модуляции, MIMO ранга, мощности передачи и т.д.) невозможна (потому что она одинаковая для всех клиентов, а для тех, кто недавно спал, условия радиоканала неизвестны). Поэтому все broadcast и multicast передаются на максимально медленной скорости. Если это изменить (например, разрешить только g/n на 2.4 ГГц, поднять минимальную скорость), то радиус действия точки доступа уменьшится. Это просто физика.

Хорошее замечание, mkx! Наверное, это часть человеческой природы, но учиться всю жизнь просто необходимо! Mkx, огромное спасибо за то, что делишься своими знаниями! Возможно, моя база в сетевых технологиях гораздо ниже твоего уровня, поэтому я не всегда всё понимаю полностью. Но кажется, что здесь я получаю отличные ответы, которые объясняют, почему мои изначальные ожидания были, наверное, слишком высоки. Спасибо!

Привет, tangent! Огромное спасибо за ценные комментарии!! Я настоящий новичок, честно говоря, не до конца понимаю все тонкости, о которых ты говоришь. Суть я уловил — с Wi-Fi в плане мультикаста действительно много проблем. Спасибо, что пояснил.

P.S. Для других читателей, которые не гуру IPTV: правильно ли будет сказать, что если Wi-Fi — не единственный вариант для IPTV, то лучше его избегать? И если Wi-Fi всё же необходим для IPTV, то хорошей практикой будет организовать туннель поверх Wi-Fi и использовать BCP bridging внутри? @mkx и @tangent, что вы думаете?

Дорогой @tangent, вот захваченные пакеты https://we.tl/t-UdWyYxpwkW. Прошу прощения, что не приложил их раньше, но я много тестировал и теперь отправляю пакеты, которые, на мой взгляд, вызывают наибольшие проблемы. Есть переключение канала, а также переход к просмотру «старой» программы — на пару часов назад от реального времени. Сервис на некоторых каналах дает возможность смотреть всё, что было за последние два дня. Я заметил, что именно это особенно провоцирует проблемы с качеством, поэтому включил это в файл. Пожалуйста, дайте знать, что думаете, и ещё раз спасибо большое.