- « Poprzedni
-
- 1
- 2
- Następny »
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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ć?
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
@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?
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- Oznacz jako nowe
- Zakładka
- Obserwuj
- Wycisz
- Subskrybuj źródło RSS
- Wyróżnij
- Drukuj
- Zgłoś
Konfiguracja IPTV na OpenWRT/LuCI z dekoderem 4K Multi
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.
- « Poprzedni
-
- 1
- 2
- Następny »