Skip to main content

Onderstaande gaat er vanuit dat je reeds beschikt over een Linux machine welke je gebruikt om KPN internet op jouw LAN omgeving ter beschikking te stellen.

Indien je dezelfde instructies hebt gevolgd welke ik jaren terug zelf via het internet heb gevonden dan ben je in het bezit van een redelijk prijsgunstige switch met ondersteuning voor het 802.1q protocol, waarschijnlijk een Netgear GS105E Pro of de 8-poorts variant daarvan, en heb je deze vóór je router staan om de VLAN’s te splitten én distribueren. Sinds medio november 2019 levert dit een nogal vervelende melding op de iTV kastjes op en dit komt doordat deze buiten het streaming netwerk dat via VLAN-4 wordt aangeboden andere internetdiensten willen gebruiken welke KPN nu via datzelfde netwerk heeft geblokkeerd. Dit houdt in dat deze diensten nu via de normale internetconnectie moeten lopen, hetgeen inhoudt dat de iTV kastjes in ons interne netwerk zouden moeten staan. Aangezien wij reeds over een 802.1q capabele switch beschikken gaan wij dat natuurlijk niet doen ;)

Mijn hardware is een Excito B3, gebaseerd op een ARMv5te Marvell SoC met twee (echte) gigabit poorten, optionele WiFi via de PCI-e poort en twee SATA poorten waarvan een intern. Het oorspronkelijke besturingssysteem van deze machine is Debian Squeeze met een noob interface, maar ik draai Gentoo met een door mijzelf geporteerde versie van die noob interface, gewoon omdat het kan. Waarmee ik wil zeggen dat je geen extreem dikke machine nodig hebt én dat onderstaande netwerkconfiguratie betrekking heeft op netifrc en je deze dus zal moeten vertalen naar je eigen Linux smaak.

Stap 1:
Indien je ook vaste telefonie hebt via KPN en daarvoor de Experia router als VOIP interface achter de primaire switch hebt opgenomen, configureer dan de switch om VLAN-4  als "tagged” naar je router door te geven. Voor de volgende stap veronderstel ik dat je voor dezelfde poort VLAN-6 eveneens wijzigt van “untagged” naar “tagged”.
Plug anders de kabel van je glasvezelkastje over van de switch rechtstreeks naar je router machine

Stap 2:
Definieer de VLAN ID’s (netifrc)

config_eth0="null"
rc_net_eth0_provide="!net"
vlans_eth0="4 6"

# vlan voor iTV
config_eth0_4="dhcp"
dhcpcd_eth0_4="-i IPTV_RG" # bedankt @wjb
rc_net_eth0_4_provide="!net"
rc_net_eth0_4_need="net.eth0"

# vlan voor internet via PPPoE
config_eth0_6="null"
rc_net_eth0_6_provide="!net"
rc_net_eth0_6_need="net.eth0"

Verander “link_ppp0” van eth0 naar eth0.6 en herstart zowel eth0 als de ppp interface om te controleren dat je internet nu ook werkt zonder dat de switch eerst de VLAN-6 tag heeft gestript
Hint: je kunt dit ook zonder de kabel om te pluggen testen door via de ProSAFE Plus utility de betreffende poort om te zetten van “untagged” naar “tagged”.

Stap 3:
Na de herstart van eth0 zou je nu ook een interface eth0.4 moeten hebben en daar een 10.x.x.x adres op zien. Mocht je een andere dhcp client gebruiken dan DHCPCD en geen IP adres zien, dan zul je zelf moeten uitvinden hoe je de “vendor class ID” moet doorgeven (dat is dus "IPTV_RG”).

Stap 4:
Creëer een nieuw VLAN op je interne netwerk (netifrc)

 

vlans_eth1="1921"

# vlan voor communicatie met iTV LAN (ASCII 84 86 = "TV")
config_eth1_1921="10.84.86.254 netmask 255.255.255.0 brd 10.84.86.255"
rc_net_eth1_1921_need="net.eth1"

Stap 5:
Voeg het nieuwe VLAN ID toe aan je switch configuratie: “tagged” op de LAN poort van je router en “untagged” op de poort waar het iTV kastje moet komen.

Stap 6:
Voeg het nieuwe IP segment toe aan je DHCP server. Voor DNSmasq ziet dat er zo uit:

interface=eth1.1921

# Set range for a maximum of 5 clients
dhcp-range=eth1.1921,10.84.86.2,10.84.86.6,1h

# Set DNS servers to Google DNS
dhcp-option=eth1.1921,6,8.8.8.8

# Set default route
dhcp-option=eth1.1921,3,10.84.86.254

Controleer eventueel met een laptop of iets dergelijks of je ook echt een adres in deze range ontvangt op deze specifieke switch poort.

Stap 7:
Je kan het amper verzinnen, maar omdat het protocol voor de streaming helemaal niet gerouteerd kan worden moet je een proxy installeren. In de meeste distributies is “igmpproxy” wel te vinden. In Gentoo is deze gemaskeerd als zijnde niet helemaal hoe het netwerk zich zou moeten gedragen. Mocht het in jouw distributie helemaal niet worden aangeboden dan kan je de source hier vinden: https://github.com/pali/igmpproxy

Wijzig de inhoud van /etc/igmpproxy.conf als volgt:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave

##------------------------------------------------------
## Disabled Interfaces
##------------------------------------------------------

# real interface - no untagged traffic there
phyint eth0 disabled
# virtual WLAN ID 6 - carrier for PPPoE connection
phyint eth0.6 disabled
# internet connection
phyint ppp0 disabled

# real lan interface
phyint eth1 disabled

# do tag any other interfaces your system may contain as
# disabled as well
# ...

##------------------------------------------------------
## Downstream Interface
##------------------------------------------------------
phyint eth1.1921 downstream ratelimit 0 threshold 1


##------------------------------------------------------
## Upstream Interface
##------------------------------------------------------
phyint eth0.4 upstream ratelimit 0 threshold 1
altnet 10.84.86.0/24 # that's my local segment
altnet 213.75.0.0/16
altnet 217.166.0.0/16


Stap 8:
De volgende iptables regels moeten worden toegevoegd:

*filter
-N iTV_fwd
-N iTV_in
-A FORWARD -i eth1.1921 -j iTV_fwd
-A FORWARD -i eth0.4 -j iTV_fwd
-A INPUT -i eth0.4 -j iTV_in
-A iTV_fwd -i eth0.4 -m pkttype --pkt-type multicast -j ACCEPT
-A iTV_fwd -d 10.84.86.0/24 -i eth0.4 -j ACCEPT
-A iTV_fwd -o eth0.4 -j ACCEPT
-A iTV_fwd -o ppp0 -j ACCEPT
-A iTV_fwd -j REJECT
-A iTV_in -m pkttype --pkt-type multicast -j ACCEPT

*nat
-A POSTROUTING -s 10.84.86.0/24 -o eth0.4 -j MASQUERADE

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


Stap 9:
Nog één ding te doen. Wijzig in de ProSAFE Plus utility het ID voor IGMP Snooping van ‘4’ naar ‘1921’

Sluit het iTV kastje aan en als het goed is start deze helemaal door, krijg je langer dan 10 seconden beeld en heb je ook weer een menu.
 

Vandaag stond toch weer het beeld na tien seconden stil, ondanks geen meldingen van igmpproxy. Toch maar het altnet naar 0.0.0.0/0 gewijzigd en voila! Wat een geluk dat die iTV doosjes niet met de rest van mijn netwerk kunnen communiceren. Ik word echt steeds blijer dat ik die Experiabox die ik vorig jaar opgestuurd kreeg nog onuitgepakt in de doos heb liggen.


@Erik_ Het VLAN ID mag niet hoger zijn dan 4096. Iedere instantie van het getal 8486 zonder puntjes of spaties er tussen dient derhalve te worden gewijzigd naar een getal binnen de geldige range. Dus wel “eth1_8486” en “eth1.8486”, maar niet “84.86”. Maak er maar 1921 van - dat is ("TV” - “AA”).

Done.


Voor wat het waard is, een doel van mij was om ook virtualisatie op SoC’s met Cortex-A7 te hebben. Dat is namelijk de eerste/simpelste processorkern waarbij ARM hardware virtualisatie mogelijk gemaakt. O.a. RaspberryPi2 en BananaPi hebben een Cortex-A7. Bij gebrek aan VLAN ondersteuning is er dan een andere scheidingsmogelijkheid. Is dan wel zelf de kernel compileren enz.

Maar sinds kort zijn er images voor 64-bit ARM-cores van Ubuntu-server 19.10 beschikbaar, en dat blijkt zonder veel werk draaiend te krijgen op RaspberryPi4 (Cortex-A72) en  RaspberryPi3 (Cortex-A53). Als ik alleen SD-card en Gigabit switch en USB-poweradaptor heb aangesloten, blijken beide in rust ongeveer 0,55A te trekken, dus minder dan 3 Watt. Een RaspberryPi0 met een aangesloten microUSB 100Mbps RJ45 ethernet adaptor ongeveer 0,12A, dus ruim minder dan 1 Watt, wat soms nog veel te veel is voor een batterij.

Als ik wireguard aanzet in een virtuele machine met maar 1 processorkern toegewezen op de RaspberryPi4 en dan met iperf3 een speedtest doe naar een cloudcomputer,  haalt ie de volle 150Mbps van de glasvezel en is de load ongeveer 44%. Het lijkt dus wel bruikbaar ter vervanging van Intel PC en dan met gebruik van VLANs op de ene enkele Gbit poort van de RaspberryPi4.


Klopt. Nieuwste Pi heeft USB3 en die heeft dus de limiet op 540Mbit. Voor iets dat uitsluitend als router wordt ingezet zal dat veelal meer dan genoeg zijn. VLAN ondersteuning is overigens in principe niets meer dan `vconfig` installeren en volgens mij moet dat ook prima werken met Raspbian, maar het kan zijn dat je ook nog de 8021q module voor je kernel nodig hebt. Dat kan best een uitdaging zijn als je niet echt kaas hebt gegeten van Linux.


Als je vlan's gebruikt, en je wilt veel data transporteren naar een pc in een ander vlan, dan moet dat allemaal via die Pi, heen en terug, dus halve snelheid. Als die dat maar max 540 Mbit aan kan, dan gaar dat nooit sneller dan 270 Mbit, wat neerkomt op 33,75 Mb/s. Klopt dit? Of beredeneer ik nu fout?


Klopt. Nieuwste Pi heeft USB3 en die heeft dus de limiet op 540Mbit.

De RasberryPi4B heeft een BCM54213 ethernet controller met RGMII interface naar de SoC. Dat haalt gewoon 1Gbps Rx  en 1Gbps Tx simultaan. Ik weet niet hoe je bij die 540Mbit. De USB3 controller is via PCI-E aan gesloten op de SoC, dus bidirectioneel 5Gbps. Ik heb een oude SSD via een SATA-USB3 adapter aangesloten, en die haalt zo’n 300MByte/s, schrijven minder snel, maar dat is een kwestie van een modernere SSD aansluiten. Is in ieder geval een wereld van verschil met SDcard. 

De RasberryPi3B+ heeft z’n gigabit inderdaad via USB2 aangesloten, is dus maar halfduplex ongeveer 300Mbps. Zou 

 

Voor iets dat uitsluitend als router wordt ingezet zal dat veelal meer dan genoeg zijn. VLAN ondersteuning is overigens in principe niets meer dan `vconfig` installeren en volgens mij moet dat ook prima werken met Raspbian, maar het kan zijn dat je ook nog de 8021q module voor je kernel nodig hebt. Dat kan best een uitdaging zijn als je niet echt kaas hebt gegeten van Linux.

In hele simpele ethernet adapters of hardware zit vaak geen VLAN ondersteuning en ik gebruik ook een halfduplex switch (100Mbps). En VLAN capabele switch vreet weer te veel stroom (draait op battery/solar), dus vandaar ik zat te kijken naar iets met lichtgewicht VPN of andere UDP-tunnel virtueel netwerking. 


Als je vlan's gebruikt, en je wilt veel data transporteren naar een pc in een ander vlan, dan moet dat allemaal via die Pi, heen en terug, dus halve snelheid. Als die dat maar max 540 Mbit aan kan, dan gaar dat nooit sneller dan 270 Mbit, wat neerkomt op 33,75 Mb/s. Klopt dit? Of beredeneer ik nu fout?

Ik had/heb als plan om een managed switch in te zetten en dan een Pi met 2 VLANs te bestoken, het LAN en het WAN van de provider. B.v. NFS verkeer tussen NAS en werkstation gaat direct in het LAN subnet, alleen dus door de switch. Alleen verkeer naar buiten, dus VPN naar cloud enz gaat via de Pi4. Ik heb 150Mbps glasvezel, dat gaat makkelijk. Wil nog wel kijken of Pi3B+ ook voldoende is, want die Pi4 blijkt verassend snel, dus een beetje overkill.


VLAN ondersteuning is overigens in principe niets meer dan `vconfig` installeren en volgens mij moet dat ook prima werken met Raspbian, maar het kan zijn dat je ook nog de 8021q module voor je kernel nodig hebt. Dat kan best een uitdaging zijn als je niet echt kaas hebt gegeten van Linux.

Voor Raspbian is /etc/network/interfaces waar men VLANs en bridges kan definieren. Voor Debian Stretch had ik diverse constructies om flexibel 4G USB apparaten via ethernet kabel beschikbaar te hebben. Alleen even wat packages voor bridging en VLAN toevoegen. Voor Opensuse Tumbleweed is het weer een heel andere set van tools, maar is ook goed te doen. Met NetworkManager is het ook goed te doen, alleen nog niet grafisch, dat zou wel handig zijn op laptop.

Maar met kernel compileren doelde ik eigenlijk op KVM support. Dat is in Raspbian niet meegenomen, en Armbian weet ik zo niet, maar denk het ook niet. Ik heb o.a. wel aan kernelpatching gedaan, maar iets van de plank is vele malen sneller is mijn ervaring als het gaat om diverse ARM SoCs. Ook in de 32-bit Ubuntu server SDcard image zit KVM ‘erin’, i.i.g. is /dev/kvm zichtbaar. Echter alleen op een Cortex-A7 (Pi2), niet op Cortex-A53 (Pi3). Het blijkt dat (vooralsnog?) ‘bitbreedte’ van KVM host en KVM guest zelfde moet zijn voor ARM CPU’s, is niet zo voor Intel CPU’s.

 


Juist. Ik ben wellicht wat standaarden door elkaar aan het gooien. Moet zeggen dat het me bevreemd dat er een full duplex gigabit NIC zou bestaan welke geen VLAN ondersteuning heeft. In hoeverre een dergelijke NIC zin heeft in een machine als een Pi ontgaat mij ook enigszins - echt de enige reden die ik kan verzinnen is een "poor man’s firewall” die een streaming service moet ondersteunen. Hetgeen dan op zich wel weer een raakvlak heeft met deze HowTo, maar zelf zou ik toch niet zo snel voor een dergelijke oplossing gaan.

 

Kan mezelf op zich overigens prima voorstellen dat in de Raspbian kernel niet echt rekening is gehouden met de mogelijkheid om virtualisatie toe te passen. Daar wil graag in ieder geval ook beduidend meer geheugen in hebben dan de pi biedt.


Moet zeggen dat het me bevreemd dat er een full duplex gigabit NIC zou bestaan welke geen VLAN ondersteuning heeft. In hoeverre een dergelijke NIC zin heeft in een machine als een Pi ontgaat mij ook enigszins - echt de enige reden die ik kan verzinnen is een "poor man’s firewall” die een streaming service moet ondersteunen.

Ik heb o.a. een kast in het veld staan met als netwerk I/O punt een ubiquiti nanostation loco m2. Die kan wel VLAN, maar o.a. een camera in dat ‘solarkastnetwerkje’ niet. En ook de switch niet, maar de BananaPi natuurlijk wel. Maar voert veel te ver off-topic.

Hetgeen dan op zich wel weer een raakvlak heeft met deze HowTo, maar zelf zou ik toch niet zo snel voor een dergelijke oplossing gaan.

De reacties blijken hoofdzakelijk te gaan over het hard- en software platform wat iemand voor de iTV code zou kunnen gebruiken. Zoals je al aangaf, is dat specifeke board speciaal voor jouw, maar anderen zullen denk ik wat anders kiezen. Router-generiek zie ik nu minder noodzaak tot 2 Ethernet poorten, dat maakt de keuze veel diverser kwa hardware, als iemand losse, niet-virtuele hardware wil. De 1GB variant van b.v. de Pi4B i.c.m. managed switch zou denk ik gunstiger zijn dan dat Armbiam-supported Dual-Fast-ethernet boardje waar ik eerder naar linkte. Maar goed, keuze opties te over.


Hmmm, ja. In het oorspronkelijke idee van de poor man’s firewall werd natuurlijk niet met VLAN’s gewerkt maar met verschillende IP segmenten. VLAN tagging zorgt met zekerheid voor meer veiligheid in het gescheiden houden van die segmenten.

 

In dit geval zal je echter wel degelijk minimaal twee ethernetkaarten nodig hebben en dat is omdat IGMP snooping maar op één VLAN wordt ondersteund (in de NetGear Pro switches). Wanneer je zowel WAN als LAN over dezelfde switch gooit om met die ene NIC in de Pi te kunnen verbinden, dan moet je voor iTV dus VLAN 4 aanwijzen voor IGMP snooping, maar dan moet dit vervolgens ook het VLAN nummer zijn voor de LAN koppeling met het ontvangerkastje. De stromen zijn dan niet meer gescheiden en het kastje ziet dan onder andere twee DHCP servers welke totaal verschillende IP adressen uitgeven: die van jouw Pi en die van KPN en dan raakt de poep de ventilator.


... en dan raakt de poep de ventilator.

:astonished::astonished:


In dit geval zal je echter wel degelijk minimaal twee ethernetkaarten nodig hebben en dat is omdat IGMP snooping maar op één VLAN wordt ondersteund (in de NetGear Pro switches).

Ja, dan is 1 ethernetpoort een no-go, of je moet al 2 switches hebben, maar dan is het toch beter om voor extra ethernet aansluiting te gaan. Binnen dit type switch is natuurlijk maar 1 VLAN_ID namespace.

Of je kan volstaan met zo’n simpel 100Mbps USB2 adaptertje is even de vraag. Er zijn er een hoop waarvan de chipset aan de USB kant maar tot Full-speed (12Mbps) gaat, genoeg ervaring mee. Weet (nog) niet in hoeverre de exemplaren die ik heb VLAN in de hardware aankunnen, maar daar kom ik t.z.t. wel achter.

Wanneer je zowel WAN als LAN over dezelfde switch gooit om met die ene NIC in de Pi te kunnen verbinden, dan moet je voor iTV dus VLAN 4 aanwijzen voor IGMP snooping, maar dan moet dit vervolgens ook het VLAN nummer zijn voor de LAN koppeling met het ontvangerkastje. De stromen zijn dan niet meer gescheiden en het kastje ziet dan onder andere twee DHCP servers welke totaal verschillende IP adressen uitgeven: die van jouw Pi en die van KPN en dan raakt de poep de ventilator.

Ik heb tegenwoordig glasvezelinternet vanuit het glasvezelbuitenaf project, zonder TV service. Mijn laaste abo in NL was nog analoog van UPC, maar wat ik zo lees over de TVkastjes en ook b.v. de ontwikkelingen bij T-Mobile Thuis, trek ik de conclusie dat de KPN TVkastjes VLAN agnostisch zijn. Dus in de router is dan binnenkomend VLAN_ID 4, maar uitgaand kan dus iets anders zijn, wat je in Stap 9 doet. Over de kabel tussen switch en TVkastje gaan dus alleen maar een untagged ethenernet frames. Klopt dit?

Ik zie het dan zo, dat IGMP snooping geen zin heeft. Een tabel met de VLAN config van de switch kan verduidelijken, want de eeste zin in de tweede alinea in de openingspost is nogal a-specifiek.


Ik zie het dan zo, dat IGMP snooping geen zin heeft. Een tabel met de VLAN config van de switch kan verduidelijken, want de eeste zin in de tweede alinea in de openingspost is nogal a-specifiek.

 

Even kijken of ik de situatie een beetje kan schetsen (zonder telefoon).

 

poort naam iTV Inet VOIP VLAN-1 VLAN-1921
1 WAN t t t    
2 router/firewall t t   t of u t
3 iTV         u
4 LAN-1       u  
5 LAN-2       u  
6 LAN-3       u  
7 LAN-4       u  
8 LAN-5       u  

 

Het probleem hierin is dus dat de IGMP snooping in dit geval aan moet staan op zowel VLAN-4 als VLAN-1921, want anders staat het beeld na maximaal 10 seconden stil. Omdat VLAN-4 extern opgelegd is kan je vanwege die IGMP afhankelijkheid in dit geval niet anders dan het LAN verkeer voor iTV eveneens via VLAN-4 laten lopen en dat betekent dat het u-tje in regel 3 verhuist van kolom 6 naar kolom 2. Het directe gevolg daarvan is echter dat poort 3 van de switch nu niet meer alleen een verbinding kan maken met poort 2, maar tevens met poort 1 en dat is nu juist wat niet meer mag.

 

Dit heb ik dus inderdaad in mijn openingsbericht ook niet helemaal goed staan. Voor iTV kunnen WAN en LAN niet via een en dezelfde switch lopen.


Voor iTV kunnen WAN en LAN niet via een en dezelfde switch lopen.

Dan kan prima, IGMP snooping hoeft alleen aan de LAN zijde actief te zijn.


Het blijkt dat (vooralsnog?) ‘bitbreedte’ van KVM host en KVM guest zelfde moet zijn voor ARM CPU’s, is niet zo voor Intel CPU’s.

Het vraagteken kan weg, want ik heb nu een 32-bit ARM virtuele machine draaien op 64-bit ARM host met volledige hardware versnelling. Dus Ubuntu server 64-bit op RaspberryPi4 met daarbinnen een Debian 32-bit virtuele machine waarop ik nu in Firefox dit bericht type. Zonder KVM hardware versnelling is het totaal onbruikbaar, veel te langzaam, maar met is het een soort snelle RaspberryPi2 binnen een RaspberryPi4.


Dit topic is het dichtste bij wat ik kon vinden over mijn specifiek issue, wat ik hier beschrijf; https://forum.kpn.com/thuisnetwerk-72/gebruik-een-eigen-router-i-p-v-de-experia-box-458609/index125.html


Met het risico van en excuus voor cross-posting en het heropenen van oude threads; het zou toch gewoon moeten kunnen? Normale Ubuntu Linux install met 2 fysieke netwerkkaarten en dan IPTV en internet werkend? 


Gordonb3 Hoe is je igmpproxy nu geconfigureerd? als ik 0.0.0.0/0  als altnet invul start hij niet.

onfig: IF: Got altnet token 0.0.0.0/0.
The bits part of the address is invalid : 134549976.
Unable to parse subnet address.
Unknown token '0.0.0.0' in configfile
Unable to load config file...