OPNsense & pfSense KPN/Telfort IPTV how-to

[Theone098]

Ik krijg mijn KPN /xs4all iptv kastje icm PFsense + (24.11) niet meer aan de praat. Als ik het fritzbox modem gebruik, werkt het. Ik heb al van alles geprobeerd en ik zie t.o.v. de OP geen vreemde zaken (krijg ip-adressen en zie ook verkeer op het IPTV WAN en LAN). Default route aangepast zoals hierboven.

De Arris 5202 komt niet voorbij de 85%. Ik zie het volgende in het system/routing log:
2025-02-03 11:01:09.511393+01:00 igmpproxy 69935 select() failure; Errno(4): Interrupted system call
2025-02-03 11:00:34.396650+01:00 igmpproxy 46079 Sender VIF was down.; Errno(50): Network is down
2025-02-03 10:37:01.168453+01:00 igmpproxy 39001 select() failure; Errno(4): Interrupted system call
2025-02-03 10:36:29.374159+01:00 igmpproxy 13674 There must be at least 1 Vif as upstream.

Met name deze: There must be at least 1 Vif as upstream.

Iemand die mij een zetje in de goede richting kan geven?

[Lethalis]

Theone098 schreef op maandag 3 februari 2025 @ 12:18:
Met name deze: There must be at least 1 Vif as upstream.

Iemand die mij een zetje in de goede richting kan geven?

Je moet altijd een upstream interface hebben.

Heb je al gekeken of die nog goed geconfigureerd staat?

Ik heb zelf in mijn opnsense config de volgende interfaces:

code:

IPTV upstream 0.0.0.0/1, 128.0.0.0/1 IPTV upstream
STB downstream 192.168.15.0/24 IPTV downstream

Bij mij zit het TV kastje in zijn eigen STB netwerk, maar goed.

Tips die ik verder op internet zie:
1. Have you tried turning it off and on again? Reboot, soms ziet de igmp proxy de interfaces niet goed.
2. De service stoppen in de UI en via de terminal "igmpproxy -vd /var/etc/igmpproxy.conf" uitvoeren. Dit start de IGMP proxy in verbose mode. Hopelijk krijg je dan meer informatie.

[Theone098]

Lethalis schreef op maandag 3 februari 2025 @ 15:00:
[...]

Je moet altijd een upstream interface hebben.

Heb je al gekeken of die nog goed geconfigureerd staat?

Ik heb zelf in mijn opnsense config de volgende interfaces:

code:

IPTV upstream 0.0.0.0/1, 128.0.0.0/1 IPTV upstream
STB downstream 192.168.15.0/24 IPTV downstream

Bij mij zit het TV kastje in zijn eigen STB netwerk, maar goed.

Tips die ik verder op internet zie:
1. Have you tried turning it off and on again? Reboot, soms ziet de igmp proxy de interfaces niet goed.
2. De service stoppen in de UI en via de terminal "igmpproxy -vd /var/etc/igmpproxy.conf" uitvoeren. Dit start de IGMP proxy in verbose mode. Hopelijk krijg je dan meer informatie.

Dank je. Het is gelukt. Uiteindelijk zat het in de config van de iptv WAN fw rules. Ik moest daar het nieuwe adres ook toevoegen.

Tjonge, dat heeft wat tijd gekost

[stormfly]

Theone098 schreef op maandag 3 februari 2025 @ 15:37:
[...]

Dank je. Het is gelukt. Uiteindelijk zat het in de config van de iptv WAN fw rules. Ik moest daar het nieuwe adres ook toevoegen.

Tjonge, dat heeft wat tijd gekost

Voor UDP en IGMP heb ik die FW rules volledig open staan voor het STB subnet, een extra laag beheer die je kan nekken als iets niet werkt als je daar ook rules plaatst.

[Riddertommie]

Hallo, ik ben recentelijk overgestapt naar TV+ van KPN (2x android box) naar wat ik begreep zijn er dan geen problemen meer met het vastlopen van het beeld bij het gebruik van OPNsense

Nu wilde ik dus gebruik maken van OPNsense 25.1 alleen is daar geloof ik wat veranderd met het instellen van PPPoe deze optie is gewoon niet meet zichtbaar bij wan instellingen.

Doe ik iets fout?

[Arnout]

Riddertommie schreef op maandag 10 februari 2025 @ 15:22:
Hallo, ik ben recentelijk overgestapt naar TV+ van KPN (2x android box) naar wat ik begreep zijn er dan geen problemen meer met het vastlopen van het beeld bij het gebruik van OPNsense

Nu wilde ik dus gebruik maken van OPNsense 25.1 alleen is daar geloof ik wat veranderd met het instellen van PPPoe deze optie is gewoon niet meet zichtbaar bij wan instellingen.

Doe ik iets fout?

Uit de changelog:

PPP devices can no longer be configured on the interface settings page. To edit the device settings use the native PPP device edit page instead.

[Riddertommie]

Arnout schreef op maandag 10 februari 2025 @ 15:37:
[...]


Uit de changelog:

[...]

@Arnout

Ja die had ik gelezen maar dat lost het niet echt op (teminste dat denk ik).

Zodra ik een vlan aanmaak (vlan6) en dit vlan aan het WAN koppel kan ik geen pppoe kiezen bij IPv4 config type. Ook niet als ik eerst zelf een pppoe interface aanmaak zoals jij aangeeft.

[barrymossel]

Riddertommie schreef op maandag 10 februari 2025 @ 15:44:
[...]


@Arnout

Ja die had ik gelezen maar dat lost het niet echt op (teminste dat denk ik).

Zodra ik een vlan aanmaak (vlan6) en dit vlan aan het WAN koppel kan ik geen pppoe kiezen bij IPv4 config type. Ook niet als ik eerst zelf een pppoe interface aanmaak zoals jij aangeeft.

Je moet een pppoe0 aanmaken bij Interfaces > Devices > Point-to-point met vlan6. Dan bij Interfaces > Assignments je pppoe0 kiezen bij je WAN interface. Duurde bij mij ook even voordat ik dat doorhad.

[Riddertommie]

barrymossel schreef op maandag 10 februari 2025 @ 18:27:
[...]

Je moet een pppoe0 aanmaken bij Interfaces > Devices > Point-to-point met vlan6. Dan bij Interfaces > Assignments je pppoe0 kiezen bij je WAN interface. Duurde bij mij ook even voordat ik dat doorhad.

Deze houd ik even achter de hand. Wat ik nu heb gedaan is de wizard opgestart daar kun je wel kiezen voor pppoe. als dat niet werkt dan verdiep ik mij in jou tip.

Bedankt!

[Riddertommie]

barrymossel schreef op maandag 10 februari 2025 @ 18:27:
[...]

Je moet een pppoe0 aanmaken bij Interfaces > Devices > Point-to-point met vlan6. Dan bij Interfaces > Assignments je pppoe0 kiezen bij je WAN interface. Duurde bij mij ook even voordat ik dat doorhad.

Het is mij niet gelukt. heb jij dit wel voor elkaar gekregen? OPNsense 25.1 met KPN? of is dit niet wat je aan het doen was?

Hoor graag.

[barrymossel]

Riddertommie schreef op dinsdag 11 februari 2025 @ 20:34:
[...]


Het is mij niet gelukt. heb jij dit wel voor elkaar gekregen? OPNsense 25.1 met KPN? of is dit niet wat je aan het doen was?

Hoor graag.

Letterlijk 1,5 week geleden ongeveer. Kostte me wat moeite, aangezien ik doorgaans (ook) step-by-step tutorials volg en deze niet meer overeenkomen (bijvoorbeeld ook dat de VLANs op een andere plek staan - volgens mij was de officiële documentatie ook niet geüpdatet). Maar uiteindelijk is het gewoon gelukt. KPN, TV+, OPNSense in ProxMox (maar dat zou geen verschil moeten maken). Ik heb uiteindelijk onder andere deze gebruikt: https://wiki.kaldenhoven....rk/opnsense-kpn-glasvezel

Schets anders even je eigen situatie. Welke hardware? Welke kabel loopt van welk apparaat naar welk apparaat. En maak vooral even screenshots van:

• VLAN overzicht (Interface > Devices > VLAN)
• Interfaces overzicht (Interfaces > Assignments)
• PPPoE configuratie (Interface > Devices > Point-to-point)
• WAN configuratie (Interfaces > [WAN])

Zonder dat is het voor iedereen gissen. Elk klein dingetje verkeerd kan ervoor zorgen dat het niet werkt (weet ik uit ervaring).

[Riddertommie]

barrymossel schreef op woensdag 12 februari 2025 @ 08:17:
[...]

Schets anders even je eigen situatie. Welke hardware? Welke kabel loopt van welk apparaat naar welk apparaat. En maak vooral even screenshots van:

• VLAN overzicht (Interface > Devices > VLAN)
• Interfaces overzicht (Interfaces > Assignments)
• PPPoE configuratie (Interface > Devices > Point-to-point)
• WAN configuratie (Interfaces > [WAN])

Zonder dat is het voor iedereen gissen. Elk klein dingetje verkeerd kan ervoor zorgen dat het niet werkt (weet ik uit ervaring).

Ik doe niet hele gekke dingen geloof ik. Ik wil mijn bestaande modem (box 10) vervangen door opnsense welke ik draai op Proxmox die weer draait op een Lenovo m700 mini pc met twee netwerkkaarten.

Ik heb het zover voor elkaar dat ik via het opstarten (cmd) keurig 3 ip adressen krijg en ook de juiste. alleen werkt het niet.

mijn pc zelf krijgt ook keurig een IP via dhcp met juiste waarden. Ik zie het gewoon niet. Ik ben nu terug op de KPN router en omdat anders de rest van het huis (lees de kinderen) geen internet meer hebben. zodra ik weer tijd heb zal ik screenshots maken.

Iedere hulp/tips welkom

Bedankt!

[NIK0]

Riddertommie schreef op dinsdag 11 februari 2025 @ 20:34:
[...]


Het is mij niet gelukt. heb jij dit wel voor elkaar gekregen? OPNsense 25.1 met KPN? of is dit niet wat je aan het doen was?

Hoor graag.

@Riddertommie Misschien nog een idee, als je het wel aan de gang krijgt onder 24.x en dan een migratie doet naar 25 zou OpnSense zelf alles op de juiste plek moeten neerzetten?

[barrymossel]

Riddertommie schreef op woensdag 12 februari 2025 @ 18:29:
[...]


Ik doe niet hele gekke dingen geloof ik. Ik wil mijn bestaande modem (box 10) vervangen door opnsense welke ik draai op Proxmox die weer draait op een Lenovo m700 mini pc met twee netwerkkaarten.

Ik heb het zover voor elkaar dat ik via het opstarten (cmd) keurig 3 ip adressen krijg en ook de juiste. alleen werkt het niet.

mijn pc zelf krijgt ook keurig een IP via dhcp met juiste waarden. Ik zie het gewoon niet. Ik ben nu terug op de KPN router en omdat anders de rest van het huis (lees de kinderen) geen internet meer hebben. zodra ik weer tijd heb zal ik screenshots maken.

Iedere hulp/tips welkom

Bedankt!

Gekke dingen zul je vast niet doen, maar een klein vergissinkje zit in een klein hoekje. Hier draai ik ook Proxmox met o.a. OPNSense. En mij is het met de nieuwste versies ook gelukt. Dus er moet iets fout staan in een instelling, lijkt me. En 2 (of meer) zien meer dan 1...

Ik wil graag met je meekijken, dus ik wacht op je screenshots.

[Riddertommie]

Kleine update, ik heb nieuwe hardware besteld bij ome Ali. Ik maakte gebruik van een nic2usb en deze viel af en toe uit met, wat ik denk, alle gevolgen van dien. Ik heb nu een m.2. to ethernet gekocht.

Houd jullie op de hoogte.

[Ravian18]

Ik ben zelf ook een beetje aan het struggelen om internet van KPN over PPPoE in te stellen op OPNsense. Iemand een idee? Mijn instellingen zijn als volgt:

[Tom Paris]

Ravian18 schreef op maandag 24 februari 2025 @ 15:45:
Ik ben zelf ook een beetje aan het struggelen om internet van KPN over PPPoE in te stellen op OPNsense. Iemand een idee? Mijn instellingen zijn als volgt:
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

PPPoE moet op VLAN 6.

[Ravian18]

Tom Paris schreef op maandag 24 februari 2025 @ 16:35:
[...]


PPPoE moet op VLAN 6.

De VLAN tag staat op 6. Dat klopt toch?

[Tom Paris]

Ravian18 schreef op maandag 24 februari 2025 @ 16:52:
[...]

De VLAN tag staat op 6. Dat klopt toch?

Volgensmij gaat het fout omdat je een device hebt 'vlan01' met tag '6'. Ik weet niet hoe OPNsense daar exact mee om gaat, maar in deze guide gebruiken ze ook gewoon 'vlan06'.

[synoniem]

Ravian18 schreef op maandag 24 februari 2025 @ 15:45:
Ik ben zelf ook een beetje aan het struggelen om internet van KPN over PPPoE in te stellen op OPNsense. Iemand een idee? Mijn instellingen zijn als volgt:
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Als ik de schermplaatjes bekijk staat je vlan 6 op je LAN port (igc0) en niet op je WAN port(icg1) tenzij je die twee geswitched hebt ergens.

[Ravian18]

synoniem schreef op maandag 24 februari 2025 @ 18:29:
[...]

Als ik de schermplaatjes bekijk staat je vlan 6 op je LAN port (igc0) en niet op je WAN port(icg1) tenzij je die twee geswitched hebt ergens.

Dit klopte inderdaad niet. Ik realiseerde mij daarnaast ook niet dat de WAN aangesloten moest worden op de ETH1 poort en LAN op ETH0. Het is dus opgelost, dank voor het meedenken

[Riddertommie]

Hallo hallo, Kleine update. Ik heb de nieuwe hardware gekregen en geïnstalleerd en ik heb het zover dat het internet het nu doet.

Zo meteen verder met de TV instellingen.

Bedankt iedereen!

[Riddertommie]

Hallo, ik heb zowel internet als TV aan de praat, maar ik heb toch het gevoel dat TV niet werkt zoals het moet.

De beide turner (KPN) werken allen in unicast, geen multicast (wat ik zou verwachten). Als ik kijk naar mijn switch zie ik ook niet dat deze informatie geeft bij IPMG snooping terwijl met het "oude" KPN modem dit wel zo was.

Ik maak gebruik van de IGMP proxy plugin, of had ik dit juist niet moeten doen omdat dit al op de switch zit?

Of maak ik een denkfout hier?

[Muis666]

Riddertommie schreef op dinsdag 4 maart 2025 @ 11:39:
Hallo, ik heb zowel internet als TV aan de praat, maar ik heb toch het gevoel dat TV niet werkt zoals het moet.

De beide turner (KPN) werken allen in unicast, geen multicast (wat ik zou verwachten). Als ik kijk naar mijn switch zie ik ook niet dat deze informatie geeft bij IPMG snooping terwijl met het "oude" KPN modem dit wel zo was.

Ik maak gebruik van de IGMP proxy plugin, of had ik dit juist niet moeten doen omdat dit al op de switch zit?

Of maak ik een denkfout hier?

IGMP Proxy ontvangt multicast verkeer en stuurt het door naar apparaten die om de stream vragen. Deze moet op je router draaien.
IGMP Snooping is kijken van switches naar het IGMP verkeer zodat ze kunnen bepalen naar welke poorten het verkeer moet worden gestuurd.

Normaal gesproken kun je logging aanzetten van je IGMP Proxy zodat je kunt zien wat er misgaat.

[Riddertommie]

Muis666 schreef op dinsdag 4 maart 2025 @ 13:29:
[...]

IGMP Proxy ontvangt multicast verkeer en stuurt het door naar apparaten die om de stream vragen. Deze moet op je router draaien.
IGMP Snooping is kijken van switches naar het IGMP verkeer zodat ze kunnen bepalen naar welke poorten het verkeer moet worden gestuurd.

Normaal gesproken kun je logging aanzetten van je IGMP Proxy zodat je kunt zien wat er misgaat.

Het is allemaal net weer iets anders, Ik draai opnsense op proxmox (had ik misschien moeten zeggen......) en daar heb ik voor ieder nic een bridge aangemaakt. Of het nu een bug is of niet, er wordt voor iedere bridge dan ook standaard IGMP aangezet wat je niet uit kunt zetten via de webgui. Wat je dan krijgt (als ik het goed heb) dat de IGMP proxy in opensense zich conformeert aan het eerste lan/bridge die die tegen komt en dus niet doorkomt naar de switch zelf) Dit kun je wel handmatig uitzetten en dan zie ik in de switch ook wel de broadcast netwerken opkomen, maar dat voor heel even. Er zijn wat tips te vinden op het internet maar ik heb de juiste nog niet.

Iemand anders die deze configuratie werkend heeft: dus OPNsense 25.1 op proxmox met IGMP (kpn)?

Hoor graag.

[Theone098]

Opgelost. Verkeerde instelling op een tussenliggende switch. Daar stond een igmp-proxy aan.

[ Voor 114% gewijzigd door Theone098 op 14-03-2025 07:35 . Reden: Opgelost. ]

[bdcp]

Riddertommie schreef op donderdag 6 maart 2025 @ 14:08:
[...]


Het is allemaal net weer iets anders, Ik draai opnsense op proxmox (had ik misschien moeten zeggen......) en daar heb ik voor ieder nic een bridge aangemaakt. Of het nu een bug is of niet, er wordt voor iedere bridge dan ook standaard IGMP aangezet wat je niet uit kunt zetten via de webgui. Wat je dan krijgt (als ik het goed heb) dat de IGMP proxy in opensense zich conformeert aan het eerste lan/bridge die die tegen komt en dus niet doorkomt naar de switch zelf) Dit kun je wel handmatig uitzetten en dan zie ik in de switch ook wel de broadcast netwerken opkomen, maar dat voor heel even. Er zijn wat tips te vinden op het internet maar ik heb de juiste nog niet.

Iemand anders die deze configuratie werkend heeft: dus OPNsense 25.1 op proxmox met IGMP (kpn)?

Hoor graag.

Heb je hier nog iets voor gevonden? Heb namelijk hetzelfde setup

[Riddertommie]

bdcp schreef op donderdag 20 maart 2025 @ 23:02:
[...]


Heb je hier nog iets voor gevonden? Heb namelijk hetzelfde setup

Hier een draadje wat ik heb gevolgd.

[OPNsense+KPN+IPTV] Wel unicast, geen multicast werkend.

Daar staan ok de commandos om broadcast in virtuele bridge uit te krijgen.

Zoals aangegeven zie ik dan de Broadcast netwerken opkomen, maar dan werkt het voor mij nog niet helemaal. Waarbij ik twijfel aan de switch.

Ik hoor graag hoe het bij jou loopt......

[bdcp]

Riddertommie schreef op vrijdag 21 maart 2025 @ 15:13:
[...]


Ik hoor graag hoe het bij jou loopt......

Ook voor mij werkt het uitschakelen van IGMP Snooping ook niet, ik ontvang nog steeds geen TV. In eerste instantie heb ik PfSense geprobeerd, maar zonder succes voor de TV. Er bevinden zich twee fysieke switches tussen mijn router en de TV, echter functioneren deze switches prima met de KPN Router, dus het lijkt erop dat het probleem niet aan de switches ligt.

Ook met opnsense loop ik tegen dezelfde problemen aan: alles lijkt correct ingesteld, maar ik ontvang alleen internet, geen televisie. Ik vermoed dat het mogelijk iets te maken heeft met proxmox.

Mijn huidige opzet is uit een Beelink met 2x NIC. Een NIC gebruik ik voor de WAN passthrough naar opnsense (ik heb ook een bridge geprobeerd), en de andere NIC gebruik ik voor de LAN bridge.


Verder dan dit vind ik het lastig te debuggen. Om met IGMP Proxy in debug mode te werken moet ik er eens goed voor gaan zitten.

[Arnout]

Afgelopen paar dagen werd het internet thuis slechter, apps bleven hangen, X laadde plaatjes niet. Ik had niks veranderd aan mijn OPNsense setup.

Gisteravond dacht ik, laat ik OPNsense updaten. Dit lukte ook niet . Bleef hangen op het downloaden van packages...

Kwam ik via Reddit uit op het uitschakelen van IPv6.

Nu zag ik in het KPN Glasvezel topic dat er ook met de KPN Box IPv6 problemen zijn, zou het daarmee te maken hebben?

[Vorkie]

Arnout schreef op zaterdag 22 maart 2025 @ 16:02:
Afgelopen paar dagen werd het internet thuis slechter, apps bleven hangen, X laadde plaatjes niet. Ik had niks veranderd aan mijn OPNsense setup.

Gisteravond dacht ik, laat ik OPNsense updaten. Dit lukte ook niet . Bleef hangen op het downloaden van packages...

Kwam ik via Reddit uit op het uitschakelen van IPv6.

Nu zag ik in het KPN Glasvezel topic dat er ook met de KPN Box IPv6 problemen zijn, zou het daarmee te maken hebben?

Had je wel herstart?

Het zou niets met elkaar te maken moeten hebben, OPNSense vraagt gewoon via PPPoE IPv6 range op en jij doet middels RA weer het in je eigen netwerk doorzetten, dat is wat er zo te zien stuk gaat in die Experiabox.

Hoe heb je IPv6 geconfigureerd?

Hier met PFSense in ieder geval 0 problemen.

[Arnout]

Vorkie schreef op zaterdag 22 maart 2025 @ 16:42:
[...]


Had je wel herstart?

Het zou niets met elkaar te maken moeten hebben, OPNSense vraagt gewoon via PPPoE IPv6 range op en jij doet middels RA weer het in je eigen netwerk doorzetten, dat is wat er zo te zien stuk gaat in die Experiabox.

Hoe heb je IPv6 geconfigureerd?

Hier met PFSense in ieder geval 0 problemen.

Heb 2x herstart en telkens bleef hij hangen. Ook via de console / terminal update functie.

[Vorkie]

Arnout schreef op zaterdag 22 maart 2025 @ 16:55:
[...]


Heb 2x herstart en telkens bleef hij hangen. Ook via de console / terminal update functie.

Hoe is IPv6 ingesteld? Track interface? of heb je static IP's op de VLAN's gezet?

Ik weet niet precies hoe dat in OPNSense ingesteld wordt, maar zal in de basis niet veel verschillen van PFsense.

Zo staat het bij mij al jaren.

[ Voor 30% gewijzigd door Vorkie op 22-03-2025 17:04 ]

[Arnout]

Vorkie schreef op zaterdag 22 maart 2025 @ 17:03:
[...]

Hoe is IPv6 ingesteld? Track interface? of heb je static IP's op de VLAN's gezet?

Ik weet niet precies hoe dat in OPNSense ingesteld wordt, maar zal in de basis niet veel verschillen van PFsense.

Zo staat het bij mij al jaren.

[Afbeelding]

Ja zo had ik het ook, adhv deze guide https://www.eigenrouter.n...kpn/opnsense-without-vlan

Dus IPv6 Configuration Type op DHCPv6, staat nu op None.

[ Voor 3% gewijzigd door Arnout op 22-03-2025 23:04 ]

[Vorkie]

Arnout schreef op zaterdag 22 maart 2025 @ 23:03:
[...]

Ja zo had ik het ook, adhv deze guide https://www.eigenrouter.n...kpn/opnsense-without-vlan

Dus IPv6 Configuration Type op DHCPv6, staat nu op None.

[Afbeelding]

OK, en hoe staat je LAN interface? Ik zie ook DHCPV6? Niet ingesteld toch? Dat moet allemaal met RA, IPv6 liever niet op DHCP.

Wel zonde dat ze daar de MTU niet op 1500 laten zetten ook.

[stormfly]

Vorkie schreef op zondag 23 maart 2025 @ 08:41:
[...]
Wel zonde dat ze daar de MTU niet op 1500 laten zetten ook.

Met MTU 1492 👍 Also je spreekt over MTU 1500 heb je het over 0,53% snelheidsverbetering. Ik ben actief aan het reageren op het 1500 MTU verhaal wat hier op Tweakers ontstaan is. Omdat ik van mening ben dat de niet diep technische Tweakers nu een verkeerd beeld krijgen over wat de winst nu daadwerkelijk is.

Overigens is met OPNsense op PPPoE wel 1500 te behalen als je de bovenliggende interfaces goed zet.

[Vorkie]

stormfly schreef op zondag 23 maart 2025 @ 08:57:
[...]


[Afbeelding]

Met MTU 1492 👍 Also je spreekt over MTU 1500 heb je het over 0,53% snelheidsverbetering. Ik ben actief aan het reageren op het 1500 MTU verhaal wat hier op Tweakers ontstaan is. Omdat ik van mening ben dat de niet diep technische Tweakers nu een verkeerd beeld krijgen over wat de winst nu daadwerkelijk is.

Overigens is met OPNsense op PPPoE wel 1500 te behalen als je de bovenliggende interfaces goed zet.

MTU heeft niet alleen maar met snelheid te maken en is niet alleen maar wat “hier op Tweakers is ontstaan”.

[ Voor 3% gewijzigd door Vorkie op 23-03-2025 09:44 ]

[stormfly]

Vorkie schreef op zondag 23 maart 2025 @ 09:43:
[...]


MTU heeft niet alleen maar met snelheid te maken en is niet alleen maar wat “hier op Tweakers is ontstaan”.

Ik ben benieuwd naar meer onderbouwing dan kan ik wat leren 👍 met 0,53% verschil lijkt mij dat je het niet waar kunt nemen in dagelijks gebruik? Uiteindelijk ligt MSS er voor TCP ook overheen.

Laat ik voorop stellen dat ik OPNsense ook op 1500 PPP had staan. Soms ik zie mensen hier worstelen met instellingen en verdwalen en vraag ik mij af: waarom Omdat je met een te grote MTU juist gaat fragmenten of raar gedrag van websites kan krijgen die niet lekker inladen.

Bron internet
MTU is de maximale grootte van een pakket dat kan worden verzonden over een netwerkverbinding. Dit omvat alle headers en gegevens.

MSS daarentegen is de maximale hoeveelheid gegevens (payload) die in een TCP-segment kan worden verzonden, exclusief de TCP/IP-headers.

[ Voor 55% gewijzigd door stormfly op 23-03-2025 10:00 ]

[Vorkie]

stormfly schreef op zondag 23 maart 2025 @ 09:45:
[...]


Ik ben benieuwd naar meer onderbouwing dan kan ik wat leren 👍

Fragmentatie van pakketten is iets wat je altijd moet voorkomen, op lange afstandsverbindingen, dus internet, maar ook op MPLS / incountry Wan.

Je voorkomt daarmee ook vaak onverklaarbare hiccups, niet alleen je eigen router moet constant pakketten fragmenteren, ook die routers aan de andere zijde. Het is dat TCP netjes een retransmission doen bij missende ACKs, maar ook hier is het zonde van de energie die het kost voor al die routers. Je hoeft het niet allemaal te zien of te merken op je internet lijntje thuis, maar voorkomen is beter dan genezen. Ook zakelijk gezien zie ik vaak een kopie van de slechte optimalisaties die de systeem/netwerkbeheerder thuis heeft uitgeplozen. Er zijn niet voor niets certificaten zoals CCNA en daarbij ervaringen die je op doet als professioneel netwerkbeheerder bij de grote organisaties.

MTU is wat mij betreft naar het internet toe 1500, gezien het wordt ondersteund door KPN, zet je interface fysieke op 1522 en zet je OPnsense / PFsense op 1500. Is nog net wat groener ook mocht het je interesseren.

Doe er verder mee wat je wilt, gezien je reacties wil je graag 1492 behouden, dat is dan je eigen keus.

[stormfly]

Vorkie schreef op zondag 23 maart 2025 @ 10:10:
[...]

Fragmentatie van pakketten is iets wat je altijd moet voorkomen, op lange afstandsverbindingen, dus internet, maar ook op MPLS / incountry Wan.

Zeker, hoe lager de MTU des te lager kans is op fragmentatie. Het fragmenteren van pakketten: MTU >1500 over een pad van 1500 versturen kost meer CPU time dan een extra datapakket voor een MTU van bijvoorbeeld 1400. Fragmentatie is niet alleen een kwestie van CPU-tijd, maar verhoogt ook significant de kans op packet loss. Als er meerdere fragmenten zijn en er raakt er maar één kwijt, moet het hele pakket opnieuw worden verzonden. Dit zorgt voor extra vertraging en inefficiëntie. Bij een goed gekozen lagere MTU vermijd je dit probleem volledig en krijg je een veel consistentere performance, zeker op drukkere verbindingen.

Fragmentatie ontstaat bij een te grote MTU.

Als een pakket groter is dan de MTU van een tussenliggende router, moet dat pakket worden opgesplitst (gefragmenteerd) in kleinere delen om door te kunnen. Dit gebeurt bijvoorbeeld als:
• De afzender een MTU van 1500 bytes gebruikt, maar een router onderweg slechts 1492 bytes toestaat (zoals bij PPPoE).
• Een VPN extra headers toevoegt, waardoor het totale pakket groter wordt dan de ingestelde MTU.

Kleine MTU = minder kans op fragmentatie, omdat pakketten sowieso klein genoeg zijn om overal zonder opsplitsen door te komen

MSS berekening bij een MTU van 1500 bytes - de header = netto.

Voor IPv4: MSS = 1500 - 40 = 1460 bytes
Voor IPv6: MSS = 1500 - 60 = 1440 bytes

Je voorkomt daarmee ook vaak onverklaarbare hiccups, niet alleen je eigen router moet constant pakketten fragmenteren, ook die routers aan de andere zijde. Het is dat TCP netjes een retransmission doen bij missende ACKs, maar ook hier is het zonde van de energie die het kost voor al die routers. Je hoeft het niet allemaal te zien of te merken op je internet lijntje thuis, maar voorkomen is beter dan genezen.

Ja exact een te grote MTU moeten alle routers in het pad het pakket opknippen, daarom is mijn punt ook: waarom die laatste paar byte eruit halen (vergroten MTU) terwijl het risico op uitdagingen groter wordt. 1 byte te hoog ingesteld is een recept voor gedoe

Ook zakelijk gezien zie ik vaak een kopie van de slechte optimalisaties die de systeem/netwerkbeheerder thuis heeft uitgeplozen. Er zijn niet voor niets certificaten zoals CCNA en daarbij ervaringen die je op doet als professioneel netwerkbeheerder bij de grote organisaties.

Dat is een goed idee, blijf van je MTU af tenzij je CCNA hebt behaald Dat is exact waarover ik dit gesprek begon kennis over de materie vermogen tot issues oplossen tov de beperkte winst. Overigens helemaal niet persoonlijk naar jou, vat het aub niet zo op. Vorige week kwam het ook voorbij in het UniFi topic. Dit is denk ik ook een Tweaker, goede kwalitatieve post met mooie plaatjes.

MTU is wat mij betreft naar het internet toe 1500, gezien het wordt ondersteund door KPN, zet je interface fysieke op 1522 en zet je OPnsense / PFsense op 1500. Is nog net wat groener ook mocht het je interesseren.

We weten dat KPN PPPoE MTU 1500 ondersteund, doen Delta en Glasnet dat ook? (ik weet het niet).

Die "groener" opmerking snap ik niet helemaal. In theorie heb je bij grotere pakketten minder overhead per byte (minder headers), maar deze marginale winst wordt volledig teniet gedaan door de extra verwerkingstijd bij fragmentatie en mogelijke retransmissies als fragmenten verloren gaan. Een gefragmenteerd pakket dat opnieuw moet worden verzonden is juist minder "groen" dan twee kleinere pakketten die direct goed aankomen

Doe er verder mee wat je wilt, gezien je reacties wil je graag 1492 behouden, dat is dan je eigen keus.

Het gaat mij erom dat 1492 out of the box heel goed werkt en dat beeld wil ik voor minder ingelezen Tweakers delen. Ik zie de laatste tijd veel nieuwe usersnames in de netwerk topics en wilde eens een ander licht schijnen op de MTU casus.

Tweakers kunnen zelf kiezen wat ze willen gebruiken, en besluiten hoe goed ze netwerken doorgronden om deze 0.5% winst te pakken. Zoals je zelf laat doorschemeren, iedereen is er helemaal vrij in

[mrdemc]

stormfly schreef op zondag 23 maart 2025 @ 12:43:
[...]


Zeker, hoe lager de MTU des te lager kans is op fragmentatie. Het fragmenteren van pakketten: MTU >1500 over een pad van 1500 versturen kost meer CPU time dan een extra datapakket voor een MTU van bijvoorbeeld 1400. Fragmentatie is niet alleen een kwestie van CPU-tijd, maar verhoogt ook significant de kans op packet loss. Als er meerdere fragmenten zijn en er raakt er maar één kwijt, moet het hele pakket opnieuw worden verzonden. Dit zorgt voor extra vertraging en inefficiëntie. Bij een goed gekozen lagere MTU vermijd je dit probleem volledig en krijg je een veel consistentere performance, zeker op drukkere verbindingen.

Fragmentatie ontstaat bij een te grote MTU.

Als een pakket groter is dan de MTU van een tussenliggende router, moet dat pakket worden opgesplitst (gefragmenteerd) in kleinere delen om door te kunnen. Dit gebeurt bijvoorbeeld als:
• De afzender een MTU van 1500 bytes gebruikt, maar een router onderweg slechts 1492 bytes toestaat (zoals bij PPPoE).
• Een VPN extra headers toevoegt, waardoor het totale pakket groter wordt dan de ingestelde MTU.

Kleine MTU = minder kans op fragmentatie, omdat pakketten sowieso klein genoeg zijn om overal zonder opsplitsen door te komen

MSS berekening bij een MTU van 1500 bytes - de header = netto.

Voor IPv4: MSS = 1500 - 40 = 1460 bytes
Voor IPv6: MSS = 1500 - 60 = 1440 bytes




[...]


Ja exact een te grote MTU moeten alle routers in het pad het pakket opknippen, daarom is mijn punt ook: waarom die laatste paar byte eruit halen (vergroten MTU) terwijl het risico op uitdagingen groter wordt. 1 byte te hoog ingesteld is een recept voor gedoe


[...]


Dat is een goed idee, blijf van je MTU af tenzij je CCNA hebt behaald Dat is exact waarover ik dit gesprek begon kennis over de materie vermogen tot issues oplossen tov de beperkte winst. Overigens helemaal niet persoonlijk naar jou, vat het aub niet zo op. Vorige week kwam het ook voorbij in het UniFi topic. Dit is denk ik ook een Tweaker, goede kwalitatieve post met mooie plaatjes.


[...]


We weten dat KPN PPPoE MTU 1500 ondersteund, doen Delta en Glasnet dat ook? (ik weet het niet).

Die "groener" opmerking snap ik niet helemaal. In theorie heb je bij grotere pakketten minder overhead per byte (minder headers), maar deze marginale winst wordt volledig teniet gedaan door de extra verwerkingstijd bij fragmentatie en mogelijke retransmissies als fragmenten verloren gaan. Een gefragmenteerd pakket dat opnieuw moet worden verzonden is juist minder "groen" dan twee kleinere pakketten die direct goed aankomen


[...]


Het gaat mij erom dat 1492 out of the box heel goed werkt en dat beeld wil ik voor minder ingelezen Tweakers delen. Ik zie de laatste tijd veel nieuwe usersnames in de netwerk topics en wilde eens een ander licht schijnen op de MTU casus.

Tweakers kunnen zelf kiezen wat ze willen gebruiken, en besluiten hoe goed ze netwerken doorgronden om deze 0.5% winst te pakken. Zoals je zelf laat doorschemeren, iedereen is er helemaal vrij in

Maar is 1492 dan niet te klein voor het pakket verzonden vanuit de bron die gewoon 1500 verwacht (zoals de pc of webserver) waarna die op jouw router gefragmenteerd moet worden?
Zoveel moeite is het ook niet om het goed in te stellen. Het voelt voor mij een beetje als autorijden op zachte banden in ieder geval.

[stormfly]

mrdemc schreef op zondag 23 maart 2025 @ 15:16:
[...]


Maar is 1492 dan niet te klein voor het pakket verzonden vanuit de bron die gewoon 1500 verwacht (zoals de pc of webserver) waarna die op jouw router gefragmenteerd moet worden?
Zoveel moeite is het ook niet om het goed in te stellen. Het voelt voor mij een beetje als autorijden op zachte banden in ieder geval.

MSS in TCP/IP lost dat op, MSS bepaald op basis van de onderhandeling tussen verzender & ontvanger wat er maximaal aan pakketgrootte gebruikt kan worden binnen de geldende MTU mogelijkheden. MSS onderhandelt dat bij het opzetten van de TCP sessie op getal wat matched met de PPPoE MTU mogelijkheden. Bij een PPPoE verbinding leggen de pakketten sowieso een andere weg af, de router moet elk pakket encapsuleren in PPP wat op zich al CPU intensief is.

Bij UDP pakketten mis je de intelligentie van TCP/IP en kom je wel uit op echte fragmentatie als je 1500 in 1492 probeert te stoppen. Als dan het bit DF=0 is ingesteld fragmenteert het pakket bij de router, bij DF=1 wordt het pakket gewoon gedropt

[Arnout]

Ik heb de KPN Box 12 aangesloten en deze heeft precies hetzelfde probleem. Gelukkig, het ligt niet aan mijn OPNsense setup

Ik krijg deze ifconfig op een ubuntu laptop als ik de Box 12 als router/AP gebruik:

code:

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::f1e8:3eab:54c2:d848  prefixlen 64  scopeid 0x20<link>
        inet6 2a02:a452:xxxx:1:d23f:aa8a:d344:bda9  prefixlen 64  scopeid 0x0<global>
        inet6 2a02:a452:xxxx:1:2450:8180:38f2:57a5  prefixlen 64  scopeid 0x0<global>
        ether 5c:93:a2:ad:f6:fe  txqueuelen 1000  (Ethernet)
        RX packets 1603  bytes 304903 (304.9 KB)
        RX errors 0  dropped 240  overruns 0  frame 0
        TX packets 833  bytes 115939 (115.9 KB)
        TX errors 0  dropped 12 overruns 0  carrier 0  collisions 0

Nu lees ik dit op de KPN community:

Elk eindapparaat krijgt een IPv6 modemadres en via dat adres gaat hij het internet op. Maar wat er kan gebeuren is dat de Box 12 twee van die IPv6 adressen uitdeelt. Eentje ervan is dan niet valide, en werkt niet. Als een eindapparaat dan via dat niet-valide IPv6 adres een internetpagina of app probeert te openen, dan werkt dat niet. Sommige eindapparaten zijn slim genoeg dat ze merken dat het IPv6 adres niet klopt en switchen naar de andere. Dan is de verbinding gewoon traag. Maar als je eindapparaat niet kan switchen, dan kun je de site niet bereiken of heeft de app geen verbinding. De oplossing, voor nu, is om dan IPv6 uit te zetten in je modem.

Dit lijkt op mijn probleem, maar wat gaan ze fixen in de Box 12 dan? Dit lijkt me meer een netwerk issue?

[EricNL]

Ik ben me aan het voorbereiden om mijn eerste OPNsense installatie ooit uit te gaan proberen, maar ik twijfel nog een beetje of ik de volgorde goed heb. Ik heb zelf KPN FTTH, dus met VLAN6 en PPPoE.

1. Ik heb een Vlan6 interface aangemaakt en deze gekoppeld aan mijn fysieke WAN interface.
2. Ik heb vervolgens een PPPoE interface aangemaakt, en deze gekoppeld aan de Vlan6 interface.
3. Onder Interface > Assignments heb ik vervolgens de WAN interface aangepast zodat deze als Device de pppoe0 interface gebruikt.

Klopt dit? Ik ben al behoorlijk wat jaren aan verschillende interfaces gewend, maar van de manier binnen OPNSense krijg ik nog niet echt hoogte...

[ Voor 9% gewijzigd door EricNL op 27-03-2025 17:27 ]

[NIK0]

EricNL schreef op donderdag 27 maart 2025 @ 17:25:
Ik ben me aan het voorbereiden om mijn eerste OPNsense installatie ooit uit te gaan proberen, maar ik twijfel nog een beetje of ik de volgorde goed heb. Ik heb zelf KPN FTTH, dus met VLAN6 en PPPoE.

1. Ik heb een Vlan6 interface aangemaakt en deze gekoppeld aan mijn fysieke WAN interface.
2. Ik heb vervolgens een PPPoE interface aangemaakt, en deze gekoppeld aan de Vlan6 interface.
3. Onder Interface > Assignments heb ik vervolgens de WAN interface aangepast zodat deze als Device de pppoe0 interface gebruikt.

Klopt dit? Ik ben al behoorlijk wat jaren aan verschillende interfaces gewend, maar van de manier binnen OPNSense krijg ik nog niet echt hoogte...

[Afbeelding]

[Afbeelding]

[Afbeelding]

Weet niet of je TV hebt maar heb je deze tutorial gevolgd? Volgens mij brengt die je al een heel eind:
https://www.eigenrouter.n...se/kpn/opnsense-with-vlan

[Remie]

Is er recent (+- 2 weken) geleden iets veranderd aan KPN iptv?
Mijn vrouw gaf gisteren aan dat ze al een tijdje geen live tv meer kan kijken.

De stream start en 5 seconden later hangt hij.
Ik heb nu jaren een werkende setup en geen wijziging recent gedaan.

code:

Mar 30 07:16:21 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:16:18 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:16:18 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:57 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:57 igmpproxy   50914   RECV Membership query from 10.60.125.152 to 224.0.0.1
Mar 30 07:15:54 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:54 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:33 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:30 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:30 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:09 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:06 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:06 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:14:51 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:14:50 igmpproxy   50586   Joining group 224.0.0.22 on interface ix0.10
Mar 30 07:14:50 igmpproxy   50586   Joining group 224.0.0.2 on interface ix0.10
Mar 30 07:14:50 igmpproxy   50586   adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0
Mar 30 07:14:50 igmpproxy   50586   adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0
Mar 30 07:14:39 igmpproxy   98491   Shutdown complete....
Mar 30 07:14:39 igmpproxy   98491   All routes removed. Routing table is empty.
Mar 30 07:14:39 igmpproxy   98491   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:14:39 igmpproxy   98491   Got a interrupt signal. Exiting.
Mar 30 07:14:39 igmpproxy   98491   select() failure; Errno(4): Interrupted system call
Mar 30 07:14:33 igmpproxy   98491   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:14:30 igmpproxy   97826   Joining group 224.0.0.22 on interface ix0.10
Mar 30 07:14:30 igmpproxy   97826   Joining group 224.0.0.2 on interface ix0.10
Mar 30 07:14:30 igmpproxy   97826   adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0
Mar 30 07:14:30 igmpproxy   97826   adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0
Mar 30 07:14:30 igmpproxy   67323   Shutdown complete....
Mar 30 07:14:30 igmpproxy   67323   All routes removed. Routing table is empty.
Mar 30 07:14:30 igmpproxy   67323   Got a interrupt signal. Exiting.
Mar 30 07:14:30 igmpproxy   67323   select() failure; Errno(4): Interrupted system call
Mar 30 07:14:27 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:21 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:15 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:09 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:03 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:13:57 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:13:52 igmpproxy   67323   RECV Membership query from 10.60.125.152 to 224.0.0.1
Mar 30 07:13:51 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.

~edit:

Het is inmiddels opgelost. Vorige week een nieuwe regel gemaakt op IPv4+IPv6 met allow any protocol from VLAN010 source to any destination (Om iets te troubleshooten en vergeten de regel uit te zetten). Ondanks dat dit een "allow" regel is blokkeerde deze regel IGMP verkeer. Is dit expected behaviour of heb ik een bug gevonden?

[ Voor 13% gewijzigd door Remie op 30-03-2025 08:34 ]

[synoniem]

Remie schreef op zondag 30 maart 2025 @ 07:28:
Is er recent (+- 2 weken) geleden iets veranderd aan KPN iptv?
Mijn vrouw gaf gisteren aan dat ze al een tijdje geen live tv meer kan kijken.

De stream start en 5 seconden later hangt hij.
Ik heb nu jaren een werkende setup en geen wijziging recent gedaan.

code:

Mar 30 07:16:21 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:16:18 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:16:18 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:57 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:57 igmpproxy   50914   RECV Membership query from 10.60.125.152 to 224.0.0.1
Mar 30 07:15:54 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:54 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:33 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:30 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:30 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:15:09 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:15:06 igmpproxy   50914   MRT_DEL_MFC; Errno(49): Can't assign requested address
Mar 30 07:15:06 igmpproxy   50914   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:14:51 igmpproxy   50914   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:14:50 igmpproxy   50586   Joining group 224.0.0.22 on interface ix0.10
Mar 30 07:14:50 igmpproxy   50586   Joining group 224.0.0.2 on interface ix0.10
Mar 30 07:14:50 igmpproxy   50586   adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0
Mar 30 07:14:50 igmpproxy   50586   adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0
Mar 30 07:14:39 igmpproxy   98491   Shutdown complete....
Mar 30 07:14:39 igmpproxy   98491   All routes removed. Routing table is empty.
Mar 30 07:14:39 igmpproxy   98491   Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0
Mar 30 07:14:39 igmpproxy   98491   Got a interrupt signal. Exiting.
Mar 30 07:14:39 igmpproxy   98491   select() failure; Errno(4): Interrupted system call
Mar 30 07:14:33 igmpproxy   98491   Inserted route table entry for 239.255.255.250 on VIF #-1
Mar 30 07:14:30 igmpproxy   97826   Joining group 224.0.0.22 on interface ix0.10
Mar 30 07:14:30 igmpproxy   97826   Joining group 224.0.0.2 on interface ix0.10
Mar 30 07:14:30 igmpproxy   97826   adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0
Mar 30 07:14:30 igmpproxy   97826   adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0
Mar 30 07:14:30 igmpproxy   67323   Shutdown complete....
Mar 30 07:14:30 igmpproxy   67323   All routes removed. Routing table is empty.
Mar 30 07:14:30 igmpproxy   67323   Got a interrupt signal. Exiting.
Mar 30 07:14:30 igmpproxy   67323   select() failure; Errno(4): Interrupted system call
Mar 30 07:14:27 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:21 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:15 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:09 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:14:03 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:13:57 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.
Mar 30 07:13:52 igmpproxy   67323   RECV Membership query from 10.60.125.152 to 224.0.0.1
Mar 30 07:13:51 igmpproxy   67323   The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring.

~edit:

Het is inmiddels opgelost. Vorige week een nieuwe regel gemaakt op IPv4+IPv6 met allow any protocol from VLAN010 source to any destination (Om iets te troubleshooten en vergeten de regel uit te zetten). Ondanks dat dit een "allow" regel is blokkeerde deze regel IGMP verkeer. Is dit expected behaviour of heb ik een bug gevonden?

[Afbeelding]

[Afbeelding]

[Afbeelding]

Dat is expected behavior want om multicast verkeer te laten passeren moet je onder advanced "Allow IP options" aan vinken.

[Remie]

synoniem schreef op zondag 30 maart 2025 @ 12:26:
[...]

Dat is expected behavior want om multicast verkeer te laten passeren moet je onder advanced "Allow IP options" aan vinken.

Tuurlijk :-D.

De regel staat weer uit dus ik heb weer goede ruling :-)

Dankjewel voor het meedenken

[Riddertommie]

Remie schreef op zondag 30 maart 2025 @ 07:28[/message]:[/b]
Is er recent (+- 2 weken) geleden iets veranderd aan KPN iptv?
Mijn vrouw gaf gisteren aan dat ze al een tijdje geen live tv meer kan kijken.

De stream start en 5 seconden later hangt hij.
Ik heb nu jaren een werkende setup en geen wijziging recent gedaan.

Hoi, Remie, je geeft aan al jaren werkend. in welke configuratie is dat? OPNsens met proxmox? multicast?

Heel nieuwsgierig hier.

[Remie]

Riddertommie schreef op maandag 31 maart 2025 @ 11:38:
[...]


Hoi, Remie, je geeft aan al jaren werkend. in welke configuratie is dat? OPNsens met proxmox? multicast?

Heel nieuwsgierig hier.

Pfsense op een Dell Precision van een aantal jaren oud.
Ik gebruik de IGMP proxy om multicast TV te kunnen kijken.

[Conjurer]

Goed nieuws: pfSense 2.8 komt eraan (zou het dan toch echt?): https://www.netgate.com/b...on-2.8-beta-now-available. Ik zie ook dat de roadmap opeens een merkwaardige sprong maakt in de voortgang: van lange tijd op 91% naar opeens 95%: https://redmine.pfsense.org/projects/pfsense/roadmap

Dan is hopelijk de problematiek met het zappen eindelijk voorbij. In dit forum door Remie gemeld en in de pfSense bugtracker geregistreerd: https://redmine.pfsense.org/issues/15043

[Kees]

Ik heb een vreemd probleem met opnsense en KPN en ik hoop dat iemand gelijke ervaringen heeft en mischien zelfs een oplossing weet

Mijn setup werkt; ik heb internet, ik kan tv kijken, ik kan dingen downloaden en uploaden.

Maar ik haal op sommige hosts hele lage snelheden. Een download van ftp.bit.nl bijvoorbeeld komt binnen met maximaal 40-100Mbit/s. Maar dezelfde download op een externe server (*kuch* de server die dit forum host *kuch*) komt gewoon met 3+Gbits binnen, dus aan bit ligt het niet.

Vervolgens viel het mij op dat als ik diezelfde file van verschillende tweakers servers probeerde af te halen, dat het dan soms traag was, en soms snel. De file direct van een loadbalancer afhalen was bijvoorbeeld snel, maar vanaf een webserver was het traag.

Als ik dan verder kijk, dan zie ik iets opvallend. Een download van een server is heel erg langzaam afhankelijk van het gebruikte congestion protocol.. Als op die server het tcp_congestion_protocol op bbr staat; dan komt de download binnen met gbit snelheden, maar als het congestion_protocol op cubic staat dan is het bijzonder traag.

Als ik het KPN modem gebruik dan werkt het wel goed..

Heeft iemand dit eerder gezien?

[ Voor 4% gewijzigd door Kees op 03-05-2025 21:14 ]