OpenWRT a IPTV

[j131]

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.

[OVDC]

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 

[j131]

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.

[OVDC]

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

[j131]

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