temat Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi w Telewizja

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

tyrytyt — Fri, 27 Feb 2026 09:46:29 GMT

Cześć wszystkim.

Czy komuś aktualnie działa IPTV na dekoderze 4K Multi z routerem z OpenWrt? Mam konfigurację zgodną z załączoną i niestety telewizja nie działa na dekoderze.

_________

* Wpis wydzielony jako nowy temat - Bartłomiej

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

ksq — Fri, 27 Feb 2026 11:23:43 GMT

Problem rozwiązany, kolega nie miał zainstalowanego pakietu igmpproxy. 🙂

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Fri, 27 Feb 2026 12:25:28 GMT

@tyrytytnapisał(-a)
...
4K Multi z routerem z OpenWrt
...

Do kombinacji IP TV + OpenWrt to najlepszym punktem odniesienia będzie ten wątek. Ten na któy się powołujesz też jest dobry, ale tak naprawdę zawiera trochę zbędnych informacji, które mogą utrudniać działanie. Tutaj są tylko rzeczy które działają, i OP skonfigurował to przy zerowym doświadczeniu z tym systemem. Polecam wszystkim.

https://nasz.orange.pl/t5/Gry-online/Problem-z-bufferbloat-i-utrata-pakiet%C3%B3w/m-p/455912#M9044

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

tyrytyt — Fri, 27 Feb 2026 15:03:05 GMT

Tak jak kolega @ksq wspomniał, problemem był brak pakietu igmpproxy. Bardzo dziękuję za pomoc 🙂

@j131 super, dziękuję za podlinkowanie, zaraz przewertuję.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Fri, 10 Jul 2026 11:58:21 GMT

Czy to rozwiązanie, oczywiście z zainstalowanym pakietem igmpproxy sprawdza się na IWU200?

Zapodałem je do LuCI, ale nie zadziałało.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Sat, 11 Jul 2026 11:35:36 GMT

Udało się dzięki opisowi @larmalarma i modyfikacji pod specyfikę OpenWRT (pola: odpowiednie zakodowanie w hex 'list sendops', rozwiązanie konfliktu routingu domyślnego z VLAN.838, dodanie do firewall zezwolenia na pakiety odnawiające dzierżawę adresu IP z niestandardowych podsieci).

Teraz najważniejsze, czy ta konfiguracja będzie działać stabilnie?

Przy okazji, sprawdziłem, że aby otrzymać adresy IPv6 nie trzeba przelogowywać się na login .../ipv6. Serwer DHCP Orane, po odpytaniu, wydaje je na standardowym loginie ale trzeba pamiętać że są one o długości /56 a nie /64. Przy tej opcji mamy publiczny adres ipv4 i ipv6.

Router: GL-BE9300.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Sat, 11 Jul 2026 23:36:24 GMT

@raduspl

Po pierwsze czy konfiguracja Twojego sprzętu będzie stabilna to nie wiem, ale u mnie analogiczna konfiguracja działa nieprzerwanie od ponad roku. Tak że od strony operatora tego typu konfiguracja jest jak najbardziej stabilna.
Co do tego "przy okazji" to proszę doprecyzuj o co chodzi, bo nie do końca zrozumiałem. Czyżbyś był w stanie w ramach jednej sesji PPPoE uzyskać zarówno publiczny adres IPv4 jak i delegację prefixu dla globalnego adresu IPv6? To że delegowany prefix ma długość 56 to wiadomo od dawna, i że sobie z tego trzeba coś wybrać, to też wiadomo, ale nikt jak dotąd nie raportował otrzymania PD w tej samej sesji PPPoE w której wynegocjowano adres IPV4. Możesz to pokazać w logach? Czy też chodzi ci o to, że bez modyfikacji loginu dostajesz PD, a IPv4 masz przez DSLite? Ale wtedy IPv4 nie byłby publiczny, więc to raczej nie to... To ile masz jednocześnie sesji PPPoE nawiązanych żeby mieć oba typy adresów rutowalne w internecie?

PS. Jak już masz sukces, to podziel się kompletnym opisem, bo piszesz dość kryptycznie o tym co musiałeś zmodyfikować i jak. Przykładowo nie rozumiem o jakim konflikcie rutingu wspominasz ani jakież to pakiety odnawiające dzierżawę musiałeś specyficznie przepuszczać na fw i czemu właściwie z "niestandardowych adresów"?

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

ksq — Sun, 12 Jul 2026 11:52:22 GMT

Sprawdziłem u siebie i nie jestem w stanie potwierdzić, żeby dało się uzyskać Dual Stack z publicznym IPv4 i IPv6 z wykorzystaniem jednej sesji PPPoE.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Sun, 12 Jul 2026 11:58:10 GMT

Podczas ustawiania IPTV wydawało mi się, że miałem przez chwilę adres publiczny ipv6 (zalogowany byłem bez prefixu). Niestety do tej pory nie udało mi się tego odtworzyć, więc trzeba przyjąć, że mi się wydawało. Wtedy priorytetem była dla mnie IPTV, więc nie drążyłem.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Sun, 12 Jul 2026 13:53:30 GMT

Nie da się wykluczyć że nawet bez prefixu można dostać sesję w ipv6 i wtedy PD zadziała. Ale to nie będzie DS bo nie będzie publicznego iIPv4. Żeby ruting pakietów ipv4 w ogóle działał w takim przypadku, to trzeba by skonfigurować DSLite (nic szczególnie trudnego, ale "samo" się raczej nie zrobi, musiałbyś pamiętać że to konfigurowałeś).

Kruczek polega na tym, że jeśli skupiony byłeś na IP TV to mogłeś nie mieć w tym momencie tras ipv4 do internetu, a IP TV i tak mogła działać - ruting pakietów multicast do IPTV nie idzie wszak w ogóle przez internet i IP TV w tej implementacji obywa się znakomicie bez publicznego adresu IPv4. Dekoder z radością skorzysta z tras ipv6 żeby uzyskać autoryzację i klucze z internetu. To mógł być taki egzotyczny zbieg okoliczności, niekoniecznie coś ci się tylko wydawało.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Sun, 12 Jul 2026 20:14:51 GMT

Mogło się tak wydarzyć.

Na ten czas odpuściłem drążenie tematu bo i tak moim celem było zestawienie VPNu i tunelu z CloudFlare.

IPTV jak do tej pory działa stabilnie. Zastanawiam się tylko na zastosowaną opcją:

Send options: FSVDSL_funbox3.MLTV.softathome.Funbox3

Przed podmianą routera miałem FB6, czy jest sens to zamieniać?

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Sun, 12 Jul 2026 20:33:11 GMT

Jeśli chodzi ci o opcje użyte do zapytań DHCP to one cokolwiek dają tylko na VLAN 835, który i tak jest zbędny. Na VLAN 839 DHCP nie jest używane, a na VLAN 35 żadne takie udawanie FunBoxa nie jest potrzebne - kompletnie nic nie daje. Chyba że piszesz o czymś związanym z konfiguracją VPN - to wtedy wszytko zależy od tego co jest z drugiej strony tunelu, ale tak czy owak nie ma żadnego powodu żeby odnosić się w konfiguracji do sprzętu którego fizycznie nie ma i Operator z powodu tego faktu nie banuje połączeń.
W mojej konfiguracji nie ma żadnych odniesień do FB i zarówno IP TV jak i DS działa już od wielu miesięcy bardzo stabilnie. Oczywiście u mnie to nie jest OpenWRT, ale w kontekście tego o czym piszemy, to akurat wydaje się bez znaczenia.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Mon, 27 Jul 2026 13:44:36 GMT

No i udało się, na pewno wielu już to zrobiło przede mną, ale własny sukces cieszy. IPTV też działa stabilnie.

Teraz nadszedł czas na testowanie.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Mon, 27 Jul 2026 21:07:42 GMT

@radusplnapisał(-a)
No i udało się, na pewno wielu już to zrobiło przede mną, ale własny sukces cieszy. IPTV też działa stabilnie.
Teraz nadszedł czas na testowanie.

Dokładnie tak jest. Satysfakcja z samodzielnego rozwiązania problemu jest nieoceniona.

Pomyślnych testów. Tak z czystej ciekawości: IP TV ci chodzi po WiFi czy po kablu? Może mógłbyś krótko podsumować konfigurację? Niekoniecznie wszystkie niuanse, ale te które uważasz za krytyczne?

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Wed, 29 Jul 2026 12:49:15 GMT

Dla zapewnienia rozszerzenia funkcjonalności własnej sieci domowej zdecydowałem się na zakup nowego routera aby zastąpić FB6. Wybór padł na dual stack i OpenWrt (używam wersji 23.05), który podłączyłem do ONT operatora (nie Orange) sieci światłowodowej kablem ethernet.

Odpowiadając na pytanie, Orange IPTV działa na LAN (bez wskazywania konkretnego gniazda). Nie próbowałem jej uruchomić przez WiFi z powodu braku sprzętowej obsługi WPS na moim routerze a wiadomo, że IWU200 bez tego nie sparuje się z siecią bezprzewodowa. W OpenWrt istnieje możliwość programowej symulacji WPS'a, ale wymaga ona głębokich zmian oprogramowania, więc w to nie wchodziłem (jeszcze).

Zakładam, że macie już skonfigurowany główny interfejs WAN PPPoE over eth0.35 (logowanie bez /ipv6).

Po kolei, konfigurując niezbędne było posługiwanie się firmową nakładką web, luci i ssh. Pierwsze co należy zrobić, to aktywować IGMP Snooping i doinstalować pakiet igmpproxy (interfejs web).

Następne kroki (już tylko w luci):
1. W menu /Network/Interface/Devices dodajemy na adapterze ethernet „eth.0” (nie „VLAN eth.0.35”!) dwa VLAN’y (802.1q), tj. „eth0.838” i „eth0.839” i łączymy je w most "br-iptv". Most otrzyma MAC Address, który wykorzystamy w późniejszej konfiguracji. W moim przypadku nie zmieniałem pozostałych opcji i pozostawiłem domyślne ustawienia.
2. Przechodzimy do menu /Network/Interfaces i dodajemy interfejs „iptv” bazując na wcześniej utworzonym moście „br-iptv” i protokole „DHCP client” a w zakładce firewall ustawiamy strefę „iptv” (pokaże się ona po zmodyfikowaniu firewall, o czym za chwilę).

Teraz przyszedł czas na najważniejsze zmiany, ja, ze względu na łatwość wykonałem je w terminalu ssh edytorem vi, ale można też je utworzyć w luci:
1. Firewall: dodanie strefy iptv i kilku reguł (plik /etc/firewall):
config zone
option name 'iptv'
list network 'iptv'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config rule
option name 'IPTV_IGMP_Input'
option src 'iptv'
option proto 'igmp'
option target 'ACCEPT'
config rule
option name 'IPTV_Multicast_Forward'
option src 'iptv'
option dest 'lan'
option proto 'udp'
option dest_ip '224.0.0.0/4'
option target 'ACCEPT'
config rule
option name 'IPTV_UDP_Ports'
option src 'iptv'
option dest 'lan'
option proto 'udp'
option dest_port '5000 8200 11111'
option target 'ACCEPT'
config rule
option name 'Allow-DHCP-IPTV'
option src 'iptv'
option proto 'udp'
option src_port '67-68'
option dest_port '67-68'
option target 'ACCEPT'

2. igmpproxy (plik /etc/igmpproxy modyfikujemy, aby wyglądał jak poniżej):
config igmpproxy
option quickleave 1
config phyint
option network lan
option zone lan
option direction downstream
list altnet 224.0.0.0/4
config phyint
option network iptv
option zone iptv
option direction upstream
list altnet 224.0.0.0/4
list altnet 10.0.0.0/8
config phyint
option network wan
option direction disabled

config phyint
option network wan6
option direction disabled

3. newtork (plik /etc/network, modyfikujemy istniejący interfejs „iptv” dodając/modyfikując linie):

config interface 'iptv'

..........

option defaultroute '0'
option reqopts '1 3 6 15 26 28 42 121'
list sendopts '60:736167656d636f6d'
list sendopts '61:0100000000XXXX'
list sendopts '77:2746535644534c5f66756e626f78332e4d4c54562e736f66746174686f6d652e46756e626f7833'
Wyjaśnienie:
defaultroute na ‘0’ - wyłącza ustawianie tej sieci jako bramy domyślnej dla całego internetu,
option reqopts '1 3 6 15 26 28 42 121' - lista opcji DHCP, o które router prosi serwer,
list sendopts '60:736167656d636f6d' - wysyła opcję 60 (Vendor Class Identifier) zapisaną w kodzie szesnastkowym (HEX). Identyfikuje ona producenta sprzętu (w tym przypadku tekst dekoduje się na firmę Sagemcom),
list sendopts '61:0100000000XXXX' - wysyła opcję 61 (Client Identifier) w formacie HEX. To unikalny identyfikator urządzenia (wpisz bez „:” MAC Address utworzonego mostu zamiast XXXX),
list sendopts '77:2746535644534c5f66756e626f78332e4d4c54562e736f66746174686f6d652e46756e626f7833' - wysyła opcję 77 (User Class) w formacie HEX. Ten ciąg tekstowy jawnie identyfikuje usługę telewizyjną dla konkretnego modemu (dekoduje się m.in. jako FunBox3.MLTV.softathome).

Po zapisaniu ustawień i restarcie interfejsu został pobrany adres i powróciła telewizja.

Nie wiem, czy to jest konfiguracja optymalna, ale ważne, że działa stabilnie od kilku tygodni.

Pozdrawiam Społeczność nasz.orange.pl a w szczególności @larmalarma

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Wed, 29 Jul 2026 13:01:49 GMT

Dzięki za podzielenie się.
Nie mam oczywiście jak tego sprawdzić bo nie mam OpenWRT, ale zachodzę w głowę po ta cała gimnastyka z udawaniem Funboxa i konfigurowaniem VLAN 838. To jest całkowicie zbędne.

Owszem, w tej konfiguracji faktycznie zadzieją się następujące rzeczy: ruter poprosi serwer DHCP o dane na tym dwuvlanowym mostku. Dostanie te dane. Wśród nich będzie m. in. adres IP (który zostanie przypisany do interfejsu mostka) ale także kilka innych rzeczy, w tym serwer DNS, NTP i jakieś statyczne trasy. Żadna z tych rzeczy nie jest potrzebna ani nawet "używalna" na własnym sprzęcie. Te serwery (DNS, NTP i co tam jeszcze jest pod tymi statycznymi trasami) milczą jak zaklęte. Więc jeśli już cokolwiek z tego miałoby być potrzebne, to ten adres IP. Ale on też przecież nie jest używany w kontekście VLAN 839 - przypisanie do tworzonego mostka tego adresu jest nawet ryzykowne (choć z tak starannymi ustawieniami FW oczywiście nie stanowi zagrożenia per se).

IMHO wszystko co dotyczy konfiguracji VLAN 838 można usunąć, nie tworzyć mostka, a interfejs iptv zostawić na VLAN 839, przypisać mu jakiś (zupełnie dowolny) adres prywatny, wyłączyć na nim ARP i będzie działało. Nikt poza igmpproxy nie musi nawet znać tego adresu. DHCP i jego opcje można spokojnie zlikwidować - zastosowanie tych parametrów które on tam ustawia powoduje na ruterze mniej lub bardziej oczywiste problemy (np. zapytania DNS mogą łapać timeouty). W konfiguracji igmpproxy trzeba by wtedy dodać altnet 10/10 na upstream i tyle.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Wed, 29 Jul 2026 16:32:37 GMT

Zrobiłem takie próby. W przypadku interfejsu iptv opartego na mostku usunięcie podszywania się po FB, sendops 60 i 77, skutkuje brakiem wydania adresu.

Natomiast usunięcie VLAN 838 i nadanie stałego adresu interfejsu nie zakłóca działania IPTV nawet po usunięciu sendops. Dla pewności pozostawiłem adres nadany mi przez VLAN 838 licząc na wpis w tabeli ARP Orange. Zobaczę co się stanie, gdy minie czas dzierżawy.

Podstawiłem na próbę adres z tzw. "czapy" ale z zakresu zdefiniowanego w igmpproxy - 10.99.99.99/8 i działa dalej.

Teraz czas na obserwację.

Dzięki za garść wiedzy.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Wed, 29 Jul 2026 19:04:47 GMT

Super, dzięki że pofatygowałeś się to sprawdzać.
Co do tego nieszczęsnego adresu - tak, podszywanie się pod FB jest niezbędne żeby ten DHCP odpowiedział/wydał adres. To potwierdzam w całej rozciągłości. Tylko że ten adres nie jest do działania IP TV potrzebny. Co więcej, ta wymiana uprzejmości między FB a serwerem DHCP następuje praktycznie natychmiast, jeszcze przed nawiązaniem sesji PPPoE, jak tylko łącze optyczne się zapnie, to FB od tego zaczyna komunikację. Nieważne czy w ogóle IP TV będzie używana, nieważne czy będzie IPv6 czy IPv4, nieważne czy w ogóle uda się zalogować do usługi. FB i tak uzyskuje ten IP i po coś to robi. Bardzo mocno podejrzewam, że ten VLAN 838 (i ten IP) to jest Operatorowi potrzebny do zbierania szczegółowej telemetrii z rutera. Jeśli moja hipoteza ma coś wspólnego z rzeczywistością, to w przypadku własnego rutera jedyny "pożytek" to ten adres IP, żadnej telemetrii ruter do Orange i tak nie prześle. Dostanie tylko w bonusie niefunkcjonalny serwer DNS i NTP. Choć muszę przyznać że nie chcąc drażnić Operatora specjalnie agresywnie tych elementów które FB uzyskuje z DHCP nie sprawdzałem.

Wracając do adresu IP na interfejsie telewizyjnym. To jest oczywiście kuszące aby użyć tu tego adresu z DHCP (i wiele opisów właśnie tak proponuje, z mostkiem lub nawet bez), ale moim zdaniem to jest trochę fałszywy przyjaciel. Jedyny (niekwestionowany) zysk to taki, że przydzielony adres nie powinien generować konfliktu. Ale czy na pewno? Przecież przydzielony był na interfejsie VLAN 838, a nie na VLAN 839 na którym mogłoby to mieć jakieś znaczenie - bo ewidentnie adresy z klasy 10/10 są źródłem pakietów mulicast (zresztą ostatnio coraz mniej tych adresów się pojawia - prawie cała komunikacja idzie z pojedynczego adresu z tej klasy). No ale multicast rządzi się swoimi prawami: indywidualne adresy nie mają w nim w ogóle zastosowania. Pakiety są dostarczane na adresy multicastowe, a nie na indywidualne IP. Więc ten adres w tej sieci (VLAN 839) nie jest w ogóle potrzebny. Jedyny powód, że jakiś adres musi tam być to igmpproxy, bo on po prostu po adresie identyfikuje interfejsy. [Jak się kiedyś wkurzę to przepiszę ten kod tak, żeby adres nie był potrzebny]. Ale póki co wystarczy po prostu coś tam przypisać, upewnić się że nie jest to nigdzie rozgłaszane (w ekstremalnym przypadku można nie odpowiadać na ARP z tego interfejsu, ale spokojnie wystarczy jakiś adres prywatny z klasy innej niż 10/8) i tyle. Oczywiście jeśli adres przydzielony będzie w tej samej klasie z której idą pakiety multicast (10/8 albo 10/10, pewny nie jestem; 10/10 zdaje się wystarczać), to konfiguracja igmpproxy jest minimalnie prostsza, bo nie trzeba dodawać opcji altnet. No ale to przecież też nie jest problem dodać tę opcję. Czyli bez DHCP: jeśli na iptv mamy adres arbitralny, z kasy 10/10 to ryzykujemy konflikt adresów, ale igmpproxy będzie przyjmował pakiety multicast bez dodatkowych opcji. Ale jeśli przydzielimy adres tak prywatny że nie ma opcji konfliktu, to wystarczy dodać altnet 10/10 do konfiguracji igmpproxy i oba problemy znikają.
Działa mi to nieprzerwanie już od ponad roku, tyle że nie na OpenWRT.
W tym miejscu muszę oddać kredyt koledze @pirenej który oświecił mnie w odpowiednim momencie i pierwszy pokazał minimalistyczną konfigurację IPTV na własnym sprzęcie.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

raduspl — Wed, 29 Jul 2026 20:02:30 GMT

Aż tak biegły nie jestem ale wydaje mi się, że Twój tok rozumowania jest poprawny w kwestii potrzeby utrzymywania adresu IPv4 na interfejsie iptv. Żeby to sprawdzić zmieniłem go na 100.100.X.X i też działa, nawet bez dodawania altnetu.

Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi

j131 — Wed, 29 Jul 2026 21:47:00 GMT

Może to zależy o wersji igmpproxy. U mnie bez altnet albo z innym altnet nie chciało działać. Fakt, jakoś tego wtedy nie drążyłem, być może że trzeba się temu jeszcze raz przyjrzeć. Tak czy owak to jest idiosynkrazja igmpproxy, nie jakaś uniwersalna zasada sieciowa. Gdyby zamiast igmpproxy postawić jakiegoś innego demona zapewniającego ruting pakietów multicast, to miałby swoje idiosynkrazje, na pewno inne. Ale nie znam nikogo kto używałby w tym kontekście czegoś innego niż igmpproxy - tyle że co do wersji/implementacji to pewnie bywają różne. Nie wiem jakiej ewentualnie używa FB (oczywiście tu nie ma pewności czy tego używa, choć jakieś przesłanki są), ani jaka wersja jest w OpenWRT ani nawet jaką w tej chwili mam u siebie. Cieszę się że działa adekwatnie i w sumie po jednorazowej konfiguracji można zapomnieć że jest. Każda sprawdzona informacja jest więc cenna - oszczędza czas i nerwy.