Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

[j131]

Jeszcze jedno przyszło mi do głowy.

Na OpenWRT jest dostępny także inny, poza igmpproxy program o podobnej funkcji. Nazywa się to omcproxy i w zasadzie nie wymaga konfiguracji. W szczególności może się obyć bez odpowiedników "altnet" i bez adresu IP na vlan 839. Jedyna niepewność to fakt że preferuje IGMPv3. Nie wiadomo więc czy będzie współpracował z Orange, bo IGMPv2 są tu obligatoryjne.

Nie mam jak tego sprawdzić w prosty sposób, bo nie uśmiecha mi się kompilacja tego pakietu tylko dla takiego testu. Ale na OpenWRT on jest natywnie dostępny i wspierany, więc jeśli chciałbyś wypłynąć na nieznane wody, to możesz spróbować z nim zamiast igmpproxy. A nuż zadziała?

[raduspl]

Właśnie poczytałem o omcproxy na forach, jest wstecznie kompatybilne z IFGMv2/v3 plus dodatkowo zawiera MLDv2 (multicast w sieciach IPv6). Czy zastosowanie jego mam sens? Ale oczywiści żyłka poznawcza zadziała i w niedalekiej przyszłości (może nawet w weekend) spróbuję. Muszę tylko ogarnąć backup'y z routera, bo oficjalna nakładka nie daje takiej możliwość a ta wykonana w luci nie gwarantuje przywrócenia ustawień i każdy pad (co przy testowaniu zdarza się regularnie) to żmudne odtwarzanie ustawień od początku. No i bunt domowników, gdy nagle muszą przerzucić się na DVB-T...

Generalnie piszą, że interfejs IPTV musi mieć przypisany jakikolwiek adres IP aby kernel Linuksa w ogóle podniósł warstwę sieciową i pozwolił demonowi omcproxy (lub igmpproxy) na zbieranie pakietów a w samym routingu multicastowym (IGMP) adres IP nie bierze udziału (routowaniu obrazu) – router nasłuchuje na tym interfejsie zapytań o dołączenie do grupy multicastowej (IGMP Join) i przesyła je dalej. Separacja  (odłączenie VLAN 838 na interfejsie IPTV) odciąża router od niepotrzebnego ruchu i mostkowania co faktycznie zauważyłem (monitoruję w homeassistant obciążenie procesora routera).

Podsumowując - miałeś absolutną rację wskazując na uproszczenie konfiguracji.

[j131]

IPv6 się nie przyda, a skłonność do trzymania się IGMPv3 będzie na pewno przeszkadzała. Ale nie sprawdzisz, się nie dowiesz.
Od siebie dodam, że zrobiłem właśnie kilka testów, i ten adres jest jednak mocno umocowany w działaniach jądra. Bez adresu na interfejsie jądro linuxa zachowuje się inaczej niż kiedy jakiś adres jest. Inicjacja strumienia (IGMPv2 etc.) jest calkowicie możliwa bez IP, Orange akceptuje pakiety IGMPv2 w których adres źródłowy jest nawet wyzerowany (to sprawdziłem). Ale schody zaczynają się przy odbiorze pakietów. Jeśli nie ma IP, to albo trasy z adresów źródłowych są potrzebne na tym samym interfejsie, albo modyfikacje rp_filter albo jedno i drugie, przy czym cały czas trzeba pilnować żeby IGMPv3 się nie włączył zamiast v2. Generalnie gra niewarta świeczki. Samo igmpproxy dałoby się zmodyfikować dość łatwo, ale problemu by to nie rozwiązało. OpenWRT używa jednak jądra serii 6 (ja jestem na 5.15) może tam zasady są nieco inne (choć wątpię). Tak czy inaczej - powodzenia w testowaniu.

[raduspl]

W nawiązaniu do testów, wypracowałem taką minimalistyczną konfigurację, przy której IPTV Orange działa (pojawił się zauważalny dłuższy start strumienia po włączeniu zasilania, później już to nie występuje).

O stabilności rozwiązania na pewno wkrótce poinformuje mnie rodzina 😉

Zmiany w porównaniu do poprzedniej konfiguracji, to: podmiana igmpproxy na omcproxy.

Konfiguracja:

omcproxy:

   config homeworker
   option core_omcproxy '1'

config proxy
   option name 'iptv_proxy'
   option scope 'global'
   option uplink 'iptv'
   list downlink 'lan'

network iptv:

config interface 'iptv'
   option proto 'none'
   option device 'eth0.839'

W tle oczywiście IGMP Snooping - wstecznie kompatybilny v3 (po wymuszeniu v2 też działa), Firewall bez zmian. Po wprowadzeniu zmian niezbędny jest zimny start dekodera.

Środowisko: router GL-BE9300 (OpenWrt 23.5 na Linux 5.4.213), IWU200, Orange Love na sieci "obcej" zakończonej ONT.

[j131]

Ha! Pierwszy działający przykład IP TV Orange BEZ adresu IP na interfejsie vlan 839!
Gratulacje. Jeśli miałoby zrywać, to dość szybko by się to działo, w minutach, nie w godzinach. Obstawiam że będzie stabilnie.

[j131]

Mógłbyś w wolnej chwili sprawdzić jak masz ustawiony rp_filter?

np. coś takiego:

cat /proc/sys/net/ipv4/conf/all/rp_filter 
cat /proc/sys/net/ipv4/conf/default/rp_filter
cat /proc/sys/net/ipv4/conf/iptv/rp_filter

[raduspl]

cat /proc/sys/net/ipv4/conf/all/rp_filter
0

cat /proc/sys/net/ipv4/conf/default/rp_filter
0

cat /proc/sys/net/ipv4/conf/iptv/rp_filter
cat: can't open '/proc/sys/net/ipv4/conf/iptv/rp_filter': No such file or directory

Odwzorowałem to o co pytałeś, ale:

sysctl -a | grep rp_filter

podaje wynik 0 dla każdej sieci ipv4 LAN

[j131]

Dokładnie tego się spodziewałem. Linux, zwłaszcza w roli rutera często ma tam "2" a nie "0", i wtedy pakiety przychodzące na interfejs bezadresowy nie przechodzą kontroli którą to ustawienie implikuje.

Jest to kontrola "odwrotnej ścieżki", czyli sprawdzenie czy istnieje trasa (nawet tylko teoretycznie) prowadząca do źródła pakietu. Ponieważ takiej specyficznej trasy dla 10/10 normalnie nie ma, używana jest domyślna, ale ponieważ domyślna nie idzie przez interfejs z którego przychodzi pakiet, pakiet nie jest przepuszczany dalej.
Gdyby komuś chodziło po głowie zmienianie tego parametru to warto o tej wysoce nieoczywistej zależności pamiętać. Jeśli jest adres (jakikolwiek) - wystarczy jakakolwiek trasa odwrotna. Jeśli nie ma adresu trasa musi być przez ten sam interfejs (przy ustawieniu 2, przy 1 jest jeszcze bardziej restrykcyjnie, przy 0 trasy nie są sprawdzane).

To oczywiście nadal hipoteza/interpretacja obserwacji, ale wysoce prawdopodobna. Podejrzewam, że gdybyś zmienił specyficznie an vlan 839 albo na all na "2", to omcproxy przestałby sobie radzić. W tej samej konfiguracji, ale z adresem na interfejsie - znowu zaczęłoby działać (ale wtedy wszystko jedno który proxy).

Nie zachęcam cię do takich testów, bo to jednak sporo zachodu a sprawa jest właściwie rozstrzygnięta.