temat OpenWRT a IPTV w Modemy i routery

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 10:57:59 GMT

Cześć,

Tworzę setup następujący:

FB łączy się jako WAN do R1 OpenWRT, na R1 tworzony jest Bridge który spina R2 i dekoder UHD100.
R2 tworzy mesh z R1 i dodatkowo łączy się kablem do dekodera HD80 i R3 (tu już tylko mesh i nie istotny w konfiguracji).

Na R1 tworzę wan w stronę FB, w bridgu jest VLAN dla Wi-Fi (osobny nie powiązany z FB) oraz IPTV.

Na początek moim celem jest tylko uruchomić to w ramach tego designu na R1 i UHD.

Zone są narazie odblokowane w celu uproszczenia.

root@R1:~# cat /etc/config/igmpproxy 
config igmpproxy
	option quickleave 1
#	option verbose [0-3](none, minimal[default], more, maximum)

config phyint
	option network wan
	option zone wan
	option direction upstream
	list altnet 0.0.0.0/0

config phyint
	option network iptv
	option zone iptv
	option direction downstream

root@R1:~# cat /etc/config/network 

...

config device
	option name 'br-lan'
	option type 'bridge'
	option igmp_snooping '1'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan'
	option proto 'none'

...

config interface 'wan'
	option proto 'static'
	option device 'wan'
	option ipaddr '192.168.1.2'
	option netmask '255.255.255.0'
	option gateway '192.168.1.1'

...

config route
	option target '0.0.0.0/0'
	option gateway '192.168.1.1'

config interface 'Users'
	option proto 'static'
	option device 'br-lan.20'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'
	list dns '192.168.1.1'
	list dns '8.8.8.8'

config bridge-vlan
	option device 'br-lan'
	option vlan '30'
	list ports 'lan2:t'
	list ports 'lan3'

config interface 'iptv'
	option device 'br-lan.30'
	option proto 'static'
	option ipaddr '192.168.30.1'
	option netmask '255.255.255.0'
	list dns '8.8.8.8'
	list dns '192.168.1.1'
	option gateway '192.168.1.1'

root@R1:~# cat /etc/config/firewall 

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option synflood_protect '1'

config zone
	option name 'wan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option mtu_fix '1'
	option masq '1'
	list network 'wan'

...


config zone
	option name 'iptv'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'iptv'

config forwarding
	option src 'iptv'
	option dest 'wan'

config rule
	option dest 'wan'
	option name 'IPTV'
	option proto 'igmp'
	option target 'ACCEPT'
	option src 'iptv'

config rule
	option src 'wan'
	option dest 'iptv'
	list dest_ip '224.0.0.0/4'
	option target 'ACCEPT'
	option proto 'udp'

Oczywiście konfiguracja nie działa. Słyszałem że normalnie działa między WAN a LAN. Czy jest jakaś różnica między VLAN, nie wydaje mi się bo wychodzi do dekodera jako Untagged

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 13:24:27 GMT

Co to jest R1 i R2?

Co to za dekoder UHD100?

Zdefiniowałbym altnet dokładniej, jako 10/10. Pamiętam że bez tego igmpproxy nie chciało przerzucać pakietów. Ale to był inny system. Adresów multicast chyba się do zapory nie dodaje, ale to nie powinno przeszkadzać.

Może ktoś lepiej zorientowany w tym systemie zobaczy w czym może być problem.

Generalnie zacząłbym od mniej skomplikowanego układu, dwie podsieci z ruterem między nimi, dwie adresacje z maskaradą i igmpproxy na tym ruterze.

Czy w tej konfiguracji internet działa normalnie i tylko z IPTV jest problem?

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 13:11:39 GMT

R1 to router (Cudy WR3000s) który terminuje VLANy ogarnia NATy i resztę usług, R2 pełni bardziej formę L3 Switcha ale nie jest on w zakresie pytania bo jak uda się rozwiązać problem z R1 to R2 ogarnę na spokojnie.

Samsung ICU100


┌──────────────────────────┐
│ Funbox                   │
│                          |
└─────────────┬────────────┘
              │
              │
              │
       ┌──────┴────────┐ 
       │      R1       │
       │    OpenWRT    │
       │     br-lan    │
       └─────┬─────────┘
             │
  ┌──────────┴──────────┐
  │                     │
  │                     │
  ▼                     ▼
lan2 (TRUNK)       lan3 (ACCESS)
tag 20, tag 30        untag 30
  │                     │
  │                     │
  │                     │
  │               ┌─────┴────┐
  │               │ Dekoder  │
  │               └──────────┘
  │
  │ trunk VLAN20 + VLAN30
  ▼
┌─────────┐
│ R2      │
│ OpenWRT │
│         │ 
└─────────┘

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 13:13:45 GMT

A, to tu jest więcej "ruterów"... OK, to tylko się upewnię: do światłowodu podłączony jest ruter operatora (Funbox), czy jakiś własny? Pomiędzy FB a ICU100 jest więc jeszcze R1 i R2 czy tylko R1? Konfigurujemy R1 czy R2 też? Bo jeśli pakiety multicast nie przechodzą przez R2 (a nie będą przechodzić jeśli R2 jest ruterem ich nieświadomym, no chyba że R2 jest tylko switchem, to wtedy nie nazywajmy go ruterem...).

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 13:17:09 GMT

Dodałem Diagram dla wizualizacji.

Tak w tym setupie nie ma problemu z internetem z VLANu 20.

Fizycznie urządzenia sieciowe też mają dostęp do internetu

Ze względu że jest to stary dom z grubymi ścianami VLANy to jedyna opcja dociągnąć telewizję i Internet. Za R2 będzie drugi dekoder i dalej rozciągać się Internet w ramach vlan20 ale to inna sprawa już 😃

Światłowód wchodzi do FB z niego przechodzi standarodwym swoim lanem do portu WAN na R1 i tam chcę żeby cała sieć lokalna pracowała a FB był tylko transitem do internetu. Z IPTV chyba nie dam rady i musi to być przez FB?

---------------------------------------

Scaliłem wpisy - Mikołaj

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 13:22:55 GMT

Musi być FB jeśli nie masz ONT, tak czy inaczej. Gdybyś miał ONT, FB nie byłby potrzebny - konfiguracja IPTV na OpenWRT została wielokrotnie sprawdzona i to po prostu działa.
No ale skoro nie ma ONT to kombinujesz bardzo rozsądnie. Być może to mostkowanie w czymś przeszkadza, nie jestem pewien. Generalnie kluczowy w tym układzie jest igmpproxy, on ma zwodniczo ubogą konfigurację, ale tylko jedną poprawną.

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 13:39:00 GMT

Sugerujesz rozpiąć interface i zostawić testowo LAN3 jako osobny subnet i go zamieścić w proxy?

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 13:55:25 GMT

Tak bym zrobił, przynajmniej testowo. Byle ten lan3 dostawał też normalny ruch (ale to powinien załatwić forwarding - przecież normalnie na ruterze jest włączony).

To co widzisz to dekoder próbujący wyłączyć program TVP 2. Jakoś mu to jednak nie wychodzi - może faktycznie pakiety igmp nie wychodzą do FB... Tylko co je blokuje? Na WAN nic się nie pojawia? Strumień UDP z jakichś adresów 10/10 do tych właśnie grup multicast o które dekoder się upomni powinien się tam pojawić. Ten "multicast" w sensie strumienia danych IP TV jest stricte jednokierunkowy: idzie z WAN do LAN (tutaj powinien iść od strony FB, z jakiegoś adresu w klasie 10/10) do lan3, ale zaadresowany nie do dekodera oczywiście tylko do grupy multicast. Stąd tak kluczowa jest konfiguracja igmpproxy - to jedyne miejsce w którym można określić dokąd mają trafiać te pakiety udp, one nie podlegają przecież normalnemu trasowaniu - utykają na pierwszym ruterze który nie wie co z nimi zrobić. Natomiast pakiety kontrolne igmp v2 (koniecznie v2, nie v1 i nie v3; może to jest konfigurowalne) muszą się przemieszczać w obie strony. No i jest jeszcze ruch tcpip z dekodera do serwerów autoryzacyjnych w internecie - tego jest więcej niż pakietów igmp (ale to chyba akurat działa).

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 13:40:10 GMT

Po rozpięciu płynie multi cast przez Lan3, ale nie wychodzi do WAN...

połączenie do Internetu wracają, jest prawidłowy TCP dla niego

listening on lan3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:36:56.785225 IP 192.168.2.116 > all-routers.mcast.net: igmp leave 232.0.18.8
13:36:57.354523 IP 192.168.2.116 > 232.0.18.8: igmp v2 report 232.0.18.8
13:37:00.014221 IP 192.168.2.116 > 232.0.18.8: igmp v2 report 232.0.18.8
13:37:00.387459 IP 192.168.2.116 > all-routers.mcast.net: igmp leave 232.0.18.8
13:37:00.959764 IP 192.168.2.116 > 232.0.18.8: igmp v2 report 232.0.18.8
13:37:03.994060 IP 192.168.2.116 > all-routers.mcast.net: igmp leave 232.0.18.8
13:37:04.254483 IP 192.168.2.116.51017 > 239.255.255.250.1900: UDP, length 137
13:37:04.568078 IP 192.168.2.116 > 232.0.18.8: igmp v2 report 232.0.18.8
13:37:07.603438 IP 192.168.2.116 > all-routers.mcast.net: igmp leave 232.0.18.8

Czy ta konfiguracja igmp jest prawidłowa?

config igmpproxy
        option quickleave 1
#       option verbose [0-3](none, minimal[default], more, maximum)

config phyint
        option network wan
        option zone wan
        option direction upstream
        list altnet 10.0.0.0/10

config phyint
        option network tv
        option zone tv
        option direction downstream

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 14:24:10 GMT

Problem częściowo rozwiązany, mimo że pisało w luci że igmpporxy jest zainstalowany to nie było binarki w /usr/sbin.

Ponowna instalacja z konsoli sprawiła przepływ multicastu przez WAN. Zaczynam teraz test z VLAN

Edit:

VLAN też działa. Zaczynam przepuszczenie do R2 i drugiego dekodera

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 16:33:20 GMT

No, to teraz już będzie z górki. Powodzenia.

PS. Zaraz, zaraz: a ten drugi dekoder to jaki model? Bo jeśli nie któryś z tej trójki: Multi 4k, ICU100, IWU200, to nie potrzebuje on niczego poza internetem. Jeśli to jednak któryś z tej trójki to pamiętaj o wspieraniu igmpsnooping na wszystkich węzłach po drodze. No i oczywiście coś musi te pakiety szuflować (pewnie igmpproxy), jeśli sieć nie jest płaska.

OpenWRT a IPTV

OVDC — Wed, 17 Jun 2026 20:22:11 GMT

Drugi to WHD80, to by wyjaśniało czemu działał w innym subnecie bez spoofingu.

Tak teraz to już z górki, może komuś się kiedyś przyda aby sprawdzać sbin 🙂

Dzięki za wsparcie

OpenWRT a IPTV

j131 — Wed, 17 Jun 2026 20:53:41 GMT

A, no to staroć to o nim nic nie wiem - już takich dawno nie dają. No ale on jednak też chyba chodził tak jak ta trójka, musiał mieć multicast skonfigurowany. To jeszcze sprzęt z czasów kiedy i DTH (czyli satelitarna TV) na tym samym dekoderze była oferowana.
Swoją drogą ciekawe jak sobie z nim poradzisz, bo jeszcze nikt akurat z tym dekoderem nie walczył z konfiguracją IP TV w podsieci, a przynajmniej nie pochwalił się na forum.

OpenWRT a IPTV

OVDC — Thu, 18 Jun 2026 20:19:10 GMT

Ogólnie to jakieś cuda na kiju się dzieją z tym WHD80 😄

VLAN podłączony do dekodera i dostęp do internetu wystarczy, działa bez IGMP.

Ale hitem jest to że wzrost hitcnt jest po stronie br-lan a nie po stronie vlan.

tcpdump na lan2 (połączenie fizyczne w stronę dekodera) mimo użycia tcpdump z -e pokazuje tylko i wyłącznie igmp od dekodera.

A tcpdump z br-lan który zawiera połączenie do R1 i drugiego dekodera nie pokazuje za dużo pakietów (a przypuszczam że ich trochę powinno być przy live streamingu)

root@OpenWrt:~# tcpdump -i br-lan -e not net 192.168.20.0/24
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:24:40.587876 80:af:ca:7f:ef:98 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 118: fe80::82af:caff:fe7f:ef98 > ip6-allnodes: ICMP6, router advertisement, length 64
19:24:40.854834 80:af:ca:7f:ef:98 (oui Unknown) > 33:33:00:01:00:03 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::82af:caff:fe7f:ef98 > ff05::1:3: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff05::1:3, length 24
19:24:41.325644 80:af:ca:7f:ee:44 (oui Unknown) > 01:00:5e:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.1 > all-systems.mcast.net: igmp query v2
19:24:41.981864 60:c5:ad:ab:04:0b (oui Unknown) > 01:00:5e:7f:ff:fa (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.116 > 239.255.255.250: igmp v2 report 239.255.255.250
19:24:46.211731 18:1e:78:ec:93:c6 (oui Unknown) > 01:00:5e:00:13:34 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.203 > 232.0.19.52: igmp v2 report 232.0.19.52
19:24:47.254822 80:af:ca:7f:ef:98 (oui Unknown) > 33:33:00:01:00:02 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::82af:caff:fe7f:ef98 > ff02::1:2: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:2, length 24
19:24:50.262126 60:c5:ad:ab:04:0b (oui Unknown) > 01:00:5e:00:13:43 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.116 > 232.0.19.67: igmp v2 report 232.0.19.67
19:24:52.218001 fe:17:fa:18:36:3d (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype 802.1Q (0x8100), length 90: vlan 20, p 0, ethertype IPv6 (0x86dd), fe80::188e:deee:fce0:933f > ff02::fb: HBH ICMP6, multicast listener donemax resp delay: 0 addr: ff02::fb, length 24
19:24:53.265553 80:af:ca:7f:ee:44 (oui Unknown) > 01:00:5e:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.1 > all-systems.mcast.net: igmp query v2
19:24:54.290345 60:c5:ad:ab:04:0b (oui Unknown) > 01:00:5e:00:13:43 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.116 > 232.0.19.67: igmp v2 report 232.0.19.67
19:24:56.708424 18:1e:78:ec:93:c6 (oui Unknown) > 01:00:5e:00:13:34 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4 (0x0800), 192.168.30.203 > 232.0.19.52: igmp v2 report 232.0.19.52

@j131 może ty masz na to jakiś pomysł w jaki sposób się komunikuje drugi dekoder (192.168.30.206)

Po restarcie pojawił się 10/10 i UDP.

Jednak zastanawia mnie czemu na R1 widzę ruch UDP na fizycznym interface (lan3) ale na R2 w kierunku WHD80 nie widzę na fizycznym (lan2). Może to klejny błąd w OpenWRT bo ostatnio dużo ich

OpenWRT a IPTV

j131 — Sat, 20 Jun 2026 07:33:30 GMT

IPTV w multicast nie używa w ogóle ipv6. Niestety zaraz wyjeżdżam na urlop, więc się nad tym nie mam w tej chwili czasu pochylić, ale czytam twoje posty z dużym zainteresowaniem. Pierwsza hipoteza byłaby taka że on w ogóle nie używa mutlicast i normalnie bierze strumień z internetu, ale nie wiem czy to ma sens. Wtedy komunikacja jast w tcp/https, nie udp.
To stary dekoder i być może używa jakiegoś jeszcze innego triku. Ale w pierwszej kolejności odciąłbym mu całkiem dostęp do multicast - jeśli TV nadal działa to sprawa jest jasna.

Tcpdump w domyśle nie pokazuje tych pakietów wcale, trzeba starannie dobrać opcje. Adresatem nie jest dekoder, nadawcą nie jest ruter... Najlepiej widać to jeśli po prostu każesz sobie wszystko co leci na danym interfejsie pokazać gdy dekoder puszcza obraz na TV - wtedy na pewno zobaczysz te pakiety - i przede wszystkim te pakiety; jest ich cała masa.

A, o oczywistej oczywistości chyba wiesz: jest około pół minuty przesunięcia w czasie między sygnałem multicast a unicast. To dużo więcej niż drobne narzuty sprzętowe, więc jako podpowiedź może posłużyć. Jednoznacznie szybszy jest multicast.

---------------------------------------

Scaliłem wpisy - Mikołaj