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.
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...