+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Wi-Fi мост между bbox и IPTV

Wi-Fi мост между bbox и IPTV, RouterOS

orel

Guest

16.06.2022 12:56:00

Привет! Пытаюсь настроить Wi-Fi мост между модемом/роутером моего провайдера и IPTV-приставкой, которую тоже выдает провайдер. Конфигурация, которую хочу сделать, похожа на Bridging Networks с SXT, потому что для работы IPTV-приставка должна быть в той же сети, что и модем/роутер провайдера. Раньше использовал PLC-адаптеры, но соединение было нестабильным.

Моя схема выглядит так:
ISP модем/роутер <-- через Ethernet --> hAPac3 <-- по Wi-Fi --> hAPac2 <-- через Ethernet --> IPTV-приставка.

На hAPac2 сеть работает нормально (приложения вроде Netflix и Molotov запускаются, пинг до LAN и интернета проходит), но IPTV-приставка не подключается к модему/роутеру провайдера.

На обоих MikroTik-роутерах нет фильтров по фаерволу, NAT выключен, DHCP-сервер и клиент тоже отключены.

Детальная конфигурация:
hAPac3
[admin@hAPac3] > export hide-sensitive
/interface bridge
add admin-mac=**** auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX country=france disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik wireless-protocol=802.11 wmm-support=enabled
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX country=france disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik wireless-protocol=802.11 wmm-support=enabled
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk management-protection=allowed mode=dynamic-keys supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.1.3/24 interface=bridge network=192.168.1.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=192.168.1.254
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" disabled=yes ipsec-policy=out,none out-interface-list=WAN
/routing bfd interface
set [ find default=yes ] disabled=yes
/system identity
set name=hAPac3
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

hAPac2
[admin@hAPac2] > export hide-sensitive
/interface bridge
add admin-mac=**** auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk management-protection=allowed mode=dynamic-keys name=client supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-eC country=france disabled=no distance=indoors frequency=2447 installation=indoor mode=station-bridge security-profile=client ssid=MikroTik wireless-protocol=802.11 wmm-support=enabled
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-Ceee country=france disabled=no distance=indoors frequency=5580 installation=indoor mode=station-bridge security-profile=client ssid=MikroTik wireless-protocol=802.11 wmm-support=enabled
/ip dhcp-server
add interface=bridge name=defconf
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.1.2/24 interface=bridge network=192.168.1.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=192.168.1.254
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" disabled=yes ipsec-policy=out,none out-interface-list=WAN
/ip route
add distance=1 gateway=192.168.1.254
/routing bfd interface
set [ find default=yes ] disabled=yes
/system identity
set name=hAPac2
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Есть идеи, почему только IPTV-приставка не может подключиться?

orel

Guest

07.11.2022 21:09:00

Всем привет! Мне удалось немного продвинуться с моей проблемой с IPTV-потоком через 2 мосты Mikrotik. Я установил недостающие multicast-пакеты на двух роутерах, затем включил опцию igmp-snooping на мосту каждого из них, как указано в документации Bridge IGMP/MLD snooping, и это сработало! Но только на пару дней... Мне пришлось отключить питание в квартире и перезагрузить оба Mikrotik-моста и роутер провайдера, и с тех пор снова ничего не работает, хотя конфигурацию не менял. Тем не менее, соединение (кроме multicast) между IPTV-приставкой и роутером провайдера работает (например, Netflix работает без проблем).

Вот что я вижу на hAPac3:
[admin@hAPac3] > /interface bridge mdb print
GROUP VID PORTS BRIDGE
232.0.4.33 wlan1 bridge
239.255.3.22 wlan1 bridge
239.255.255.250 wlan1 bridge
239.255.255.251 wlan1 bridge

[admin@hAPac3] > /interface bridge monitor bridge
;;; defconf
state: enabled
current-mac-address: 2C:C8:1B:F6:C7:79
root-bridge: no
root-bridge-id: 0.00:26:86:00:00:00
root-path-cost: 10
root-port: ether1
port-count: 7
designated-port-count: 2
fast-forward: no
multicast-router: no

[admin@hAPac3] > /interface bridge port monitor [find]
interface: ether2 ether3 ether4 ether5 wlan1 wlan2 ether1
status: in-bridge in-bridge in-bridge in-bridge in-bridge in-bridge in-bridge
port-number: 4 5 6 7 1 2 3
role: disabled-port disabled-port disabled-port disabled-port designated-port designated-port root-port
edge-port: no no no no no no no
edge-port-discovery: yes yes yes yes yes yes yes
point-to-point-port: yes yes yes yes no no yes
external-fdb: no no no no no no no
sending-rstp: yes yes yes yes yes yes no
learning: no no no no yes yes yes
forwarding: no no no no yes yes yes
root-path-cost: 10
designated-bridge: 0.00:26:86:00:00:00
designated-cost: 0
designated-port-number: 1
multicast-router: no no no no no no yes

А вот что на hAPac2:
[admin@hAPac2] > /interface bridge mdb print
GROUP VID PORTS BRIDGE
232.0.4.33 ether2 bridge
239.255.3.22 ether2 bridge
239.255.255.250 ether2 bridge
239.255.255.251 ether2 bridge

[admin@hAPac2] > /interface bridge monitor bridge
;;; defconf
state: enabled
current-mac-address: DC:2C:6E:72:4D:A7
root-bridge: no
root-bridge-id: 0.00:26:86:00:00:00
root-path-cost: 20
root-port: wlan1
port-count: 7
designated-port-count: 1
fast-forward: no
multicast-router: no

[admin@hAPac2] > /interface bridge port monitor [find]
interface: ether2 ether3 ether4 ether5 wlan1 wlan2 ether1
status: in-bridge in-bridge in-bridge in-bridge in-bridge in-bridge in-bridge
port-number: 4 5 6 7 1 2 3
role: designated-port disabled-port disabled-port disabled-port root-port alternate-port disabled-port
edge-port: yes no no no no no no
edge-port-discovery: yes yes yes yes yes yes yes
point-to-point-port: yes yes yes yes no no yes
external-fdb: no no no no no no no
sending-rstp: yes yes yes yes yes yes yes
learning: yes no no no yes no no
forwarding: yes no no no yes no no
root-path-cost: 20 20
designated-bridge: 0x8000.2C:C8:1B:F6:C7:79 0x8000.2C:C8:1B:F6:C7:79
designated-cost: 10 10
designated-port-number: 1 2
multicast-router: no no no no yes no no

Есть идеи, почему multicast-трафик заблокирован?

bpwl

Guest

08.11.2022 10:44:00

Интересно, очень интересно то, как bbox-iptv работает через ptp/ptmp Wi-Fi-связь. Сам не пробовал, но волновался, как этот канал справится с «мультикастом» в Wi-Fi. Отправлять его как multicast-wifi по ptp-ссылке — точно не то, чего бы мы хотели. Контент данных может быть мультикастом, и отправитель с получателем могут его так обрабатывать, но ptp — это явно среда для одноканальной передачи (unicast). Для ptmp всё зависит от ситуации. Так что в данном случае связь между hAP ac³ и hAP ac² должна быть unicast, и то же касается IPTV-данных между bbox (модем провайдера) и IPTV-приставкой (рекордером или телевизором). Из того, что я понимаю, на ether1 hAP ac³ и ether1 hAP ac² будет мультикаст. IGMP тут сильно не поможет, если только IPTV-приставка не отключена. Если приставка включена, весь IPTV-мультикаст пойдёт по Wi-Fi. Wi-Fi-ссылка не должна переключаться на мультикаст-трансляцию (только на «базовой скорости»), иначе канал Wi-Fi быстро забьётся. Мои изначальные опасения по поводу всей сети из SXT-ссылок подробно изложены в этой интересной статье: https://www.rfc-editor.org/rfc/rfc9119.html Не уверен, по-другому ли NV2 будет работать с мультикастом. Я надеялся, что да, но, похоже, что нет: http://forum.mikrotik.com/t/nv2-routeros-and-multicast-issues/49633/1 Нужно ещё проверить? Или всё должно обрабатываться помощником мультикаста на FULL. По умолчанию стоит disabled! Теперь хотя бы понимаю, почему многие демонстрации ptp от MT используют EoIP или MPLS/VPLS поверх «AP-bridge + station bridge link», что в любом случае отлично подходит для unicast. С ROS7 появилась ещё больше вариантов туннелей.

bpwl Guest	#4 0 08.11.2022 10:50:00 На голландском, но хорошо объяснено: https://www.wirelessinfo.be/mikrotik-point-to-point-link-eoip-vs-mpls/

tangent Guest	#5 0 08.11.2022 11:07:00 Не ожидается, что это будет работать. Существующие темы: 1, 2.

bpwl

Guest

08.11.2022 15:46:00

Я не сдаюсь, хотя и не ожидаю, что это сработает. Проблем нет, если настроить только unicast. Держитесь подальше от multicast Wi-Fi в этой связке! Туннелирование решит проблему, скрывая любой multicast-трафик. Multicast Wi-Fi работает только на базовых скоростях, в одном канале, без подтверждений (ACK) и повторных передач. По умолчанию это 6 Мбит/с на интерфейсе (3 Мбит/с — реальная скорость передачи в одну сторону). Для мультикастового видео это совсем не подходит.

То, что контент мультикастовый, не значит, что точка доступа (AP) и клиентская PtP-связь должны работать через multicast. Это должно быть и есть unicast! У меня ежедневно на 20 одновременных SXT-соединениях есть 260 Мбит/с на 5 ГГц, канал 40 МГц, 2S дуплексный поток (с интерфейсной скоростью 400 Мбит/с), всё в unicast. (3 SXTsq на каждый SXT SA5, каждый на отдельном канале от SXT SA5). Я поменял всё на NV2 просто потому, что на этом месте это показало лучшие результаты. Длина линии — 200 м. Конечные пользователи получают 180 Мбит/с через hAP ac², который обеспечивает клиентское соединение.

Учтите накладные расходы туннеля. PPTP туннель уменьшит скорость до 80 Мбит/с, SSTP — ещё больше. Что находится в туннеле, не влияет на работу линка, он останется unicast. Конечно, Wi-Fi — это общий радио-ресурс. Нужно правильно настроить его под конкретное место. 20 Мбит/с потокового видео — абсолютно не проблема в такой настройке, даже для нескольких клиентов. Multicast helper может облегчить проблемы с multicast, но для этой PtP-связи он вообще не нужен. На WLAN-интерфейс Wi-Fi multicast подаваться не должен.

То, что происходит внутри туннеля, полностью скрыто от драйвера Wi-Fi. Просто обратите внимание на размер MTU, чтобы избежать фрагментации в туннеле. Если общая загруженность Wi-Fi создаёт проблемы, не забудьте изменить настройки WLAN-интерфейса и включить WMM для пакетов линка. WMM в Mikrotik НЕ активирован по умолчанию, если вы не примените какие-то mangle-правила в фаерволе (или даже в bridge), чтобы поднять приоритет с уровня best effort (priority=0) до видеоприоритета 4 или 5.

Для максимальной пропускной способности обязательно надо включить A-MSDU для этого приоритета. По умолчанию в Mikrotik он выключен. И всё это касается именно PtP-связи, независимо от того, что внутри туннеля. Включение WMM на уровне пакетов payload не поможет — это неправильное место для такой настройки. PtP-связь с приоритетом 4-5 и WMM будет иметь преимущество над обычными PtP-соединениями и клиентскими подключениями для ВСЕХ своих пакетов.

Рассказы про проблемы IPTV обычно связаны с тем, что Wi-Fi-связь работает через multicast. В этом примере ether1 на hAP ac³ и hAP ac² видят и пропускают multicast, но Wi-Fi линк AP-bridge/station-bridge никогда не должен переносить multicast из IPTV. Обратите внимание на L2 петлю, которая образуется при одновременном подключении WLAN1 и WLAN2. RSTP либо остановит одно из соединений, либо будет петля.

Возможная схема — использовать WLAN1 как обычную точку доступа, подключённую к bridge, как ether1 в hAP ac². Тогда точка доступа сможет раздавать multicast клиентам, если это нужно. При этом понятно, что WLAN2 нельзя подключать к bridge в hAP ac³ или hAP ac², иначе он будет получать multicast-пакеты. Концы туннеля подключаются к bridge, а не к Wi-Fi-линку WLAN2.

Замечание: WMM относится к 802.11, у NV2 свой QoS: https://www.yumpu.com/en/document/read/49327240/n-streme-and-nv2-mum-mikrotik

tangent

Guest

08.11.2022 16:24:00

Проблема с ограничением мультикаста в большинстве WiFi-сетей — это побочный вопрос. Да, это плохо и влияет на ситуацию, но я видел такие же проблемы, о которых упоминал в других постах, и с уникастовым VoD. Основная проблема — это протоколы потоковой передачи в реальном времени, такие как RTP и MPEG-TS поверх голого UDP, а не мультикаст. Когда у тебя поток на 20 Мбит/сек (например, полноценный ATSC или DVB-канал, упакованный в MPEG-TS), не имеет значения, что у тебя в сумме 200 Мбит/сек пропускной способности — если поток прерывается на длительное время, это становится критичным. При видео с 30 кадрами в секунду у тебя есть всего 1/30 секунды, чтобы успеть обработать каждый кадр, и если пропустишь хотя бы один — испортится где-то от полусекунды до нескольких секунд видео. В отличие от этого псевдопотоковые протоколы, такие как HLS и MPEG-DASH, позволяют сервису использовать большие буферы, чтобы маскировать подобные перебои. Вот почему ни один крупный OTT-видеосервис сейчас не использует настоящий стриминг: они знают, что большая часть их клиентов смотрит через WiFi. Я считаю, что у автора проблемы с традиционным IPTV, которое до сих пор широко распространено даже в эпоху YouTube, в основном за счет старых кабельных компаний, превратившихся в интернет-провайдеров. У них огромные вложения в инфраструктуру, рассчитанную на проводные (кабельные) подключения. Когда пытаешься протащить такие протоколы через WiFi, они не срабатывают, потому что проектировались еще до появления WiFi (конец 80-х). Я не говорю, что традиционное IPTV вообще не может работать. Просто по моему профессиональному опыту в IPTV уже около 22 лет — оно часто подводит. Но ты можешь сам попробовать. Возьми конвертер ATSC/DVB в IP типа HDHomeRun и запусти через WiFi. В чистой лаборатории все будет хорошо, но стоит только включить микроволновку, устроить танцы между роутером и приставкой IPTV или начать большой фоновой закач — сразу начнутся задержки, сбои и искажения. Псевдопоток на базе TCP ведет себя намного устойчивее, потому что у него есть буфер на 5-30 секунд, который играет, пока проблема проходит. Это подводит нас к следующей проблеме: такие IPTV-сервисы обычно просто напичканы DRM, и ты не можешь просто перепаковать их в HLS или что-то подобное, чтобы обойти проблему как-то разумно.

orel

Guest

08.11.2022 20:50:00

Спасибо за отзыв, я не профессионал и понимаю, что мне ещё предстоит выучить пару-тройку вещей про сеть. Как только найдётся время, постараюсь попробовать идею с туннелем. В любом случае, вариант с кабелем у меня не подходит, да и PCL перестал работать после обновления прошивки...

По поводу настройки туннеля я нашёл вот эти страницы в вики: Transparently Bridge two Networks using MPLS / Transparently Bridge two Networks using MPLS extended. Кстати, когда искал документацию по теме, наткнулся на RFC, в котором говорится о мультикасте через Wi-Fi → RFC 9119 Multicast Considerations over IEEE 802 Wireless Media.

tangent

Guest

09.11.2022 08:46:00

Это увлекательная и глубокая область. «Подключи кабели и включи» — это первый шаг, а не финальный. Я постараюсь придерживаться идеи туннеля. Возможно, N-way MIMO и последний стандарт 802.1abgnxyzqrtstuv помогут твоему поезду не сойти с рельсов. Всё, что я знаю, это то, что каждый раз, когда пробовал такое в коммерческом здании из шлакоблока и арматуры, заполненном людьми с устройствами BYOD, это ломало традиционные IPTV-системы моей компании. Тем не менее, готов признать, что твоя ситуация может быть гораздо проще, чем те, с которыми мне приходится постоянно сталкиваться. В моём случае провести кабель невозможно. В мире, где существуют трансатлантические кабели, это явно преувеличение. Наверное, ты имеешь в виду, что не хочешь тянуть кабель, а не то, что это вообще невозможно. Я нашёл RFC, в котором говорится о мультикасте через Wi-Fi. Проблем с мультикастом несколько: Самые распространённые протоколы, которые его используют, имеют низкую пропускную способность. Исключения с высокой пропускной способностью, например IPTV, обычно ограничены приватными LAN; в таких случаях, как у тебя, использование кабельного модема, расположенного в стойке для развлечений, решает большую часть оставшихся проблем. Мультикаст сводится к широковещательной рассылке по проводным сетям, если специально не настроить такие сервисы, как IGMP snooping и IGMP queriers. В Wi-Fi всё является широковещательной рассылкой, так как это общий канал. Поэтому опыт настройки эффективного мультикаста по Wi-Fi «из коробки» встречается редко. Большинство игнорирует это, оставляя всё на настройках по умолчанию, пока всё не ломается окончательно.

bpwl

Guest

#10

14.11.2022 09:55:00

Всё передаётся по WiFi, который является общим средством передачи. Да, это общий канал, и с радиотехнической точки зрения отправка — это широковещательная передача. Но WiFi знает как минимум два способа передачи данных.

WiFi Unicast — передача, адресованная одному подключению по MAC-адресу, которая подтверждается получателем (ACK) или же при необходимости повторяется (с той же или более низкой скоростью интерфейса). Неудачные передачи понижают скорость MCS, успешные — повышают. Начиная с 802.11n используется MIMO с несколькими антеннами, что увеличивает скорость интерфейса (например, 400 Мбит/с на одном потоке и 866 Мбит/с на двух потоках для MCS09 в 802.11ac).

WiFi Multicast — передача, которую принимают все подключения, отправляется на базовой скорости (обычно 6 Мбит/с, если не настроено иначе) на одном потоке, при этом не подтверждается и не повторяется. Гарантии доставки, как в WiFi Unicast, нет. Получено сообщение или нет — неизвестно. IPTV и другие мультикаст/широковещательные потоки, распознаваемые драйвером WiFi как multicast/broadcast, передаются как «WiFi multicast», если не исправлены с помощью Multicast Helper и не преобразованы в «WiFi Unicast». IPTV через «WiFi multicast» идёт очень медленно (6 Мбит/с), по сравнению с «WiFi Unicast» (866 Мбит/с). Это отличается от проводных Ethernet-соединений, где unicast и multicast/broadcast работают на одинаковой скорости провода.

tangent

Guest

#11

14.11.2022 12:25:00

Я понимаю это. Просто предсказываю, что если вы повысите базовую скорость для покрытия потребностей вашего IPTV-потока, проблемы всё равно останутся. Он не подтверждается и не пересылается повторно. Для IPTV в этом нет смысла, потому что почти наверняка просто некому сообщать о потерях. Для IPTV существуют схемы восстановления ошибок с помощью прямой коррекции, но их редко используют. Гарантии доставки, как в Wifi Unicast, нет. Пришло сообщение или нет — неизвестно. Да, всё к тому: если что-то прервет хотя бы один WiFi-кадр данных, скорее всего это испортит десятки или сотни видеокадров из-за взаимозависимости кадров в современных видеокодеках. Это верно, будь то unicast, broadcast, multicast или anycast. Повреждения по проводу встречаются очень редко. А по воздуху — значительно чаще.

mkx

Guest

#12

14.11.2022 17:48:00

Подтверждения (ACK) и повторные передачи, о которых говорит @bpwl, происходят между точкой доступа и клиентом на радиоканальном уровне MAC (уровень 2). Для unicast-передач в Wi-Fi повторные передачи могут происходить на уровне 2, обеспечивая доставку правильных кадров… Такая повторная передача значительно быстрее, чем на более высоких уровнях (например, TCP, который делает повторные передачи на всем пути от источника до получателя). А вот в Wi-Fi для broadcast-передач повторные передачи невозможны. Насколько эффективен этот механизм? Я понятия не имею, как он работает в Wi-Fi, но похожие технологии (HARQ, FEC и прочее) отлично работают в 4G и 5G, они могут экономить до 20% данных, которые иначе пришлось бы пересылать на уровне 4 (или которые могли бы потеряться, если более высокие уровни не делают повторных передач). И всё это происходит за счёт увеличения задержек и джиттера. Даже большинство VoIP-систем могут выносить задержки и джиттер в несколько десятков миллисекунд, а неинтерактивный стриминг (например, мультикаст IPTV) рассчитан на задержки в секунды — благодаря буферам на десятки секунд. В таких приложениях потеря пакетов обычно плохо сказывается на качестве…

bpwl Guest	#13 0 15.11.2022 14:14:00 Коррупция данных во время передачи по проводам встречается крайне редко. По воздуху ошибок значительно больше. Но wifi-коррупция обнаруживается и исправляется (wifi unicast). Я считаю wifi unicast гарантированной доставкой пакетов, если соединение не прервано. На каждый MSDU есть контрольная сумма. Если подтверждение (ACK) не пришло, в MT происходит 7 повторных попыток на той же скорости интерфейса, если и после этого ACK нет, MT снижает скорость интерфейса и пробует ещё 7 раз. Если скорость уже минимальная (6 Мбит/с) и подтверждения все равно нет, MT повторяет попытки в течение «disconnect timeout» (по умолчанию 3 секунды) с интервалом «On fail retry time» (по умолчанию 100 мс). Если всё равно не удалось — происходит «disconnect excessive errors», и пакет, а затем и соединение обрываются. Таймаут «Frame Lifetime» тоже может сбросить пакет (но по умолчанию отключён). Смотрите разделы «What is HW retries setting» и «How to fine-tune the wireless link with hw-retries?» на https://help.mikrotik.com/docs/display/ROS/Wireless+Troubleshooting. Повышение базовой скорости для wifi multicast не имеет такой же проверки контрольной суммы и повторов, поэтому реально может приводить к пропускам или повреждениям пакетов IPTV.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры