LEDE met Xs4all IPTV: sommige zenders haperen

[amarok]

Sinds kort heb ik de Fritzbox 7581 vervangen door een Draytek 2862B en een eigen router. Over het algemeen werkt alles correct, maar sommige iptv zendes haperen.

De situatie: de Fritzbox is dus vervangen door een Draytek. Ik heb gekozen voor model 2862B omdat ik bonded vdsl2 heb. De Draytek wordt alleen gebruikt als modem. Helaas ging het niet zo simpel als bij de Vigor 120 die ik een aantal jaren geleden heb gebruikt, maar heb het wel aan de praat gekregen. Vlan 6 (internet) wordt als bridge aangeboden op poort 4 en iptv op vlan 4 wordt ook aangeboden als bridge op poort 3 op de Draytek.

De router die ik gebruik is een TP-Link Archer C5 v1.20 AC1200 met LEDE 17.01.2. Op de WAN interface (eth0) zijn de vlans 4 en 6 tagged geconfigureerd. De utp kabel loopt naar een switch op poort 1. Verder wordt vlan 4 untagged op poort 2 en vlan 6 untagged op poort 3 aangeboden op de switch. Deze poorten zijn aangesloten op de respectievelijke poorten op de Draytek.

LEDE is geconfigureerd volgens https://gathering.tweaker...message/44952450#44952450 en https://gathering.tweaker...message/49023051#49023051 en over het algemeen werkt het goed. Internet werkt goed, iptv over het algemeen ook, behalve een paar zenders.

Als ik met tcpdump kijk naar de verkeersstroom wanneer Comedy Central HD opstaat, zie je dit:

16:19:06.480799 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.482287 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.483774 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.485349 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.486855 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.488523 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328
16:19:06.490045 IP 213.75.167.10.53010 > 224.0.252.121.7242: UDP, length 1328

Deze zender werkt goed en maakt zo te zien gebruik van multicasting.

Comedy Central Extra werkt niet goed (kijk ik wel graag). Met tcpdump zie je het volgende:

16:20:49.857658 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:49.861291 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:49.864886 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:49.868685 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:49.872431 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:49.874951 IP 213.75.113.207.10000 > 10.77.2.187.3544: UDP, length 1328
16:20:50.286734 IP 213.75.167.58.54857 > 224.3.2.6.9875: UDP, length 361
16:20:50.356905 IP 213.75.167.58.54857 > 224.3.2.6.9875: UDP, length 329
16:20:50.621899 IP 213.75.167.58.54857 > 224.3.2.6.9875: UDP, length 331
16:20:50.676178 IP 213.75.167.58.54857 > 224.3.2.6.9875: UDP, length 361
16:20:50.733448 IP 213.75.167.58.54857 > 224.3.2.6.9875: UDP, length 352

Je ziet hier dus multicating en unicasting telkens door elkaar. Dit is continu te zien. De zender geeft telkens een of twee seconden beeld en staat daarna weer stil. Wordt deze zender soms gedistribueert via unicasting?

[ Edit 18:34 ]
Wat 224.3.2.6 betreft: ik zie dat dit verkeer naar deze destination ook gewoon doorgaat als ik naar een werkend kanaal kijk. Doordat de stroom met multicast packets veel sneller loopt, valt dit niet zo op in een capture.

Probleem is eigenlijk bij CC Extra (maar ook NPO1-3 GOS) dat het verkeer waarschijnlijk ge-NAT wordt. Vraag me af of dit de bedoeling is.

[/ Edit 18:34 ]


De routering ziet er als volgt uit:

root@bw62-router:~# ip route show
default via 194.109.5.226 dev pppoe-wan
10.77.1.0/24 dev br-lan src 10.77.1.1
10.77.2.0/24 dev eth1.20 src 10.77.2.1
10.201.8.0/22 dev eth0.4 src 10.201.8.252
10.201.8.1 dev eth0.4 src 10.201.8.252
194.109.5.226 dev pppoe-wan src 80.127.255.161
213.75.112.0/21 via 10.201.8.1 dev eth0.4 src 10.201.8.252

De laatste route is afkomstig van het DHCP request op de iptv interface. 10.77.2.0 (eth1.20) is het vlan voor de stb's (2x HMB2260).

Wat moet ik nu precies denken van dat gemixte multi- en unicast verkeer bij CC Extra? Het source adres dat je ziet, 213.75.113.207, zit in het subnet dat gerouteerd wordt over de iptv interface. Dat verkeer wordt ook ge-NAT door middel van masquerading.

Als iemand een hint heeft, dan graag!

[ Voor 4% gewijzigd door amarok op 20-08-2017 18:38 . Reden: Correctie omtrent 224.3.2.6 destination address ]

[amarok]

Nog wat beziggehouden met het troubleshooten. Ik vermoed nu dat wanneer er een zender geselecteerd wordt, dat deze begint als een unicast stream. Daarna wordt er via IGMP een request gedaan om de multicast groep te joinen. Vanaf dan is er sprake van multicasting.

Het lijkt erop dat bij Comedy Central Extra, en nog een aantal kanalen, er geen multicast join wordt ontvangen door op de LAN interface (eth1, vlan 20 is STB vlan, 10.77.2.187 is STB).

root@bw62-router:~# tcpdump -ni eth1.20 igmp and host 10.77.2.187
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.20, link-type EN10MB (Ethernet), capture size 262144 bytes

De STB wordt aangezet en begint op kanaal 72, Comedy Central Family. Na een vijftal seconden schakel ik over naar RTL Lounge (kanaal 73):

23:34:40.067217 IP 10.77.2.187 > 224.0.0.2: igmp leave 224.0.252.4

224.0.252.4 is waarschijnlijk CC Family; 224.0.251.35 is dan RTL Lounge.

23:34:40.497560 IP 10.77.2.187 > 224.0.251.35: igmp v2 report 224.0.251.35
23:34:47.283631 IP 10.77.2.187 > 224.0.251.35: igmp v2 report 224.0.251.35
23:34:50.755666 IP 10.77.2.187 > 224.0.251.35: igmp v2 report 224.0.251.35

Ik heb op het volgende tijdstip al een keer gezapt naar Comedy Central Extra. Zie daar geen melding van...
Hieronder schakel ik van CC Extra naar CC Family.

23:35:24.792801 IP 10.77.2.187 > 224.0.0.2: igmp leave 224.0.251.35 <-- dit is nog steeds RTL Lounge
23:35:25.364169 IP 10.77.2.187 > 224.0.252.4: igmp v2 report 224.0.252.4 <-- CC Family
23:35:32.004246 IP 10.77.2.187 > 224.0.252.4: igmp v2 report 224.0.252.4
23:35:33.444317 IP 10.77.2.187 > 224.0.0.2: igmp leave 224.0.252.4
23:36:00.442615 IP 10.77.2.187 > 224.0.252.4: igmp v2 report 224.0.252.4
23:36:08.252678 IP 10.77.2.187 > 224.0.252.4: igmp v2 report 224.0.252.4
23:36:11.204738 IP 10.77.2.187 > 224.3.2.6: igmp v2 report 224.3.2.6
23:36:15.380783 IP 10.77.2.187 > 239.255.255.250: igmp v2 report 239.255.255.250

Kan iemand mijn theorie bevestigen dat het selecteren van een kanaal in eerste instantie begint als unicast verkeer?

[jongerenchaos]

Voeg dit eens toe aan je /etc/sysctl.conf

net.ipv4.conf.all.force_igmp_version=2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2

[Thralas]

amarok schreef op zondag 20 augustus 2017 @ 16:59:
Je ziet hier dus multicating en unicasting telkens door elkaar. Dit is continu te zien. De zender geeft telkens een of twee seconden beeld en staat daarna weer stil. Wordt deze zender soms gedistribueert via unicasting?

Nee. Maar er is inderdaad wel een feature waarbij er eerst een unicast stream wordt opgezet, om dan later over te schakelen. Hoe en wanneer dit precies wordt ingezet is me niet duidelijk (ik kan het zo 123 niet reproduceren, maar heb het wel eens gezien).

[ Edit 18:34 ]
Wat 224.3.2.6 betreft: ik zie dat dit verkeer naar deze destination ook gewoon doorgaat als ik naar een werkend kanaal kijk. Doordat de stroom met multicast packets veel sneller loopt, valt dit niet zo op in een capture.

Daar haalt het dng z'n updates/metadata vandaan. Is inderdaad altijd subscribed zolang een STB aanstaat (al dan niet in standby).

code:

!(ip.dst == 224.3.2.6)

Probleem is eigenlijk bij CC Extra (maar ook NPO1-3 GOS) dat het verkeer waarschijnlijk ge-NAT wordt. Vraag me af of dit de bedoeling is.

Dat zou geen probleem moeten zijn (voor het unicast gedeelte) - daar gebruiken ze STUN voor.

Als ik de group van CC Family join dan zie ik verkeer van deze source:

code:

17:24:12.969496 IP 213.75.167.22.54413 > 224.0.252.4.7008:  rx type 73 (1328)

CC Extra:

code:

17:23:07.392183 IP 213.75.167.18.54643 > 224.0.252.1.7002:  rx type 0 (1328)

Die liggen vrijwel 'naast' elkaar. Er gaat iets goed fout bij jou.

Als je iets met unicast wilt testen zul je even een kanaal uit het basispakket van KPN moeten noemen waar dat optreedt. CC Whatever heb ik niet.

[avdleun]

Naast elkaar ? Het zijn geen radiogolven.....

[Thralas]

...

Wel IP-adressen waarvan je mag verwachten dat eventuele ranges (en routes) tenminste een /24 beslaan. Zodoende.

[ Voor 5% gewijzigd door Thralas op 21-08-2017 20:34 ]

[avdleun]

Thanks. Ik leer nog iedere dag. Wat levert die /24 op ?

[Thralas]

Wat wel eens mis wil gaan bij multicast IPTV is dat, omdat een stream slechts 1 kant op gaat, je set top box het source IP-adres van de stream niet hoeft te kunnen bereiken (hij ontvangt er alleen data van maar stuurt nooit iets terug).

Echter, veel routers doen standaard aan reverse path filtering, wat ervoor zorgt dat er bij binnenkomst van een packet wordt gecontroleerd of er een route bestaat naar het source adres.

Zie Reverse path forwarding.

Uit het voorbeeld van TS blijkt dat er multicastverkeer van o.a. 213.75.167.10 afkomstig is; in de routetabel blijkt dat er geen route naar dat adres is. rp_filter moet dus al uit staan, anders zouden de andere kanalen ook niet werken.

Bijna alle mutlicast sources van KPN vallen binnen ~ 213.75.167.0/24, ook de twee TV-streams (waarvan er 1 niet werkt), vandaar de opmerking over 'naast elkaar'. Maar dat zou niet uit moeten maken nu we geconcludeerd hebben dat er toch geen reverse path checks zijn.

@amarok Misschien is het handig als je ook even op eth0.4 capped, om er zeker van te zijn dat er ook IGMPv2 queries uit gaan (IGMPv3 werkt inderdaad niet).

[amarok]

Ik heb die route later wel eens toegevoegd, want op het forum van kpn vond ik er een verwijzing naar:

https://forum.kpn.com/thu...dressen-430819#post477651

Dan werkte het nog niet. Ik heb nu wel genoemde instellingen aan sysctl.conf toegevoeg en voor de volledigheid router herstart. De routering 213.75.167.0/24 via 10.201.8.1 heb ik daarna weer handmatig toegevoegd.

STB heb ik ook herstart. Hij staat nu een software update op te halen. Ik wacht het even af....

[Thralas]

amarok schreef op maandag 21 augustus 2017 @ 21:45:
Ik heb die route later wel eens toegevoegd, want op het forum van kpn vond ik er een verwijzing naar:

Kijk nou waar die verwijzing weer heenlinkt

Ik heb overigens zelf rp_filter ook uit staan; na wat langere tijd monitoren van het IPTV-verkeer bleek dat er nog wat meer adressen zijn die op het IPTV-netwerk thuishoren (maar geen explicete route hebben).

[amarok]

Ik zal die rp_filters er weer uit halen. Het probleem is overigens nog niet verdwenen.

Dat een tv stream als unicast begint, kan ik reproduceren. Als ik een tcpdump -ni eth1.20 host 10.77.2.187 uitvoer, dan beginnen de streams waarmee ik getest heb (aardig wat zenders) allemaal als unicast. Na ongeveer een seconde stopt die stream en is er kennelijk naar multicast overgeschakeld. Bij CC Extra blijf ik zien dat de unicast stream op gang komt, stopt dan even, en dan start er opnieuw een unicast stream. Alsof de STB blijft proberen om de stream te starten.

Als je dit wilt testen: bij mij geven NPO1 GOS t/m NPO3 GOS hetzelfde probleem. Ik neem aan dat deze zenders in het basispakket zitten (191 t/m 193).

Ik zie bij deze kanalen ook geen join request voorbijkomen.

Dit zie ik trouwens ook met enige regelmaat verschijnen als ik een capture doe op de LAN interface:

22:22:47.119233 IP 10.77.2.187.51576 > 239.255.255.250.1900: UDP, length 449
22:22:47.119285 IP 10.77.2.187.47365 > 239.255.255.250.1900: UDP, length 441
22:22:47.119511 IP 10.77.2.187.53941 > 239.255.255.250.1900: UDP, length 395

Volgens Wikipedia is dit het SSDP protocol (Simple Service Discovery Protocol) en wordt o.a. gebruikt voor UPnP. Ik neem aan dat ik hier verder niets voor hoef ingericht te hebben op de router?

-----

Dit hieronder is een capture van eth0.4 (WAN interface) waarbij gefilterd wordt op IGMP:

AMC
22:40:03.773592 IP 10.201.8.252 > 224.0.0.2: igmp leave 224.0.252.103

[b]Cartoon Network[b]
22:40:04.335075 IP 10.201.8.252 > 224.0.252.119: igmp v2 report 224.0.252.119

AMC
22:40:12.757182 IP 10.201.8.252 > 224.0.0.2: igmp leave 224.0.252.119
22:40:13.335030 IP 10.201.8.252 > 224.0.252.103: igmp v2 report 224.0.252.103
22:40:15.825039 IP 10.201.8.252 > 224.0.252.103: igmp v2 report 224.0.252.103

Volgens de capture zou ik nu AMC wegzappen; ik was echter alnaar CC Extra gezapt. Zap nu door naar CC Family. Geen join in de tussentijd gezien...
22:40:17.494204 IP 10.201.8.252 > 224.0.0.2: igmp leave 224.0.252.103
22:40:29.615022 IP 10.201.8.252 > 224.0.252.4: igmp v2 report 224.0.252.4
22:40:36.555049 IP 10.201.8.252 > 224.0.252.4: igmp v2 report 224.0.252.4

Dus ook hier geen igmp packet gezien bij CC Extra op de WAN interface. Niet zo vreemd m.i., omdat 'ie aan de LAN kant ook niet gezien wordt.

Misschien maar eens een virtueel pfSense machientje bouwen met dezelfde functionaliteit als de LEDE router om uit te sluiten dat het aan die laatste ligt.

[Thralas]

amarok schreef op maandag 21 augustus 2017 @ 22:57:
Bij CC Extra blijf ik zien dat de unicast stream op gang komt, stopt dan even, en dan start er opnieuw een unicast stream. Alsof de STB blijft proberen om de stream te starten.

Als je dit wilt testen: bij mij geven NPO1 GOS t/m NPO3 GOS hetzelfde probleem. Ik neem aan dat deze zenders in het basispakket zitten (191 t/m 193).

Ik zie bij deze kanalen ook geen join request voorbijkomen.

Dan zijn die inderdaad blijkbaar gewoon unicast. Ik had daar ooit een overzicht van, maar die is niet up-to-date.

NPO1 GOS blijft hier gewoon werken via unicast. Geen mutlicast bij betrokken, ik vermoed dat stiekem multicast prima werkt, maar die paar unicast-kanalen stuk gaan?

Misschien toch ergens een NAT-timeout? Volgens mij hoort hij ook zeker niet te reconnecten (je ziet dan een nieuwe RTSP-sessie?).

Lijkt er een beetje op alsof een NAT-router besluit dat die UDP 'connectie' die met STUN is gemapped niet meer relevant is omdat er geen verkeer teruggaat..

De UDP-stream zou door moeten blijven gaan zolang de RTSP TCP-connectie openblijft (geloof ik). Als het aan de router ligt zou je 'm nog wel moeten zien binnenkomen, maar niet worden geforward naar je IPTV LAN interface..

Volgens Wikipedia is dit het SSDP protocol (Simple Service Discovery Protocol) en wordt o.a. gebruikt voor UPnP. Ik neem aan dat ik hier verder niets voor hoef ingericht te hebben op de router?

Is inderdaad UPnP, maar wordt niet echt gebruikt. Zeker niet relevant in deze.

[ Voor 3% gewijzigd door Thralas op 21-08-2017 23:47 ]

[amarok]

In de afgelopen week heb ik een OPNsense server ingericht op een Citrix Xenserver 7.1. Binnen een uur had ik dit werkend, maar liep ook hier tegen problemen. De zenders die het met de LEDE router wel deden (multicasting), deden het nu niet. De zenders die unicasting gebruiken werkten wel probleemloos nu!

Ik denk dat het ermee te maken heeft dat multicasting met XenServer niet goed werkt. Vond hier wel wat posts op andere forums over, maar een oplossing van iemand die zou moeten werken met XenServer 6.x, werkte nu niet. Voor nu besloten om dit pad te verlaten, want het is m.i. ook niet een ideale oplossing; heb liever een los doosje als router.

Vanmiddag de boel weer aangesloten zoals het was. Probleem is er nog steeds. Verder troubleshooten dus.

Eén ding dat mij verbaasd is dat ik op de router interface eth0.4 (iptv_wan) met tcpdump ook allerlei PPPoE verkeer zie. Dat hoort m.i. thuis in vlan 6. Dit vlan gaat untagged over interface eth0.

Dus het eerste waar ik benieuwd naar ben over de werking van Linux is de vraag of als je een eth0.y vlan sniffert onder Linux, hoor je dan ook alleen het traffic te zien dat in dat vlan y thuishoort? Of werkt Linux niet zo?

Als ik dit verkeer niet hoor te zien, dan is er dus kennelijk nog iets mis in mijn configuratie van switches of de LEDE router.

Ik vraag dit namelijk omdat ik tijdens een capture van eth0.4 zie dat er een constante unicast stream afkomstig van 213.75.x.y bij Comedy Central Extra te zien is. Zodra het beeld gaat haperen, dan volgt er opeens data tussendoor dat m.i. in vlan 6 thuishoort (PPPoE traffic).

Misschien is er nog wel iets mis met hoe ik de Draytek 2862b geconfigureerd heb...


----

[ Edit 18:12 ]

Het werkt! Het probleem zat uiteindelijk in de Draytek, omdat ik deze niet goed had geconfigureerd. Kort samengevat: PPPoE Passthrough staat dus geconfigureerd en internet verkeer gaat tagged over vlan 6. Omdat het eerder een tijd duurde voordat er response kwam van de PPPoE server bij Xs4all, ben ik verder gaan zoeken en heb ik ook een bridge gemaakt met vlan 6 op LAN poort 3. Vlan 4 werd daarna gebridgded op LAN poort 4. Uiteindelijk kreeg ik een adres en dacht ik dus dat het zo geconfigureerd hoorde te zijn. Dit introduceerde wel het probleem met de unicast zenders, waarbij ik vlan 6 verkeer zag in vlan 4 op het moment dat een zender begon te haperen.

Na vanmiddag nog een tijd gegoogled te hebben, heb ik de bridge voor vlan 6 verwijderd op poort 3, zodat er alleen IPTV nog gebridged wordt. En nu werken de unicasting en multicasting zenders probleemloos. On Demand werkt, opnames terugkijken werkt. Hetzelfde geldt ook voor pauzeren. Zou dit een bug in de firmware van de Draytek kunnen zijn?

Overigens heb ik vanmiddag ook nog wat andere zaken in de LEDE router aangepast naar aanleiding van forumposts en blogs. Omdat nu wat onoverzichtelijk is hoe ik de boel geconfigureerd heb, zal ik het een en ander documenteren, zodat andere gebruikers met een bonded VDSL verbinding ook wat aan mijn excercities hebben...

Iedereen hartelijk dank voor het meedenken en reageren!

P.S.: wat mijn vraag betreft over het capturen van een eth0.y interface. Daarover vond ik meer op deze pagina:

After your VLAN interfaces are set up and traffic is flowing, you can run Wireshark and capture on the VLAN interface of your choice (e.g., eth0.100 for VLAN 100) or on the underlying physical interface (e.g., eth0). If you choose the former, you will only see frames destined for that VLAN; if you choose the latter, you may see all frames or you may see only untagged frames (if there are any). It depends on the NIC, the NIC firmware, the driver, and the alignment of the moon and planets.

https://wiki.wireshark.org/CaptureSetup/VLAN

[ Voor 38% gewijzigd door amarok op 26-08-2017 18:12 . Reden: Aanvulling ]

[Kasper1985]

Hoop dat ik een wat ouder topic mag kapen.

Ik heb de fritzbox ook vervangen door een draytek modem dat ik in bridge modus draai. Ik heb dit geprobeerd aan de praat te krijgen met een R7800 met LEDE/openwrt router.

1 maal heb ik een IP gekregen vanuit xs4all. Daarna is het eeuwig stil gebleven.

Inmiddels draait het allemaal als een zonnetje op een asus router die ik nog had liggen en als accespoint gebruikte. Het feit dat het hier wel op lukt wil dus zeggen dat er ergens in de LEDE iets mis gaat.

LEDE krijg ik niet aan de praat wat ik ook aanpas. Zou je mij je config kunnen sturen van je LEDE setup? Of misschien opweg kunnen helpen?

Ik heb nu op de WAN interface een pppoe aangemaakt met als enige niet standaard ding dat ik eth0.6 heb aangegeven. Verder username en password uit een online handleiding gebruikt.

Omdat de Netgear vele malen krachtiger is dan de asus zou ik het liefst die gebruiken (ivm openvpn) maar dan moet de bassale internet verbinding wel eerst werken

Dank!

Kasper

[rens-br]

Kasper1985 schreef op zondag 8 oktober 2017 @ 20:38:
Hoop dat ik een wat ouder topic mag kapen.

Nee. Dat is niet toegestaan. Maak even een eigen topic aan.

[amarok]

Eerder heb ik beloofd om te documenteren hoe de Draytek 2862B en de LEDE router zijn geconfigureerd. Belofte maakt schuld en dus ben ik vannacht maar eens productief geweest...

https://alex.vdleun.net/xs4all-bonded-vdsl2-with-iptv-lede-and-the-draytek-2862b/

[Koen_D]

Ik heb sinds vandaag de Fritz!Box 7360 vervangen door een, door xs4all geleverde, Fritz!Box 7581.
Ik heb daarachter alles via switched ethernet met VLAN heb lopen, waarbij ik voor internet verbinding gebruik maak van 2 ISP's (xs4all en Ziggo) ivm failover en de bandbreedte beperkingen van KPN lijnen.

Voor IPTV was op de 7360 altijd alleen LAN poort 4 geschikt. Deze was gekoppeld aan VLAN 4 op mijn switches en afhankelijk van bestemming doorgezet via een trunk of directe poort switching met default poorten altijd ingesteld op VLAN 4 (PVID 4). Tevens was hierbij IGMP Snooping op iedere switch ingesteld op Enabled over VLAN 4 en met IGMPv3 IP header checking aan. Voor IPTV poorten was het VLAN voor Internet/LAN als Tagged ingesteld en IPTV (VLAN 4) als Untagged.

Na installatie van de 5781 werkte IPTV echter niet meer. XS4ALL servicedesk kon me vertellen dat voorheen alleen LAN poort 4 werkte, maar nu alle poorten van de Fritz!Box voor zowel Internet als IPTV gebruikt konden worden. Kortom, er is blijkbaar iets veranderd met de netwerk instellingen. Dit kun je op deze routers helaas niet zien of instellen. Hoe verder konden ze me echter niet mee helpen.

Ik heb wat gepuzzeld met de IGMP en VLAN instellingen. Ik weet dat xs4all internet op VLAN 6 en IPTV op VLAN 4 heeft zitten. Ik heb op de switches VLAN 6 toegevoegd. Ik heb het nu werkend door op alle switches en poorten met aangesloten IPTV devices alle poorten VLAN 1 (LAN/Internet van Ziggo) en VLAN 4 (IPTV xs4all) als Tagged in te stellen. VLAN 6 (Internet xs4all) als Untagged. Vervolgens heb ik op deze switches IGMP snooping ingesteld op Enabled voor VLAN 6. IGMPv3 Header checking en Block Unknown Multicast address op Disabled.

En daarmee werkt het weer.

[Kasper1985]

@Koen_D Dat is interessant. Ik heb gisteren geprobeerd om het zo aan de praat te krijgen met gewoon de 7581 en switches maar kreeg geen IP van het IPTV netwerk.

Heb je nu bridged of routed IPTV? Ik wil graag bridged icm de fritzbox omdat als ik het routed instel dingen als live pauzeren en opnemen niet werken.

Het is me tot nu toe nog niet gelukt om het zo werkend te krijgen.

Kasper

[Tweaker_home]

Ik heb sinds een jaar een een XS4All abbonement.
Mijn IPTV wordt gerouteerd en dmv een PFSense (laatste verse >2.4.0) werkt ook de IGMP proxy naar behoren. Hier zat in oudere versies een foutje, waardoor deze niet in een VLAN-interface werkte.
WAN aangemaakt, met daarop VLAN 4 en 6 als virtuele interface.

Nu weet ik niet welke stappen XS4All onderneemt met het verdere omzetten van Bridge naar Gerouteerde IPTV