Sticky

Gebruik een eigen router i.p.v. de Experia Box

  • 8 September 2018
  • 8546 reacties
  • 560481 keer bekeken
Gebruik een eigen router i.p.v. de Experia Box

Toon eerste bericht

8546 reacties

De symptomen verwijzen naar een IGMP proxy probleem.

Bij mij:

Als ik dit vergelijk met jouw configuratie zal 192.168.40.0/24 (bij mij ‘bridge-ether’) als downstream gedefinieerd moeten worden, als enp5s0 je LAN is lijkt dat reeds zo te zijn. Daarnaast begin ik te twijfelen of de ‘altnet’ regels niet gewoon weg kunnen en worden vervangen door één ‘altnet’ regel voor 0.0.0.0/0.

Denk dat je gelijk hebt. Dit moet wel een IGMP  probleem zijn. Unicast zenders, de lokale  omroepen, doen het wel.  Zodra die op mulitcast overgaat, loopt het vst.

Lijkt wel alsof die hele igmpproxy genegeerd wordt. Maar ik zie wel de groepen in de DSG-1100 routers.

Je igmpproxy.conf zou er dan denk ik nu zo moeten uitzien, klopt dat?

--- knip knip ---

quickleave

phyint enp5s0 downstream ratelimit 0 threshold 1

phyint vlan4 upstream  ratelimit 0  threshold 1
    altnet 0.0.0.0/0

--- knip knip ---

Wat me nu even triggerde is dat je het hebt over DSG-1100 ROUTERS. Als die daadwerk routers zijn en geen switches, dan zul je waarschijnlijk daar opnieuw het IGMP proxy truukje moeten uithalen. Persoonlijk zou ik routing nodeloos complex vinden en voor switches met IGMP snooping gaan, maar als je een goed reden hebt om routing te gebruiken dan moet je ook de lasten dragen.

Echter, als ik die DSG-1100 Google kom ik uit bij D-Link smart switches. Er van uitgaande dat het toch een switch is zal IGMP snooping dus aan moeten staan.

In principe zou dan aan alle voorwaarden voldaan moeten zijn.

Ja. Je hebt gelijk. DSG-1100 zijn smart en hebben IGMP snooping  aanstaan.  Als ik de experiabox daarin prik, dan doet alles het gewoon. Het zijn inderdaad switches, geen routers.

Ja, mijn igmpproxy ziet er  zo  uit.
Het lijkt volledig ignored te worden.

Ik zie wel een stream UPD van ongeveer 8000kb/s naar die STB gaan. 

UDP (1356 bytes) from 217.166.226.127:49152 to 224.0.252.127:7254 on vlan4

Maar, het lijkt daar niet uit te komen, waardoor ik toch weer aan routing issues ga denken.

igmpproxy wise, ik heb toch eigenlijk 2 upstreams, de  VLAN4 en de ppp0? Moet ik daar niets voor regelen?

Ja. Je hebt gelijk. DSG-1100 zijn smart en hebben IGMP snooping  aanstaan.  Als ik de experiabox daarin prik, dan doet alles het gewoon. Het zijn inderdaad switches, geen routers.

Ja, mijn igmpproxy ziet er  zo  uit.
Het lijkt volledig ignored te worden.

Ik zie wel een stream UPD van ongeveer 8000kb/s naar die STB gaan. 

 UDP (1356 bytes) from 217.166.226.127:49152 to 224.0.252.127:7254 on vlan4

Maar, het lijkt daar niet uit te komen, waardoor ik toch weer aan routing issues ga denken.

igmpproxy wise, ik heb toch eigenlijk 2 upstreams, de  VLAN4 en de ppp0? Moet ik daar niets voor regelen?

Lijkt goed te gaan, dit is bijvoorbeeld bij mij kanaal 661:

Die 8 Mbps bij jou komt prima overeen met een standaard HD kanaal.

De PPPoE hoeft je niets mee te doen, daar gaat alleen unicast verkeer overheen. Alle multicast verkeer voor iptv komt via vlan4.

Als het goed is moet je zowel op vlan4 als op de LAN interface hetzelfde volume aan data zien.

Mogelijk dan je nog wat logging kan aansteken op de igmpproxy om te achterhalen wat die doet en anders controleren met tcpdump of er gebeurd op de Linux doos wat je verwacht.

Hmm, ik zie  op Vlan4 en eth0, dat is waar vlan4 fysiek opzit,8000 kb/s.
Als ik de igmpproxy uitzet, dan is dat verkeer ook weg.

Ik zie dat verkeer niet het lan, enp5s0 opkomen. Tenzij ik op een unicast zender zit, dan is het  verkeer er wel.

Conclusie: multicast van vlan4 naar Lan werkt niet?

Dat je het verkeer op eth0 en vlan4 ziet is logisch omdat vlan4 via eth0 loopt, vlan4 heet niet voor niets eth0.4 onder Linux.

Het feit dat je IGMP verkeer stopt als je de proxy uitzet doet mij denken dat downstream IGMP fout gaat, of dat de firewall toch nog iets blokkeert in het pad vlan4 → enp5s0. Ik las ergens dat het uitgangspunt van FireHOL deny all is.

Dat je het verkeer op eth0 en vlan4 ziet is logisch omdat vlan4 via eth0 loopt, vlan4 heet niet voor niets eth0.4 onder Linux.

Het feit dat je IGMP verkeer stopt als je de proxy uitzet doet mij denken dat downstream IGMP fout gaat, of dat de firewall toch nog iets blokkeert in het pad vlan4 → enp5s0. Ik las ergens dat het uitgangspunt van FireHOL deny all is.

Ja dat klopt. Ik heb FireHOL even uitgezet en met de hand een simpele iptables config gemaakt;

iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere 213.75.112.0/21
MASQUERADE all -- anywhere anywhere

iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Dat zou alles moeten doorlaten, no blocks. Maar, nog steeds zelfde verhaal. Ik zal toch ergens iets moeten uit- of aanzetten.

Reputatie 4
Badge +1

Ja dat klopt. Ik heb FireHOL even uitgezet en met de hand een simpele iptables config gemaakt;

Dat zou alles moeten doorlaten, no blocks. Maar, nog steeds zelfde verhaal. Ik zal toch ergens iets moeten uit- of aanzetten.

Hoi,

zag dat je op mijn (misschien iets teveel Gentoo specifieke) topic een melding had achtergelaten. Twee dingetjes:

  1. Ik heb moeten constateren dat de opgegeven IP ranges (213.75.0.0/16 en 217.166.0.0/16) voor KPN niet alles-dekkend zijn en gebruik tegenwoordig 0.0.0.0/0 als `altnet` instelling. Of dat een beveiligingsrisico inhoudt weet ik niet, maar omdat de communicatie in mijn situatie tot een geïsoleerd intern vlan is beperkt maak ik mij daar niet echt druk om
     
  2. Als je beeld krijgt dan impliceert dit dat IGMPProxy werkt. Het stokken van het beeld duidt op een probleem met multicast routing, hetzij intern dan wel extern. Strikt genomen zou dat een probleem kunnen zijn met de switches die je gebruikt, maar ik zou beginnen met je firewall regels. Dit zijn de regels die ikzelf gebruik:
    :iTV_fwd
    :iTV_in
    -A INPUT -i eth0.4 -j iTV_in
    -A FORWARD -i eth1.2022 -j iTV_fwd
    -A FORWARD -i eth0.4 -j iTV_fwd
    -A iTV_fwd -i eth0.4 -m pkttype --pkt-type multicast -j ACCEPT
    -A iTV_fwd -d 10.20.22.0/24 -i eth0.4 -j ACCEPT
    -A iTV_fwd -d 224.0.0.0/4 -i eth0.4 -p udp -j ACCEPT
    -A iTV_fwd -i eth1.2022 -o eth0.4 -j ACCEPT
    -A iTV_fwd -i eth1.2022 -o ppp0 -j ACCEPT
    -A iTV_fwd -j REJECT --reject-with icmp-port-unreachable
    -A iTV_in -m pkttype --pkt-type multicast -j ACCEPT
    -A iTV_in -d 224.0.0.0/4 -i eth0.4 -p udp -j ACCEPT

     

Al terug bladerend viel me een opmerking van wjb op over vlan4 in de igmp proxy config en of dat niet eth0.4 moet zijn.

Het lijkt me inderdaad wel logisch de interface naam te gebruiken, derhalve kan het geen kwaad om dat nog even te proberen.

Reputatie 7

Dit is de definitie van de IGMP proxy server op mijn EdgeRouter.

 

Ja dat klopt. Ik heb FireHOL even uitgezet en met de hand een simpele iptables config gemaakt;

Dat zou alles moeten doorlaten, no blocks. Maar, nog steeds zelfde verhaal. Ik zal toch ergens iets moeten uit- of aanzetten.

Hoi,

zag dat je op mijn (misschien iets teveel Gentoo specifieke) topic een melding had achtergelaten. Twee dingetjes:

  1. Ik heb moeten constateren dat de opgegeven IP ranges (213.75.0.0/16 en 217.166.0.0/16) voor KPN niet alles-dekkend zijn en gebruik tegenwoordig 0.0.0.0/0 als `altnet` instelling. Of dat een beveiligingsrisico inhoudt weet ik niet, maar omdat de communicatie in mijn situatie tot een geïsoleerd intern vlan is beperkt maak ik mij daar niet echt druk om
     
  2. Als je beeld krijgt dan impliceert dit dat IGMPProxy werkt. Het stokken van het beeld duidt op een probleem met multicast routing, hetzij intern dan wel extern. Strikt genomen zou dat een probleem kunnen zijn met de switches die je gebruikt, maar ik zou beginnen met je firewall regels. Dit zijn de regels die ikzelf gebruik:
     :iTV_fwd
    :iTV_in
    -A INPUT -i eth0.4 -j iTV_in
    -A FORWARD -i eth1.2022 -j iTV_fwd
    -A FORWARD -i eth0.4 -j iTV_fwd
    -A iTV_fwd -i eth0.4 -m pkttype --pkt-type multicast -j ACCEPT
    -A iTV_fwd -d 10.20.22.0/24 -i eth0.4 -j ACCEPT
    -A iTV_fwd -d 224.0.0.0/4 -i eth0.4 -p udp -j ACCEPT
    -A iTV_fwd -i eth1.2022 -o eth0.4 -j ACCEPT
    -A iTV_fwd -i eth1.2022 -o ppp0 -j ACCEPT
    -A iTV_fwd -j REJECT --reject-with icmp-port-unreachable
    -A iTV_in -m pkttype --pkt-type multicast -j ACCEPT
    -A iTV_in -d 224.0.0.0/4 -i eth0.4 -p udp -j ACCEPT

     

Ik heb jaren lang nog Gentoo gebruikt, maar in mijn werk is bijna alles Ubuntu, dus tja. Die originele post is ook waar ik op triggerde om hier wellicht aan antwoord te vinden. Je hebt een apart VLAN voor je STB, dat kan ik ook maken als het perse nodig is. Ik zal je regels doorspitten en op mijn situatie van toepassing maken. Kijken of het helpt. 

Mijn switches vermoed ik zijn goed, want met de experia box erin werkt het wel. Ik denk dus ook firewall. Mijn firewall heeft.

Mijn interface heet ook echt VLAN4, zo gedefinieerd;

# IPTV
auto vlan4
iface vlan4 inet manual
pre-up ip link add link eth0 name vlan4 type vlan id 4
up ip link set up dev vlan4
post-up dhclient vlan4
pre-down dhclient -x
down ip link set down dev vlan4
post-down ip link delete vlan4

 

Dit is de definitie van de IGMP proxy server op mijn EdgeRouter.

 

Jup. Das hetzelfde, op het Lan en ppp naam na.

Reputatie 4
Badge +1

Ik heb jaren lang nog Gentoo gebruikt, maar in mijn werk is bijna alles Ubuntu, dus tja. Die originele post is ook waar ik op triggerde om hier wellicht aan antwoord te vinden. Je hebt een apart VLAN voor je STB, dat kan ik ook maken als het perse nodig is. Ik zal je regels doorspitten en op mijn situatie van toepassing maken. Kijken of het helpt. 
 

Intern vlan is niet noodzakelijk voor de werking. Ik ben er zelf alleen niet zo happig op dat iemand via een doosje waar ik zelf niet de controle over heb op mijn interne netwerk kan rondsnuffelen. Voor de firewall regels die ik hierboven poste maakt het eveneens niet zo heel veel uit. Kwestie van andere interface namen invoeren, maar dat moest je toch al doen omdat jouw systeem een andere alias gebruikt voor wat bij mij eth0.4 is.

Ja. Security by default, die filosofie snap ik. Ik heb ook geen chinese IP Cams meer zullen we maar zeggen.

Ik heb dit aan iptables regels gemaakt;

iptables -t nat -A POSTROUTING -o vlan4 -d 213.75.112.0/21  -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --set-mss 1412

iptables -A INPUT -i vlan4 -j ACCEPT
iptables -A FORWARD -i vlan4 -j ACCEPT

iptables -A FORWARD -i vlan4 -m pkttype --pkt-type multicast -j ACCEPT
iptables -A FORWARD -d 224.0.0.0/4 -i vlan4 -p udp -j ACCEPT

iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
iptables -A INPUT -d 224.0.0.0/4 -i vlan4 -p udp -j ACCEPT

Wat dit als listing geeft

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i vlan4 -j ACCEPT
-A INPUT -m pkttype --pkt-type multicast -j ACCEPT
-A INPUT -d 224.0.0.0/4 -i eth0.4 -p udp -j ACCEPT
-A FORWARD -i vlan4 -j ACCEPT
-A FORWARD -i vlan4 -m pkttype --pkt-type multicast -j ACCEPT
-A FORWARD -d 224.0.0.0/4 -i vlan4 -p udp -j ACCEPT

En wat weer hetzelfde effect geeft, even unicast werkt, stottert, werkt weer even, en stopt helemaal. 

Edit: handvol typos

Reputatie 4
Badge +1

hmmm… Probeer deze eens:

iptables -t raw -A PREROUTING -d 224.0.0.0/4 -i eth0.4 -p udp -m ttl --ttl-lt 7 -j ACCEPT

Ik heb overigens geen masquerading aan staan op vlan 4, dat moet immers via IGMPProxy lopen...

hmmm… Probeer deze eens:

 iptables -t raw -A PREROUTING -d 224.0.0.0/4 -i eth0.4 -p udp -m ttl --ttl-lt 7 -j ACCEPT

Ik heb overigens geen masquerading aan staan op vlan 4, dat moet immers via IGMPProxy lopen...

Zelfde situatie. Unicast → multicast happert → unicast → beeld stopt.
UDP Stream van circa 7-8 MB blijft lopen, maar komt niet naar de TV.

Zonder de 


iptables -t nat -A POSTROUTING -o vlan4 -d 213.75.112.0/21 -j MASQUERADE

Blijft het beeld helemaal zwart.

 

Reputatie 4
Badge +1

Grmbl… Ik moet beter kijken. Ik heb:

-A POSTROUTING -s 10.20.22.0/24 -o eth0.4 -j MASQUERADE

Dus wel masq, alleen staat bij mij het filter op de source en niet waar het naar toe moet. Denk alleen niet dat dit het verschil maakt. Heb je de altnet configuratie in igmpproxy.conf nog aangepast?

Grmbl… Ik moet beter kijken. Ik heb:

 -A POSTROUTING -s 10.20.22.0/24 -o eth0.4 -j MASQUERADE

Dus wel masq, alleen staat bij mij het filter op de source en niet waar het naar toe moet. Denk alleen niet dat dit het verschil maakt. Heb je de altnet configuratie in igmpproxy.conf nog aangepast?

Ja, naar 0.0.0.0/0 geen verschil :(

Reputatie 4
Badge +1

Zie dat ik in mijn eigen HowTo de firewall regels wel volledig had staan. Het lijkt daarmee allemaal wel te kloppen wat je hebt staan. Ik vermoed dan toch dat je IGMP proxy niet doet wat deze moet doen. Heb je deze geïnstalleerd als Debian/Ubuntu package? Misschien kan je proberen deze van source (link in de HowTo) te installeren. Probeer zeker ook de proxy in debug mode te laten draaien:

igmpproxy -d -n -vv 

Dit kan zomaar een aha! momentje opleveren.

Zie dat ik in mijn eigen HowTo de firewall regels wel volledig had staan. Het lijkt daarmee allemaal wel te kloppen wat je hebt staan. Ik vermoed dan toch dat je IGMP proxy niet doet wat deze moet doen. Heb je deze geïnstalleerd als Debian/Ubuntu package? Misschien kan je proberen deze van source (link in de HowTo) te installeren. Probeer zeker ook de proxy in debug mode te laten draaien:

 igmpproxy -d -n -vv 

Dit kan zomaar een aha! momentje opleveren.

Wellicht, ik heb de maker van igmpproxy op GitHub al in de discussie zitten. Ik ga vanmiddag de nieuwste versie handmatig vanaf git installen en dan de traces en logs naar hem sturen.

Reputatie 7
Badge +8

Ik heb vandaag me USG P3 aangesloten met deze hulppagina (coolhva) werkt prima alleen is het wel vaag dat hij als ik op de wan port druk bij Devices ik ip adres 0.0.0.0 krijgt te zien terwijl ik wel op internet kan en alles ook werkt TV enz

was wel even puzzelen maar werkt

Sinds kort heb ik wat problemen met de Wi-Fi. Ik gebruik de Edgerouter4 met Unify AP lite AP's (x3). Regelmatig heb ik dat als mijn apparaat van AP verandert door naar een andere verdieping te gaan, de Wi-fi netjes naar een ander AP roamt, maar ik daarmee de melding zie 'Wi-Fi verbonden, geen internet'. Ik heb niets aan instellingen veranderd. Wel heb ik mijn abonnement omgezet naar Hussel 1gbit.

Intussen heb ik;
- Instellingen van AP's naar allerlei mogelijke combinaties aangepast.
- De AP's en hun controller een fabrieksreset gegeven en opnieuw ingesteld.
- Uiteraard alles meerdere malen opnieuw opgestart, uit/aan, powercycle.

Ik begin nu te vermoeden dat het aan de ER4 ligt. Ik heb immers Wi-Fi verbinding, alleen geen internet. Het vreemde daarbovenop is dat het probleem zich niet altijd voordoet (~1x per dag), en de meeste tijd het wél goed gaat. 

Daarbij de vragen;
- Kan dit probleem liggen aan het veranderen van mijn abonnement (500mbit, naar hussel1gbit)?
- Kan dit probleem in de ER4 zitten, zijn het echt de AP’s die in storing zitten?
- Wat kan ik in de ER4 aanpassen wat dit überhaupt zou kunnen beïnvloeden?

Reputatie 7

@Valigarmanda , Heb jij IPv6 actief?

Reputatie 7
Badge +8

@wjb aan wie vraag je dat?

 

Reageer