OPNsense & pfSense KPN/Telfort IPTV how-to

[stormfly]

Zojuist de bugs doorgenomen die nog spelen in de nieuwe PFsense versie 23.01 en het lijkt er op dat de IGMP proxy een flinke bug heeft waardoor tv kijken onmogelijk gemaakt kan worden.

Bron 1: https://forum.netgate.com...gmp-proxy-stops-tv-stream
Bron 2: https://redmine.pfsense.org/issues/13929

• Bij mijn intel NUC6i5 was het niet mogelijk om het multicast verkeer over de ene interface te versturen, zowel met OPNsense als pfSense ging het niet goed. De oplossing was op deze NUC een hypervisor te installeren en daarna losse interfaces toe te kennen: Vlan 34 internet, Vlan 4 IPTV en een LAN interface met de overige vlans. In VMware dan dus 3 losse fysieke interfaces waar van er slechts één een trunk is.
• Het verhaal over dat je verschillende MAC adressen op VLAN 4 en VLAN6 (KPN) moet gebruiken geldt alleen voor Telfort. Bij KPN en XS4ALL maakt dat niet uit en mogen beide hetzelfde MAC hebben omdat het via PPPoE verloopt.
• Vergeet niet om DNS en ICMP (ping naar de gateway) toe te staan op de STB LAN interface en te zorgen dat je DNS forwarder als je die gebruikt ook luistert op de interface. Tevens zorgen dat de DNS resolvers die je meegeeft ook allemaal werken. Als je primaire resolver niet werkt geeft dat zwart beeld op de oudere HD ontvanger (Arris VIP2952v2) ook al werkt de secundaire wel gewoon.
• Als je net als ik werkt met een "router on a stick" bijvoorbeeld een Intel NUC met slechts 1 UTP port. Dan "vliegt" je internet eruit zodra je een IP adres op het IPTV WAN vlan 4 hebt ontvangen. Dit heeft ermee te maken dat KPN unieke mac adressen per vlan wil zien. Dat is met een patch in opnsense op te lossen. https://forum.opnsense.org/index.php?topic=21705.0
• Bij OPNsense heb je een uitgaande rule nodig op het WAN VLAN4 waarin IGMP options aanstaat, anders stopt de stream na 5 minuten.
• Als je vlan 4 koppelt en je internet "vliegt eruit" dan kan er een probleem zijn met het gebruik van de default interface in je router. Deze moet vanzelfsprekend op de vlan 6 (KPN) of 34 interface zijn ingesteld, zie de screenshots hieronder. Soms kiest hij vlan4 als uitgang.

Zelf gebruik ik Telfort:

• Vlan 34 internet
• Vlan 4 IPTV

Bij KPN

• Vlan 6 internet
• Vlan 4 IPTV

Eerst wat achtergrond: een STB dient ge-nat te worden voor internettoegang (netflix) via de WAN VLAN6 interface of VLAN34 (Budget/Telfort). En zodra de STB bij de IPTV backend servers (213.75.112.0/21) wil komen dient hij genat te worden achter de VLAN4 KPN interface. Door het ontvangen van de TV routes via DHCP zal dit automatisch plaatsvinden, er is geen default route bekend op deze interface.

KPN gebruikt drie reeksen waar vanuit multicast verkeer verstuurd kan worden, vroeger was dit er slechts 1 en dat is verwarrend als je een oudere guide gebruikt.
10.0.0.0/8 voor software updates
213.75.0.0/16
217.166.0.0/16

Omdat ik zo min mogelijk onderhoud naar de toekomst wil, heb ik de IGMP proxy voorzien van een default route configuratie. Dat kan helaas niet in OPNsense en pfSense maar met een trucje wel. De default route 0.0.0.0/0 bestaat in feite uit 0.0.0.0/1 & 128.0.0.0/1.

De micro basis stappen staan hier uitgelegd:https://venxir.tweakblogs.net/blog/12507/kpn-glasvezel-via-pfsense ik ga er vanuit dat je weet hoe je een interface aanmaakt in OPNsense etc.


Als e.a werkt qua routering en nat kan je vanaf je testmachine de volgende testen doen:
-Ping 213.75.112.1 dit is het IPTV subnet.
-Ping 1.1.1.1 het normale internet
-Ping Tweakers.net om dns te testen

Update november 2021

Update november 2021
KPN stuurt via VLAN4 geen gateway meer mee, daardoor worden er geen automatische NAT rule aangemaakt en stagneert het TV verkeer. Het toevoegen van een handmatige NAT rule lost deze error 561 op.




Als het dan nog niet werkt dan kunnen het alleen nog firewall rules zijn of multicast fw rules.

WAN configuratie

Plaats op de VLAN4 WAN interface een DHCP configuratie met de volgende parameters. Je krijgt hier een DHCP adres van KPN.

Ter controle kan je valideren of de interface werkt via het interface overview menu.


Als de configuratie juist is krijg je de classless routes binnen, te controleren via System -> routes -> status

LAN configuratie

Maak een LAN interface aan voor je IPTV clients. In mijn netwerk gebruik ik hiervoor een apart vlan zodat dit VLAN geen ander verkeer hoeft te vervoeren. Wel zo overzichtelijk met troubleshooten of het maken van schone packetcaptures.
Op deze LAN interface hoef je vandaag (juli 2020) geen specifieke parameters meer uit te delen aan je STB IPTV kastjes, verstandig is wel om de KPN dns servers mee te geven op het STB vlan. Dit voorkomt in de toekomst ook weer onderhoud, of problemen.

NAT configuratie

De routering (routes verkregen door de classless-route optie via dhcp) bepaalt dat alleen het IPTV verkeer via VLAN4 gaat lopen. Al het andere IP-verkeer gaat via VLAN6. Een full nat (zonder destination filter) kan daarom zonder probleem worden toegepast op VLAN4 (= WANIPTV). Dus source address = any. Dit voorkomt problemen als KPN weer iets aanpast.

Firewall configuratie

Bij OPNsense heb je ook een uitgaande IGMP options rule nodig, anders stopt de stream na 5 minuten.

IP options vinkje is alleen nodig bij de IGMP accept regels en dan beide richtingen op. Dus zowel IPTV_STB -> IPTV WAN als IPTV WAN -> IPTV_STB

IGMP-proxy configuratie

pfSense werkende configuratie

Let op gebruik van de juiste quotes

VLAN4 DHCP instellingen om een IP adres vanuit KPN te verkrijgen:

code:

dhcp-class-identifier "IPTV_RG"
subnet-mask, routers, classless-routes

Check hierna of je de routes ontvangt en een IP krijgt op je vlan 4 interface.



Daarna kan je NAT instellen, verkeer naar dit subnet moet via de vlan4 interface afgehandeld worden. Dit kan ook via de normale route tabel verlopen, ik specificeer het graag ivm multi ISP verbindingen alhier.


Om te voorkomen dat al je internet verkeer naar vlan4 wordt gestuurd dien je de prioriteiten in te stellen zodat de vlan4 interface niet het woord (active) bevat.




Het is verstandig om de default interface (uitgang) op je router te specificeren, dat voorkomt uitdagingen waarbij vlan 4 of vlan 6/34 met elkaar vermengen.

FW rules, bij de IGMP rules dien je onder ADVANCED IP options aan te vinken.



Zelfde voor het WAN:bij de IGMP rules dien je onder ADVANCED IP options aan te vinken.

Vigor 165 config

[ Voor 184% gewijzigd door stormfly op 08-02-2023 10:51 ]

[stormfly]

ik222 schreef op woensdag 16 juni 2021 @ 22:16:
[...]

Klopt helemaal, je krijgt via DHCP specifieke routes voor verkeer over VLAN4 en de default route staat op je internet interface (anders zou je geen internet hebben). Dus je mag simpelweg alles wat over VLAN4 naar buiten gaat NAT'en.

Ik zou toch nog graag even gebruik maken van je kennis, ik heb nu een IPTV decoder om e.a. te testen. Het bleek dat door multiwan e.a. niet lekker genat werd, dat is opgelost. Vanuit het IPTV segment kan ik pingen naar het TV segment.

 ping 213.75.112.1
PING 213.75.112.1 (213.75.112.1): 56 data bytes
64 bytes from 213.75.112.1: icmp_seq=0 ttl=61 time=16.014 ms
64 bytes from 213.75.112.1: icmp_seq=1 ttl=61 time=12.080 ms
64 bytes from 213.75.112.1: icmp_seq=2 ttl=61 time=10.477 ms
64 bytes from 213.75.112.1: icmp_seq=3 ttl=61 time=9.826 ms
64 bytes from 213.75.112.1: icmp_seq=4 ttl=61 time=9.991 ms

Ik stuur nu een STRING met quotes mee " dat moet voldoende zijn?


Ik stuur de Telfort/Budget Thuis DNS servers mee


En toch blijft hij snoeihard op code 301 hangen.... "laten van software op ontvanger lukt niet" terwijl er wel internet beschikbaar is en functioneel ook werkt in dat segment.

[stormfly]

Alles lijkt in de basis te werken alleen zodra hij het IGMP wil gaan doen met MC stagneert de communicatie.

[stormfly]

@ik222 ik ben zo benieuwd waar het nu scheef loopt.

IGMP LAN verkeer gesniffed op OPNsense (UniFi switches in het pad)



IGMP WAN verkeer de IGMP proxy lijkt te functioneren.

[stormfly]

ik222 schreef op woensdag 30 juni 2021 @ 23:42:
[...]

Als text en dan zonder quotes, maar geen idee of dat verschil maakt...

IGMPProxy lijkt me inderdaad goed te werken dus dat zal het niet zijn.

Die OPTION 60 is eruit bij de orginele EB DHCP offers.



Hieronder een capture van de EB dan lijkt alles direct te werken, je ziet na het verzoek tot joinen op de .6 group dat er direct MC gaat lopen om de software te downloaden.



Hieronder de FW ruleset, zou je nog eens een blik willen werpen? Pingen naar het IPTV segment lukt dus nat etc is in orde.

[stormfly]

Met deze methode heb ik toch een 0.0.0.0/0 in de IGMP proxy gekregen, dat heeft vayatta ook (de werkende setup)

Krijg even geen tijdslot om het beeld te onderbreken ;-) om het te testen.

Ik kwam deze logs tegen, dat gaf de reden tot het bovenstaande onderzoek.

code:

Jul  2 20:35:33 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:33 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].
Jul  2 20:35:34 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:34 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].
Jul  2 20:35:35 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:36 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].

@Kabouterplop01 daar is ook ineens het antwoord op de 217.166.0.0 reeks ;-)

[stormfly]

@Coolhva @ik222

Omdat OPNsense nog steeds niet werkt heb ik twee alternatieven in een VM gebruikt. Vayatta en pfSense beide voorzien in een goede multicast TV beleving. Alles functioneert naar wens.

Het is dus echt een bug/probleem in OPNsense, zouden jullie nog 1x mee willen kijken naar de config voor ik een bug open bij OPNsense?

De foutmelding bij de STB is 561, het lijkt erop dat er op het LAN geen UDP multicast data zichtbaar is. Wat op zich opmerkelijk is want op het WAN komt deze MC data wel binnen, na een IGMP verzoek.

Zien jullie een ontbrekende FW rule? Alle segmenten, internet en 213.75.112.0/21 zijn allemaal bereikbaar via icmp. Routing en NAT zijn uitgesloten, het moet een probleem zijn met de igmp proxy of een UDP MC fw rule?

Gebaseerd op deze bron werken deze rules in pfSense feilloos.
http://un.geeig.net/openbsd-vdsl.html

tcpdump capture, gelijktijdig op vlan4 en vlan25 https://www.dropbox.com/s...zIsLhWiyTNpIhdUmJBSa?dl=0

[...]
pass in on $WANINT inet proto igmp to 224.0.0.0/4 allow-opts
pass in on $WANINT inet proto udp  to 224.0.0.0/4
[...]
pass out on $WANINT inet proto igmp from $WANIP to 224.0.0.0/4 allow-opts
[...]
pass in on $LANINT inet proto igmp from $SETTOPBOX to 224.0.0.0/4 allow-opts
pass in on $LANINT inet proto udp  from $SETTOPBOX
pass in on $LANINT inet proto tcp  from $SETTOPBOX
[...]
pass out on $LANINT inet proto igmp from $LANIP to 224.0.0.0/4 allow-opts
pass out on $LANINT inet proto udp to 224.0.0.0/4

pfSense kan een OUT richting op de interface plaatsen, dat moet via een floating rule. Om dit 100% gelijk te houden heb ik deze ook floating gemaakt in OPNsense (op de interface zelf werkt het ook niet)

Voor de volledigheid dan nog de pfSense werkende FW rules + igmp proxy

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 19:38:
[...]

Ja.

Dat denk ik niet, anders had hij niet "eruit geklapt". De enige reden dat dit gebeurd is dat je hetzelfde mac gebruikt in zowel vlan 4 als 6. Of een config fout.

Waar je ook moet doen is de gateway prioriteit verlagen, zodat de gateway prio van vlan 34 beter is dan die van vlan 4.

Zal het in de guide opnemen. Zie hieronder de dropdown, die moet dan op de vlan 34 interface staan.

[ Voor 54% gewijzigd door stormfly op 11-07-2021 20:29 ]

[stormfly]

@Arno-
Hoe ziet dit scherm er bij jou uit?



bij OPNsense is het overzichtelijker ivm de prio's

[ Voor 33% gewijzigd door stormfly op 11-07-2021 20:46 ]

[Arno-]

@stormfly Bedoel je dit?
Mijn gateway overzicht ziet er anders uit (pfSense 2.5.2)

Bij vlans zie ik wel een prioriteit.

Omdat ik nu met de routed configuratie werk heb ik de gateway gegevens weggelaten.

[Arno-]

Mijn mac adressen zijn verschillend. (NB Routed config dus geen vlan 34). Anders heb ik geen internet.
IPTV en STB zijn nu disabled.

[ Voor 3% gewijzigd door Arno- op 11-07-2021 21:40 ]

[Arno-]

[Arno-]

[Lawrentium]

Ik loop sinds kort ook tegen problemen aan met KPN (ik zit nog op de oude Telfort config).

TV kijken werkt, maar sinds kort werken er een groot aantal zenders niet meer. Bijvoorbeeld RTL4, RTL5, SBS6, RTL7, en nog veel meer.

Ik vermoed dat ik een bepaalde IP range mis in mijn config, maar ik kom er inmiddels niet meer uit.

Zien jullie iets verkeerd staan? Alvast bedankt.

[stormfly]

Lawrentium schreef op zondag 5 september 2021 @ 12:16:
Ik loop sinds kort ook tegen problemen aan met KPN (ik zit nog op de oude Telfort config).

TV kijken werkt, maar sinds kort werken er een groot aantal zenders niet meer. Bijvoorbeeld RTL4, RTL5, SBS6, RTL7, en nog veel meer.

Ik vermoed dat ik een bepaalde IP range mis in mijn config, maar ik kom er inmiddels niet meer uit.

Zien jullie iets verkeerd staan? Alvast bedankt.

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

In de start post zitten exacte kopieën van wat je dient te bouwen. Wat mij als eerste opvalt is dat je IGMP proxy allemaal losse subnetten bevat. Gemakkelijker is de grote subnetten eindigend op /1, dat scheelt je beheer als KPN iets wijzigt later.

Als je nu wel TV kunt kijken is het stap 2 om naar FW rules te kijken. Je hebt op je IPTV_WAN heel veel losse rules. Je kan hier 1x een IGMP rule van maken met source *any en dan dest 244.0.0.0/4 je weet immers niet waar de stream vandaan komt.

EDIT: bouw de howto van page 1 maar na, als het dan niet werkt is het fijner troubleshooten.

Ik zou dat eerst gelijk trekken:

[ Voor 8% gewijzigd door stormfly op 05-09-2021 12:39 ]

[Lawrentium]

Config is inmiddels identiek. Nog steeds dezelfe problemen.

Verschillende zenders doen het niet, daarnaast is het niet mogelijk te pauzeren/terug te kijken.

[casemodder]

Ik zal hem hier ook even posten om de info een beetje bij elkaar te houden.

Ben 3 dagen aan het vechten geweest met KPN IPTV wat ineens niet meer werkte op PFsense.

Oplossing:

Ik heb bij Outbound NAT een regel toegevoegd en ik kon 213.75.112.1 weer pingen, en werkte mijn STB's dus ook weer

Hoe het kan: geen idee ik had niets gewijzigd aan mijn setup maar goed het werkt weer dus

Als je KPN STB op 85% blijft hangen en volgt met error 561
check of je op het STB VLAN 213.75.112.1 kunt pingen zo niet check je firewall rules/NAT

[Lakemond]

@ik222

[Lakemond]

@ik222

[Lakemond]

@ik222 route tabel

[Lakemond]

@ik222

en deze ook nog maar even:

[Lakemond]

Deze zijn inmiddels aangepast.

@ik222 Overigens ben ik op diverse posts ooit afgegaan v.w.b. de IP reeksen 213.75.0.0 en 217.166.0.0 ik heb deze overigens ook nooit in de KPN informatie/documentatie gezien... is er een "goede" informatiebron voor deze zaken. Want de pagina van KPN met informatie voor je eigen router/firewall is wel heel summier.

[Vorkie]

Vullen jullie deze in?

Ik krijg namelijk onderstaande mee uit de DHCP request.

10.146.160.0/20 link#14 U 257 1500 igb0.4
10.146.166.xx link#14 UHS 0 16384 lo0
213.75.112.0/21 10.146.160.1 UGS 41461 1500 igb0.4

mee vanuit de routes.

[ Voor 23% gewijzigd door Vorkie op 11-11-2021 18:21 ]

[Vorkie]

supayoshi schreef op donderdag 11 november 2021 @ 18:22:
Ja maar misschien zit jij in een andere regio en krijg je dit nog mee. Wij niet meer plotseling ?

Maar jij zegt dat je geen lease krijgt? Of krijg je de routes niet door met de lease? Dus krijg je IPTV WAN wel een IP?

[supayoshi]

Vorkie schreef op donderdag 11 november 2021 @ 18:24:
[...]


Maar jij zegt dat je geen lease krijgt? Of krijg je de routes niet door met de lease? Dus krijg je IPTV WAN wel een IP?

[Afbeelding]

Nee krijg ook geen lease meer https://prnt.sc/1z6auuq

[supayoshi]

Ik heb nu helaas na plaatsen decoders in eigen subnet (had ik voorheen niet, zaten in het LAN) foutcode stb-nmc-400.

Ik heb IGMP snooping aanstaan, alleen heb ik in mijn netgears ingesteld, dit voor VLAN 2222 (IPTV_STB)

Hoe kan ik vinden wat de oorzaak hiervan is?

[ Voor 28% gewijzigd door supayoshi op 15-11-2021 19:25 ]

[supayoshi]

Ja , gewoon zelfde subnet als de guide gepakt

Mis ik nog een gateway misschien? Die krijg ik dus niet meer aangeboden door KPN, dus mijn gateway is nu een enkele...

[ Voor 66% gewijzigd door supayoshi op 15-11-2021 20:44 ]

[JohHer]

[supayoshi]

ik222 schreef op maandag 15 november 2021 @ 23:04:
[...]

Ja en vooral de goede downstream interface selecteren, ik zie nu nog "LAN" staan in de screenshot van @supayoshi maar gok dat daar de settopboxen dus nu niet meer inzitten?

Dit was idd de oorzaak, downstream IFACE was nog LAN, en moest IPTV_STB worden

@stormfly in de guide, schrijf je over LAN STB, en IPTV STB, maar je bedoeld in beide gevallen IPTV_STB.
Kan je misschien de benaming consistent maken? Dat leest voor mensen wat lekkerder / begrijpelijker.

Voorbeeldje:

[ Voor 53% gewijzigd door supayoshi op 15-11-2021 23:07 ]

[Neptunus]

Hallo mede tweakers,

kan iemand eens met mij meekijken met mijn pfsense config. Ik zie waarschijnlijk iets over het hoofd en krijg daardoor mijn KPN IPTV niet goed aan het werk.

Ik krijg foutcode stb-nmc-400.
Met testsysteem:
- Ping 213.75.112.1 IPTV subnet werkt
- Ping 1.1.1.1 normale internet werkt
- Ping Tweakers.net dns resolved en werkt dus.

In de DHCP server op VL60_IPTV geeft ik DNS van kpn mee 195.121.1.34 en 195.121.1.66

Ik ben er bijna, beeld op de TV hangt binnen paar seconden en krijg dan "stb-nmc-400". Als ik switch naar anders TV kanaal zelfde verschijnsel.

Hoop dat iemand ziet wat ik over het hoofd zie. Hieronder mijn config.

[Neptunus]

ik222 schreef op dinsdag 16 november 2021 @ 23:08:
[...]

Ik zie zo snel geen fouten in je config, draait IGMPProxy wel? En zie je iets relevants in de firewall en routing log?

En zitten er nog switches tussen?

Ja er zit nog een switch tussen, een SG350X om precies te zijn. IGMP Snooping staat aan met versie V2. VLAN verkeer loopt. Heb nu bewust de switch er voor nu tussen weg gehaald een poortje op de pfsense machine direct aangesloten.Zelfde resultaat. Ik zie in de logging geen gekke dingen.

Alle tips om de fout te vinden zijn welkom.

[Gijs007]

Ik ben hier ook bezig met OPNsense i.c.m. glasvezel van KPN.
1. Internet werkt, alhoewel ik nog geen IPv6 adressen krijg (wel een FE80 link local). Moet ik daar nog iets voor configureren? Bij KPN hebben ze het over "DHCPv6-PD verzoek (in PPPoE)"

2. Verder zag ik in het KPN v12 modem dat er gebruik wordt gemaakt van PPP, terwijl we voor OPNsense PPPoE gebruiken. Kunnen wij dan ook niet af met PPP?

3. Bij KPN pagina over het instellen van een eigen modem hebben ze het over een MTU van 1500 bytes (rfc4638). maar ik zie op mijn WAN een MTU van: 1492 Komt dit door de PPP overhead of is dit nog te optimaliseren?

4. Verder werkt de IPTV nog niet goed. De connectiviteitstest gaat wel goed, en het modem start ook correct op:
-Ping 213.75.112.1 dit is het IPTV subnet.
-Ping 1.1.1.1 het normale internet
-Ping Tweakers.net om dns te testen

Het probleem is dat ik maar een paar seconden beeld en geluid heb. Daarna krijg ik een foutcode: stb-nmc-400 (ook bij een directe verbinding tussen de STB en OPNsense)
Ik vermoed dat het hem in het IGMP verhaal zit, maar ben er na veel testen nog niet uit hoe of wat.
De firewall regels zijn toegevoegd, zoals in de TS, incl. de "allow options " functie. Ook heb ik de IGMP proxy geïnstalleerd, en met de IP's geconfigureerd zoals in de TS.





Wellicht ben ik iets uit de TS vergeten? Bij het stukje aan het begin over NAT, en aan het einde, begrijp ik niet helemaal wat er moet gebeuren. De screenshots van verschillende interfaces door elkaar heen zijn wat verwarrend, en er lijkt wat informatie te ontbreken over de uit te voeren stappen (hoe en waarom).

IPTV werkt nu ineens wel. Vermoedelijk was de IGMP proxy service al die tijd ingesteld op een oude netwerkpoort met dezelfde naam

[ Voor 29% gewijzigd door Gijs007 op 20-12-2021 17:02 ]

[stormfly]

Gijs007 schreef op maandag 20 december 2021 @ 16:34:
Ik ben hier ook bezig met OPNsense i.c.m. glasvezel van KPN.
1. Internet werkt, alhoewel ik nog geen IPv6 adressen krijg (wel een FE80 link local). Moet ik daar nog iets voor configureren? Bij KPN hebben ze het over "DHCPv6-PD verzoek (in PPPoE)"

De magie zit in het feit dat je een vinkje moet zetten dat hij voor IPv6 de IPv4 drager dient te gebruiken.

2. Verder zag ik in het KPN v12 modem dat er gebruik wordt gemaakt van PPP, terwijl we voor OPNsense PPPoE gebruiken. Kunnen wij dan ook niet af met PPP?

Dat is hetzelfde

3. Bij KPN pagina over het instellen van een eigen modem hebben ze het over een MTU van 1500 bytes (rfc4638). maar ik zie op mijn WAN een MTU van: 1492 Komt dit door de PPP overhead of is dit nog te optimaliseren?

Dat is al optimaal, niets meer aan doen.

4. Verder werkt de IPTV nog niet goed. De connectiviteitstest gaat wel goed, en het modem start ook correct op:
-Ping 213.75.112.1 dit is het IPTV subnet.
-Ping 1.1.1.1 het normale internet
-Ping Tweakers.net om dns te testen

Het probleem is dat ik maar een paar seconden beeld en geluid heb. Daarna krijg ik een foutcode: stb-nmc-400 (ook bij een directe verbinding tussen de STB en OPNsense)
Ik vermoed dat het hem in het IGMP verhaal zit, maar ben er na veel testen nog niet uit hoe of wat.
De firewall regels zijn toegevoegd, zoals in de TS, incl. de "allow options " functie. Ook heb ik de IGMP proxy geïnstalleerd, en met de IP's geconfigureerd zoals in de TS.

[Afbeelding]

[Afbeelding]

Wellicht ben ik iets uit de TS vergeten? Bij het stukje aan het begin over NAT, en aan het einde, begrijp ik niet helemaal wat er moet gebeuren. De screenshots van verschillende interfaces door elkaar heen zijn wat verwarrend, en er lijkt wat informatie te ontbreken over de uit te voeren stappen (hoe en waarom).

IPTV werkt nu ineens wel. Vermoedelijk was de IGMP proxy service al die tijd ingesteld op een oude netwerkpoort met dezelfde naam

[Gijs007]

stormfly schreef op maandag 20 december 2021 @ 18:37:
[...]

[Afbeelding]

De magie zit in het feit dat je een vinkje moet zetten dat hij voor IPv6 de IPv4 drager dient te gebruiken.
[...]

Heldere uitleg, dank!
Bij mij zag het er iets anders uit. Zo te zien gebruik je PFsense?



Ik krijg nu een delegated IPv6 prefix.
Mochten er nog andere zijn die deze vraag hebben:
Ik kon die instelling eerst niet vinden. Moest eerst naar advanced wisselen, use IPv4 aanvinken, en toen terug naar basic.
De optie do not wait for RA kan ik nergens vinden. Maar lijkt dus bij OPNsense niet nodig te zijn.


Wel nog een vraag: hoe krijg ik de IP's bij de clients? Ik kan alleen een DHCP relay configureren, maar heb daarvoor blijkbaar nog een destination server IP nodig?

[FireDrunk]

Hoi allemaal, vandaag hier ook KPN Glasvezel (1Gb) opgeleverd gekregen.
Eerst keurig alles via KPN Modem (v12) getest en daar werkte alles prima, zowel internet als IPTV.

Nu wil ik mijn pfSense doos aanpasssen om dit over te nemen.

Wat ik (volgens de diverse handleidingen online) aangepast heb:

- VLAN's toevoegen op de WAN interface (4 & 6)
- Nieuwe interfaces gedefinieerd voor deze VLAN's (KPN_IPTV en KPN_WAN in mijn geval).
- DHCP instellingen aangepast voor de KPN_IPTV (options)
- NAT Rules toegevoegd:


- IGMP Proxy ingesteld:



- Bestaande LAN any-any rule aangepast zodat deze Advanced Option IP toestaat
- Uitgaande firewall rule toegevoegd:


Internet werkt keurig, alleen IPTV werkt compleet niet, bij start krijg ik:
- "Downloaden van software"
- 2x een laad balk
- Daarna een code 563.

Wat heb ik al geprobeerd:
- Ik krijg keurig een ip (via dhcp) op de KPN_IPTV interface
- Ik krijg keurig de routes gepushed (213.x)
- Firewall logging geeft geen denies uitgaand weer
- De IGMP Proxy logging van rondom de startup van de box:

[2.5.2-RELEASE][admin@***]/root: /usr/local/sbin/igmpproxy -vd /var/etc/igmpproxy.conf
adding VIF, Ix 0 Fl 0x0 IP 0x0101a8c0 re0, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0x3201a8c0 re0, Threshold: 1, Ratelimit: 0
adding VIF, Ix 2 Fl 0x0 IP 0xc806fc0a re1.4, Threshold: 1, Ratelimit: 0
Joining group 224.0.0.2 on interface re0
Joining group 224.0.0.22 on interface re0
Joining group 224.0.0.2 on interface re0
can't join group 224.0.0.2 on interface re0; Errno(48): Address already in use
Joining group 224.0.0.22 on interface re0
can't join group 224.0.0.22 on interface re0; Errno(48): Address already in use
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Inserted route table entry for 233.89.188.1 on VIF #0
Joining group 233.89.188.1 on interface re1.4
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Inserted route table entry for 239.254.127.63 on VIF #0
Joining group 239.254.127.63 on interface re1.4
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.1.112   to 224.0.0.251
Inserted route table entry for 224.0.0.251 on VIF #0
Joining group 224.0.0.251 on interface re1.4
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.112   to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
RECV V2 member report   from 192.168.1.14    to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
RECV V2 member report   from 192.168.1.112   to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 10.10.10.10     to 224.0.0.1
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
RECV V3 member report   from 10.252.6.200    to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.112   to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 192.168.1.1     to 224.0.0.1
RECV Membership query   from 192.168.1.50    to 224.0.0.1
The IGMP message was local multicast. Ignoring.
The source address 192.168.1.167 for group 239.254.127.63 is from downstream VIF[0]. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V1 member report   from 192.168.1.169   to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
RECV V1 member report   from 192.168.1.169   to 224.0.0.251
Updated route entry for 224.0.0.251 on VIF #0
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
RECV V2 member report   from 192.168.1.1     to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.1.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 192.168.1.167   to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.
The IGMP message was local multicast. Ignoring.

De IPTV Box heeft IP 192.168.1.193

Iemand een idee hoe ik verder kan debuggen? Alle switches in mijn hele huis ondersteunen IGMP Multicasting (2x TP-Link SG-108E, 1x TP-Link SG3216).

[ Voor 3% gewijzigd door FireDrunk op 21-12-2021 21:57 ]

[FireDrunk]

ik222 schreef op dinsdag 21 december 2021 @ 22:11:
@FireDrunk Heb je ook de inkomende firewall regels op de IPTV_WAN interface aangemaakt?

Yes, vergeten te vermelden:

[PerlinNoise]

@FireDrunk, gisteren ben ik ook aangesloten door KPN en ook geprobeerd iptv werkend te krijgen. Uiteindelijk is dit gelukt, maar het grappige is dat ik precies tegen hetzelfde aan liep als jou.
Ik zal even mijn instellingen met die van jou vergelijken:

WAN_IPTV:


NAT:

Source heb ik ip van de iptv Arris box.



IGMP Proxy:



Firewall Aliases: Type: networks ipv hosts



Lan firewall rules:

IPTV Arris box bovenaan gezet, toegang tot alles.



WAN_IPTV firewall rules:



BELANGRIJK:

Op alle drie de firewall rules heb ik Allow IP options aangevinkt (onder Advanced Options per firewall rule). Anders had ik na enkele minuten op dezelfde zender dat beeld vastliep en foutmelding stb-nmc-400.



Ik zie wel wat verschillen, als bij jou, zoals upstream IGMP 10.0.0.0/8 en wat meer firewall rules.

Uiteindelijk wil ik de iptv Arris box in een aparte VLAN, maar was al blij dat het werkte.

@ik222 Is er een manier om een aparte vlan voor IPTV alleen toegang te geven tot uitgaande IPTV VLAN 4, en niet internet VLAN 6?

[FireDrunk]

@PerlinNoise IGMP Proxy aangepast, mocht niet baten helaas.
@ik222 Goed gespot, maar mocht niet baten.
@Vorkie Ik ben al helemaal over op KPN voor mijn primaire internet, inclusief DNS.
Deze staat overigens gewoon op 'Override from DHCP/PPP, waardoor hij automatisch de DNS van de actieve WAN verbinding zou moeten pakken.



Ik heb alleen de DNS Resolver actief, niet de DNS Forwarder.

[ Voor 4% gewijzigd door FireDrunk op 22-12-2021 09:57 ]

[FireDrunk]

PerlinNoise schreef op woensdag 22 december 2021 @ 09:57:
[...]


Heb je al mijn instellingen goed overgenomen? firewall rules lijken ook beetje krap bij je.
Ik lees overal ook rebooten, dus probeer dat eens na aanpassen settings.

Helaas, het mocht niet baten:



Mijn LAN rule(s) staan op allow any/any inclusief die advanced option. Dat zou het probleem niet mogen zijn.

Ik kan nog een router reboot proberen, maar dan moet ik even de vrouw inlichten

[ Voor 5% gewijzigd door FireDrunk op 22-12-2021 10:12 ]

[Vorkie]

FireDrunk schreef op woensdag 22 december 2021 @ 10:10:
[...]

Helaas, het mocht niet baten:

[Afbeelding]

Mijn LAN rule(s) staan op allow any/any inclusief die advanced option. Dat zou het probleem niet mogen zijn.

IPTV LAN


IPTV WAN


IGMP Proxy


DHCP options:


Outbound NAT:


Dit komt zo 1 op 1 van mijn huidige configuratie af, maar staat ook op mijn website.

[ Voor 11% gewijzigd door Vorkie op 22-12-2021 10:14 ]

[ik222]

FireDrunk schreef op woensdag 22 december 2021 @ 10:10:
[...]

Helaas, het mocht niet baten:

[Afbeelding]

Mijn LAN rule(s) staan op allow any/any inclusief die advanced option. Dat zou het probleem niet mogen zijn.

Ik kan nog een router reboot proberen, maar dan moet ik even de vrouw inlichten

Ik zou hier een ruimere regel voor IGMP maken met options aan. Zo staat het bij mij:



En anders inderdaad rebooten, zeker nadat je NAT regels aangepast hebt is dat soms nodig. Al lijkt dat bij jou wel gewoon goed omdat je kan pingen.

[ Voor 6% gewijzigd door ik222 op 22-12-2021 10:19 ]

[PerlinNoise]

FireDrunk schreef op woensdag 22 december 2021 @ 10:27:
[...]


Ik heb geen apart VLAN voor IPTV, dus jouw configuratie komt niet helemaal overeen.

[...]

Bedoel je op de LAN of op de KPN_IPTV kant?

KPN_IPTV



Daarom gewoon even overal toegang toe geven in LAN firewall rules. Kan dat het igg niet zijn.

[ Voor 60% gewijzigd door PerlinNoise op 22-12-2021 10:31 ]

[ik222]

FireDrunk schreef op woensdag 22 december 2021 @ 10:27:
[...]


Ik heb geen apart VLAN voor IPTV, dus jouw configuratie komt niet helemaal overeen.

[...]

Bedoel je op de LAN of op de KPN_IPTV kant?

KPN_ITV.

De regels op mijn LAN / STB interface zijn dit:

[FireDrunk]

Vorkie schreef op woensdag 22 december 2021 @ 10:41:
[...]


Dat maakt natuurlijk niet zo heel veel uit, voor je LAN geldt hetzelfde.

Je IPTVbox gebruikt namelijk ook 224.0.0.0 als source, dus je allow regel doet alleen maar "internet" regelen.

Ooh, dat wist ik niet, dat zou wel eens de key van dit probleem kunnen zijn, want mijn LAN rule accepteert wel alleen mijn LAN Subnet als source.

Even extra rule maken.

EDIT: Helaas, geen soulaas.
EDIT2:

Hmm, ik zie net ook deze langskomen:



re1 is mijn (fysieke) WAN interface, zonder VLAN's dus. Wel een vreemde.
Die kan ik dus ook niet allowen, want dat is op dit moment geen geldige interface.

[ Voor 37% gewijzigd door FireDrunk op 22-12-2021 11:07 ]

[FireDrunk]

Vorkie schreef op woensdag 22 december 2021 @ 11:11:
[...]


Ik wil je echt vragen om mijn regels, of die van @ik222 over te nemen bovenin je IPTV WAN en LAN firewall rules.

Werkt niet helaas, enige verschil is dat ik in de rules de Gateway niet op KPN_IPTV kan forceren, want dat ding geeft geen default gateway.

Enige wat ik nog kan bedenken, is de decoder even direct aan de LAN interface van mijn Router hangen, om IGMP ellende op de switches uit te sluiten, maar ik had verwacht dat de decoder dan wel zou booten, maar alleen zwart beeld zou geven.

[ Voor 16% gewijzigd door FireDrunk op 22-12-2021 11:32 ]

[Vorkie]

FireDrunk schreef op woensdag 22 december 2021 @ 11:41:
[...]

Harde reset zal ik zo doen.
Ik krijg steeds code 563 na boot.

Hoe stond je NAT?

Of heb ik dat gemist?



Je IPTV kastje moet helemaal bovenin staan. (waar mijn xbox staat)

[ Voor 5% gewijzigd door Vorkie op 22-12-2021 11:44 ]

[FireDrunk]

Vorkie schreef op woensdag 22 december 2021 @ 11:43:
[...]

Hoe stond je NAT?

Of heb ik dat gemist?

[Afbeelding]

Je IPTV kastje moet helemaal bovenin staan. (waar mijn xbox staat)

[Vorkie]

FireDrunk schreef op woensdag 22 december 2021 @ 11:45:
[...]

[Afbeelding]

Zorg dat dit op je IPTV WAN interface staat.


In je Diagnostics zou er dan in routes deze moeten staan.



Staat dat er ook?

[FireDrunk]

Vorkie schreef op woensdag 22 december 2021 @ 11:50:
[...]


Zorg dat dit op je IPTV WAN interface staat.
[Afbeelding]

In je Diagnostics zou er dan in routes deze moeten staan.

[Afbeelding]

Staat dat er ook?

Yup, ingesteld, en ik krijg die route (maar wel met een andere gateway: 10.252.4.1).
Ook kan ik 213.75.112.1 pingen, waardoor ik relatief zeker weet dat die static route goed werkt.

Ik zie ook op de interface wel echt traffic binnen komen:

Waardoor ik vermoed dat de IGMP Multicast Group Join dus ook wel lukt, maar dat de decoder vanwege een andere reden zegt, bekijk het...

EDIT: Harde reset (standby button inhouden voor de power inpluggen) heeft niet geholpen, de andere reset methode (tijdens het blauwe opstartscherm 1 keer op de knop drukken), werkt niet.

En ineens springt de decoder aan, omdat ik in 1 van mijn switches IGMP Snooping *uit* zet...
Blijkbaar is de default snooping config niet toereikend...

Allen hier bedankt voor de hulp!

[ Voor 35% gewijzigd door FireDrunk op 22-12-2021 13:11 ]

[Videopac]

Aangezien de handleiding uit de OP te grote stappen voor mij neemt (ik heb voor 90% geen idee wat ik aan het doen ben) volg ik deze handleiding. Dat gaat goed totdat ik bij Gateway-single de IPTV regel aan moet passen: ik heb die regel niet.

Dus ik loop hier vast.
Internet werkt nu prima, maar televisie nog niet.
Ik heb alles 3x bij langs gelopen maar heb volgens mij geen fouten gemaakt.
Iemand een idee hoe nu verder?

[Conjurer]

Afgelopen weekend heb ik mijn Pfsense installatie i.c.m. IPTV in werking gesteld. Mijn configuratie is o.a. gebaseerd op informatie uit dit topic. Bij deze post ik mijn werkende configuratie om op mijn beurt anderen te helpen.

Wat werkt er?
(slag om de arm, heb de pfSense router met IPTV nu 3 dagen in gebruik):

TV kijken	✅
TV gids	✅
TV pauzeren	✅
Programma's terugkijken	✅
Apps (bv Youtube)	✅

Algemene info
Provider: KPN
TV ontvanger: Arcadyan HMB2260
Router software: pfSense 2.5.2-RELEASE (amd64)

Aansluiting
KPN glasvezel modem ----> (igb0) pfSense router
pfSense router (igb2) ----> KPN TV ontvanger

Verklarende woordenlijst
01_WAN = KPN internet
01_WAN_IPTV = KPN IPTV
03_IPTV_WOONKAMER = KPN TV ontvanger / STB / Arcadyan HMB2260

Screenshots
1. Interfaces -> Assignments -> VLANs


2. Interfaces -> Assignments -> PPPs


3. Interfaces -> Assignments -> PPPs -> pppoe0


4. Interfaces -> Assignments -> Interface Assignments


5. Interfaces -> Assignments -> Interface Assignments -> 01_WAN


6. Interfaces -> Assignments -> Interface Assignments -> 01_WAN_IPTV


7. Interfaces -> Assignments -> Interface Assignments -> 03_IPTV_WOONKAMER


8. Services -> DHCP Server -> 03_IPTV_WOONKAMER


9. Services -> IGMP Proxy


10. Firewall -> NAT -> Outbound


11. Firewall -> Rules -> 01_WAN_IPTV


12. Firewall -> Rules -> 03_IPTV_WOONKAMER

[Vorkie]

@Conjurer Vroeger was het inderdaad 1492 voor PPPoE, maar tegenwoordig heeft KPN dat aangepast en hoef je dus geen vul je 1500 MTU size in mee te geven, dan gaat ie naar 1500, zonder issues. Geen idee meer waar ik dit had gelezen, maar had in het begin ook 1492.



Bij je WAN DHCP options zie ik dat je 1 optie niet gebruikt ; geen idee waarom niet, maar het viel op.

code:

subnet-mask, routers, broadcast-address[, classless-routes

/Edit

Je moet wel 1500 invullen! Niet leeg laten.. sorry

[ Voor 6% gewijzigd door Vorkie op 12-01-2022 19:10 ]

[Videopac]

PerlinNoise schreef op woensdag 12 januari 2022 @ 06:52:
[...]


Heb je wel een WAN interface voor IPTV op vlan 4 dhcp (geen pppoe)...?

Ik denk het wel:

[ Voor 13% gewijzigd door Videopac op 12-01-2022 17:17 ]

[Videopac]

Vorkie schreef op woensdag 12 januari 2022 @ 18:51:
[...]

Probeer eens 1500 in te vullen ipv leeg?

1500 ingevuld, gereboot en nog steeds 1492.
NB: ik kijk bij Interfaces - Overview, ik neem aan dat dat de bedoeling is?
Het rare is dat ik geen IPv6 adres (meer) krijg en dat als MAC adres 00:00:00:00:00:00 ingevuld staat.

[Videopac]

ik222 schreef op woensdag 12 januari 2022 @ 08:27:
[...]

Ik zou zeggen configureer alles volgens de door jou gevonden handleiding en kijk dan of het werkt. Zo niet dan post hier maar screenshots van je configuratie, dan kunnen we kijken of we ergens een fout zien.

Gisteravond weer een paar uur hieraan gespendeerd, zonder positief resultaat helaas. Ik bleek wel verkeerde haakjes bij IPTV_RG gebruikt te hebben; ik had dat al eens gecontroleerd maar was toen waarschijnlijk te moe/gefrustreerd dat ik toch niet goed gekeken heb toen. Ik kan nu wel 213.75.112.1 pingen, verder geen merkbare progressie.

NB: ik ben nu begonnen o.b.v. OPNsense 22.1rc1, omdat er in FreeBSD 13 betere Realtek ondersteuning zou zitten (al betwijfel ik nu of daar een probleem zit). Hieronder mijn screenschots. Mocht iemand iets incorrects zien hoor ik het graag.Alvast bedankt voor de hulp, i.i.g.

[Videopac]

ik222 schreef op zondag 16 januari 2022 @ 15:40:
[...]

Ik zie de routes wel hoor in zijn screenshots, dat hij naar dat 213 adres kan pingen zegt ook dat de routes en de NAT regels goed zijn.

@Videopac Ik mis de screenshots van je firewall regels op de IPTV_WAN en je LAN interface. Wat je nu gepost hebt ziet er goed uit.

Dank voor je reactie. Hierbij de missende print screens.

[Videopac]

ik222 schreef op zondag 16 januari 2022 @ 21:10:
Oké, heb je ook “allow IP options” aan staan op de IGMP regels? En welke error geeft je settopbox nu precies?

Zie hieronder. Bij OPNsense heet dit "allow options". De foutmelding die ik krijg is "stb-nmc-400".

[Videopac]

Goed, nieuwe poging met pfsense. Ik krijg de WAN niet eens aan de praat. Ben de instellingen bij langs aan het lopen en het enige dat mij opviel is dat ik een tweede PPPoE regel heb die ik niet kan verwijderen.

Toevoeging: opgelost. de WAN stond gekoppeld aan die PPPoE1 i.p.v. PPPoE0.

[ Voor 6% gewijzigd door Videopac op 19-01-2022 09:43 ]

[Videopac]

Mijn LAN screenshots (in het voorbeeld eerder werd uitgegaan van een aparte interface voor de stb.).

[Videopac]

Iets later dan beloofd, maar hierbij de instellingen die bij mijn (apparaat met 1 WAN poort en 1 LAN poort) werken:

Wat werkt er?
(slag om de arm, heb de pfSense router met IPTV nu 2 dagen in gebruik):

TV kijken	✅
TV gids	✅
TV pauzeren	✅
Programma's terugkijken	✅
Apps (bv Youtube)	✅

Algemene info
Provider: KPN.
TV ontvanger: Arris ...
Router software: pfSense 2.5.2-RELEASE (amd64).
Router hardware: Odroid H2.

Aansluiting
KPN glasvezel modem ----> (re1) pfSense router.
pfSense router (re0) ----> LAN switch (en daarop KPN TV ontvanger e.a.).

Verklarende woordenlijst
WAN = KPN internet
WAN_IPTV = KPN IPTV
LAN = LAN, waaronder KPN TV ontvanger / STB / Arris

Screenshots
1. Interfaces -> Assignments -> VLANs


2. Interfaces -> Assignments -> PPPs


3. Interfaces -> Assignments -> PPPs -> pppoe0


4. Interfaces -> Assignments -> Interface Assignments


5. Interfaces -> Assignments -> Interface Assignments -> 01_WAN


6. Interfaces -> Assignments -> Interface Assignments -> 01_WAN_IPTV


7. Interfaces -> Assignments -> Interface Assignments -> 03_IPTV_WOONKAMER


8. Services -> DHCP Server -> 03_IPTV_WOONKAMER


9. Services -> IGMP Proxy


10. Firewall -> NAT -> Outbound


11. Firewall -> Rules -> 01_WAN_IPTV


12. Firewall -> Rules -> 03_IPTV_WOONKAMER


NB: een aantal instellingen zijn anders dan in het eerder genoemde voorbeeld, waaronder MTU. Ik heb die wel op 1500 proberen te zetten maar dat leverde veel problemen op.

Mocht iemand iets zien dat beter zou kunnen: laat het dan even weten.

[Pimmetje651]

heb ik zeker :

[sunib]

Gevonden, hij zit ook in OPNSense!



Ik zal 'm eens wat 'zwaarder' zetten want bij lang pauzeren wil ie bij ons ook nog wel eens wegvallen. En natuurlijk krijgt mijn server dan direct de schuld van mevrouw Subib :-)

[ Voor 22% gewijzigd door sunib op 06-02-2022 21:28 ]

[supayoshi]

Ik heb nog moeite met de juiste MTU instellingen... ik kom toch op 1492 uit maar ik doe vast wat verkeerd, zie onderstaande

Ik heb een interface:
em0_vlan6 welke ik niets aan doe op moment... staat niks op geconfigureerd.


WAN_KPN die de PPPoE sessie opzet met MTU 1500 ingesteld nu, als ik die op 1508 zet, dan lopen verbindingen traag...

[ Voor 24% gewijzigd door supayoshi op 08-02-2022 15:19 ]

[Gijs007]

Ik had een werkende setup, heb onlangs mijn OPNsense geüpdatet naar de laatste versie. Toen werd er plotseling bepaald verkeer geblokkeerd, waardoor de Arris STB niet wou starten, ondanks een aanwezige firewall regel die dat verkeer gewoon door zou moeten laten. Heb toen die firewall regel opnieuw aangemaakt, waarna het weer werkte.

Vandaag is OPNsense herstart en nu ervaar ik weer problemen, ik krijg foutcode stb-nmc-400. Wat zou duiden op IGMP problemen, maar die zie ik niet.

Het enige wat ik nog terug zie komen is de volgende blokkade:


Dat IP: 192.168.3.120 zegt mij echter niks, het bestaat niet in mijn netwerk.

En ook deze zag ik nog terugkomen:


Iemand nog tips?

[ Voor 24% gewijzigd door Gijs007 op 10-02-2022 00:31 ]

[Gijs007]

ik222 schreef op donderdag 10 februari 2022 @ 08:23:
[...]

Vooral die laatste hoor je niet te zien, hoe zien je firewall regels eruit?

Heb ze ook even uitgeschakeld en opnieuw aangemaakt met de naam test, maar ook dat mocht niet baten.

Overigens, ook even geprobeerd om de software van de STB op te halen, maar dat wou ook niet lukken:


Voor de zekerheid ook even met het KPN modem getest, dan werkt het wel.

Update:
Zojuist full nucleair gegaan, en alle regels verwijdert + daarna de interfaces. Vervolgens alles opnieuw aangemaakt volgens de TS. Helaas mocht dat niet baten, resultaat is niet verbeterd, de decoder wil nu niet verder opstarten (blijft hangen op 85%), dus ik krijg helemaal geen TV meer.

In de firewall zie zo nu en dan (om de paar minuten) deze blokkade terugkomen, maar normaal gesproken zou de decoder dan al opgestart moeten zijn en zou ik TV moeten hebben. Dus denk niet dat het relevant is:



Snap ook even niet waarom dit geblokkeerd wordt, want deze regel zou dit toch gewoon toe moeten laten?



Update2: net even getest met een laptop en vanaf de firewall, ik kan 213.75.112.1 niet pingen.
Dus blijkbaar gaat er iets niet goed met de routering rondom het IPTV netwerk. Ik krijg de routes wel netjes binnen op de IPTV_wan...
De gateway van het 10.x.x.x/20 netwerk kan ik trouwens ook niet pingen, maar er verschijnt wel een entry in mijn ARP tabel met een "HUAWEI TECHNOLOGIES CO.,LTD" apparaat. Ook kan ik wel de software van de decoder ophalen.



Update 3: ik lees iets over options 28 "broadcast address", in de documentatie van KPN:
https://kpn.com/w3/file?u...ntid=50183&mode=incontext

Die nemen we nu nog niet mee op de IPTV WAN interface.


Voor de volledigheid nog even de firewall regels. Ik snap het echt even niet meer, voorheen werkte deze config gewoon en het is volgens mij identiek aan de TS

[ Voor 64% gewijzigd door Gijs007 op 11-02-2022 13:02 ]

[Gijs007]

Fonz55 schreef op woensdag 9 februari 2022 @ 16:52:
Na een eerste (semi)succesvolle implementatie op Proxmox had ik een behoorlijke lag bij het zappen tussen zenders en het laden van webpagina's langzaam. Omdat ik ook nog eens in het hele VLAN gebeuren wilde duiken om de boel te scheiden heb ik nu een opzet met een apart VLAN(25). Het internet deel werkt goed (meer testen wel nodig), maar het pingen van 213.75.112.1 (VLAN4) binnen het VLAN25 lukt me niet. Waarschijnlijk zit het ergens qua NAT niet lekker maar heb inmiddels zoveel gewijzigd dat er misschien al meer aangepast moet worden. Zouden jullie eens mijn opzet willen langslopen en aangeven waar iets aangepast moet worden? Alle schermen heb ik maar eens netjes op Github gezet zodat ik terug kan vinden welke wijzigingen ik heb doorgevoerd.

https://github.com/fonz55...ation/blob/main/README.md

Klink een beetje als hetzelfde probleem dat ik ook heb, ik kan ook 213.75.112.1 niet meer pingen...
Dacht eerst dat het aan mijn OPNsense installatie lag, maar wellicht is er bij KPN iets gewijzigd?

Update:
Zojuist een packet capture gedaan. De ping wordt gewoon over de IPTV_WAN interface verstuurd naar het MAC adres van de gateway aan de KPN kant.



Volgens mij gaat er dus iets bij KPN mis
Snap alleen niet waarom het dan wel werkt met een experiabox aangesloten, tenzij die stiekem andere instellingen gebruikt.

[ Voor 22% gewijzigd door Gijs007 op 11-02-2022 13:30 ]

[Gijs007]

ik222 schreef op vrijdag 11 februari 2022 @ 13:37:
[...]

@Gijs007 Nee er gaat niets bij KPN mis, wat er fout gaat is dat OpnSense geen NAT toepast op het uitgaande verkeer over de IPTV_WAN interface. En dat is ook logisch want je beperkt je uitgaande NAT regel tot verkeer vanuit 172.30.0.0/20 en je pingt nu met 172.16.25.12, dat adres ligt niet binnen 172.30.0.0/20.

Dus dat het bij jou nu niet werkt is logisch, je moet je NAT regel aanpassen en kunt eigenlijk gewoon dat hele source subnet weghalen. Alles wat via IPTV_WAN naar buiten gaat mag gewoon geNAT worden

/edit: Ik zie wel dat je ook nog een NAT regel met any hebt maar hoe dan ook werkt dat dus niet nu. Ik zou enkel de regel om alles over IPTV_WAN te NAT'en laten staan en dan daarna ook je machine even rebooten.

Heb die nat regel even uitgeschakeld, kwam uit de TS, kopje: Update november 2021
Wat overigens wel precies op mijn 561 error in gaat.

Heb het nu even geconfigureerd zoals in onder het kopje: NAT configuratie
Helaas maakt dat geen verschil.

Overigens zag ik bij een eerdere packet capture, tijdens het ophalen van de software, dat er wel verkeer naar 213.75.116.x adressen gaat. Dat duidt toch op routering die wel correct functioneert.

Update: ook met deze instellingen werkt het niet:


Zit op dit moment dus met die 561 error, waarbij ik niet verder dan 85% kom met het opstarten van de STB.

[ Voor 19% gewijzigd door Gijs007 op 11-02-2022 15:14 ]

[Tweaker_home]

ik222 schreef op maandag 7 februari 2022 @ 17:32:
[...]

Sessies blijven langer open staan, dat kan in theorie zorgen voor een iets hoger geheugen en CPU gebruik. In de praktijk zul je daar niets van merken op een thuis firewall.

Kan niet zeggen dat ik daar iets van merk

hooguit 2 %meer cpu
picture is van een niet stilstaande beeld

[Fonz55]

Ik heb het nu twee weken werkend.
Wat werkt er?

TV kijken ✅
TV gids ✅
TV pauzeren ✅
Programma's terugkijken ✅

Met een steile leercurve ben ik mijn netwerk kennis bij de tijd aan het brengen. Super leuk! Nu zat ik vanmiddag weer eens de live logs te bekijken en kwam onderstaand verkeer tegen. Allereerst verbaas ik me over dat dit verkeer op mijn LAN wordt geblokkeerd. Ik zou eerder verwachten dat dit op WAN_IPTV te zien zou zijn. Inkomend op het aparte STB Vlan had ik ook nog gesnapt maar op mijn LAN interface totaal niet. Of heeft dit niets met IPTV te maken gezien de destination port van 443? Kan iemand aangeven of ik nog een routering moet aanpassen of een FW regel aanpassen?

[misteriks]

Ik heb het topic van voor naar achter door gelezen en van alles geprobeerd, maar ik krijg het niet voor elkaar om KPN TV werkend te krijgen via PFSense v2.5.2.

TV box in LAN 192.168.0.0/30 (Intern geen apart VLAN voor tv box)
TV Box is nieuw en nog niet geactiveerd via de Experiabox
TV box blijft hangen op 85% en geeft error 563. Nieuwe software ophalen werkt wel

213.75.112.1 kan ik niet pingen

IGMP snooping enabled op de TP-Link switches die ik heb

Ik zal wat screenshots plaatsen van mijn huidige config.
Hopelijk kan ik met jullie inzicht het probleem boven water krijgen

PFSense draait op een pc met een quad nic.

[misteriks]

Klopt, ik wil de TV box gewoon in een een switch/outlet kunnen prikken. Hoeft niet op een apart intern VLAN.

Geen idee welke hersenspinsel ik had toen ik overal /30 als subnet heb opgegeven.

Mijn LAN range is 192.168.0.1 - 192.168.3.254 dus subnetmask 255.255.252.0 ofwel /22

Een reset naar defaults gaat me wat ver, maar Ik heb overal waar een verwijzing stond naar /30 gewijzigd naar 192.168.0.0/22 en pfsense een reboot gegeven.
Resultaat is nog hetzelfde, Blijft hangen op 85% met error 563 en kan niet pingen naar 213.75.112.1

[ Voor 9% gewijzigd door misteriks op 13-03-2022 18:53 ]

[misteriks]

ik222 schreef op maandag 14 maart 2022 @ 21:47:
[...]

Meestal mis je dan een firewall regel die IGMP vanaf de IPTV WAN interface toestaat. Daardoor worden dan Group Specific Queries gedropt wat resulteert in streams die na een paar minuten stoppen.

Dit zijn mijn huidige WAN_IPTV firewall rules. Ik heb ook getest met source ANY zoals in je openingspost, maar dat maakte geen verschil.

[Beammo]

@misteriks een laatste poging om je duidelijker te maken waar je in de fout gaat


Je moet de igmp proxy opzetten tussen de lan poort waarop je het IPTV kastje hebt aangesloten en vlan4.
voor zover ik het nu kan zien heb jij je proxy werkend op de vlan6

De blauwe lijn moet dus je proxy worden

[Videopac]

Ik ben bezig OPNsense op mijn Protectli FW6B te installeren maar kom er, ondanks de handleidingen uit de openingspost en die van @Beammo niet helemaal uit. Mijn internet werkt perfect. IPTV nog niet. Eerst kreeg ik die vrijwel aan de praat, als in: een paar seconden beeld en dan een 400 foutmelding. Na wat verder uitproberen blijft hij nu op 85% hangen. Ik zie zelf niet wat er fout gaat.

ibg0 = WAN
ibg1 = LAN
ibg2 = IPTV

Dashboard overzicht:

Interfaces - VLAN

Interfaces assignments:






















Firewall NAT Outbound:


Firewall rules:









IGMP Proxy:

[Beammo]

Je hebt je iptv interface (vlan) op een lan poort staan, die moet op de wan poort.

Alle lanpoorten zijn standaard dhcp actieve poorten Beammo in "OPNsense & pfSense KPN/Telfort IPTV how-..."

splitsen gaat op de wan poort, dus alle vlan's asignen aan igb0

[ Voor 78% gewijzigd door Beammo op 21-03-2022 08:15 ]

[Videopac]

Beammo schreef op maandag 21 maart 2022 @ 08:04:
Je hebt je iptv interface (vlan) op een lan poort staan, die moet op de wan poort.

Alle lanpoorten zijn standaard dhcp actieve poorten Beammo in "OPNsense & pfSense KPN/Telfort IPTV how-..."

splitsen gaat op de wan poort, dus alle vlan's asignen aan igb0

[Afbeelding]

Dank voor je snelle reactie. Volgens mij heb ik dat ook gedaan, of zie ik iets over het hoofd?

[Videopac]

stormfly schreef op maandag 21 maart 2022 @ 09:49:
[...]


LAN IPTV gateway 192.168.1.1 IGMP proxy configratie 192.168.4.0/24

Kan je wel het adres pingen vanuit de openingspost?

De schermafbeeldingen zijn door elkaar geraakt hierboven.
Hieronder de correcte LAN_IPTV interface:
Ik kan 213.75.112.1 niet pingen (niet vanaf LAN, niet vanaf IPTV en niet vanuit OPNsense).

[Sjorsl820]

Beammo schreef op maandag 14 maart 2022 @ 22:31:
Hier staat een complete bijgewerkte handleiding voor Opnsense en pfsense met duidelijke scrrenshots van alle instellingen voor IPTV zonder gebruik te maken van virtualisatie

Dank voor de mooie handleiding! Ik heb sindskort ook een kpn verbinding en ben aan de slag met pfsense. Na het volgen van je handleiding werkt internet, maar TV niet (beetje de default bij de leken zoals ik die ermee aan de slag gaan). Afgelopen dagen heb ik zelf geprobeerd te troubleshooten maar ik kom niet echt verder.

Ik gebruikt een systeem met drie netwerk interfaces. 1 wan, 1 lan en 1 lan_IPTV lijkt dus erg op je handleiding. De status van mijn interfaces lijkt goed;



Mijn WAN_IPTV krijgt via DHCP een ip adres, en mijn derde lan interface (LAN2_IPTV) is direct verbonden met de STB. De STB krijgt ook een ip adres (192.168.3.100).

Ik vermoed dat het mis gaat bij de NAT / firewall instellingen, ik kan vanaf de LAN2 interface ook niet het specifieke ip adres pingen (een ping vanaf die interface naar 1.1.1.1 en tweakers.net werkt wel). Ook als ik naar de onderstaande grafiek kijk zie in geen uitgaand verkeer op de VLAN4;



NAT outbound;


Firewall rules LAN2_IPTV;


WAN_IPTV;


IGMP Proxy;


Wat zie ik over het hoofd?

[Beammo]

Settings lijken goed te zijn, start modem opnieuw op na een save, start iptv kastje opnieuw op en kijk op status pagina of de igmp proxy wel opstart, zoniet ff op play klikken bij die igmp proxy.

[MikeP.]

Videopac schreef op dinsdag 22 maart 2022 @ 21:18:
Weet iemand hoe ik het versienummer van IGMP proxy (os-igmp-proxy?) kan achterhalen in pfSense en OPNsense? In OPNsense staat v1.5.2, maar of dat ook het versienummer van de onderliggende IGMPproxy is.

Ik vraag dit omdat het me opvalt dat met 2 verschillende apparaten het me niet lukt om met OPNsense KPN tv werkend te krijgen.

Je kan het versienummer van igmpproxy achterhalen door het commando igmpproxy -h uit te voeren. Hieronder een afbeelding met de igmpproxy versie 0.3 in pfsense 2.6.0.

[Conjurer]

Het lijkt er op dat ik het probleem met hiccups opgelost heb. Kwam er achter dat IPTV ieder kwartier stotterde. Uiteindelijk kon ik het ook reproduceren door een filter reload uit te voeren (menu Status -> Filter Reload). Ieder kwartier wordt cronjob "/etc/rc.filter_configure_sync" uitgevoerd. Deze actie (over)belast de CPU gedurende een paar seconden.

Er is een issue aangemaakt, hoogstwaarschijnlijk wordt het in een volgende versie (2.7?) opgelost: https://redmine.pfsense.org/issues/12827?tab=notes. Tot het uitkomen van die release kun je d.m.v. een patch het nu al oplossen.

Oplossing: installeer patch “Disable pf counter data preservation to temporarily work around latency when reloading large rulesets”. Een patch installeren kun je doen door eerst de package “System_Patches” te installeren. Daarna kun je via menu System -> Patches de betreffende patch installeren.



Opnieuw uitvoeren van een filter reload levert dan geen stotterend beeld en/of geluid meer op.

[Sjek13]

Ik ben bezig om iptv werkend te krijgen met pfsense maar het wil nog niet lukken.

Ik kan nog niet pingen op 213.75.112.1

als ik Packet capture doe op de IPTV_WAN zie ik dit:


hij stuurt het dus naar buiten met mijn iptv_wan ip adres wat ik van kpn heb gekregen, dan zou de firewall en NAT goed moeten zijn toch?

heeft iemand een idee waar ik dit nog in kan zoeken?

[thehog]

Even een update. Het ziet er allemaal nog goed uit! Hij blifjt nu stabiel en ben inmiddels begonnen om rest van m'n IOT in proxmox te zetten.

Zijn er al anderen die mijn mod op pfsense/opnsense hebbengeprobeerd met de drie whitelist netblocks?

[stormfly]

thehog schreef op woensdag 18 januari 2023 @ 13:28:
En wat ik zie in je logs dat er nergens een join komt voor de multicast group. Omdat KPN begint te sturen wordt hij wel in de tabel gezet maar gaat igmpproxy gelijkt afvragen wie hier om gevraagd heeft en na timeout gooit ie hem er weer uit.
Dus op 1 of andere manier komt de verzoek van je STB wel bij KPN binnen maar niet langs igmpproxy.

Ja je hebt gelijk ik was chaotisch bezig. Omdat je aan zoveel dingen twijfelt ga je pfSense uitschakelen, Vyos aan, maar dat werkt dan niet als vanouds en ga je weer verder. En dan van de regen in de drup.

Ik ben back to basic gegaan, heb de opstelling nu werkend dat ik enige tijd (seconden tot minuten) TV kan kijken voordat het mis gaat. Daarmee weten we dus dat de IGMP-Proxy werkt want de multicast stream is zichtbaar iin de wireshark trace.

De wireshark trace uit het plaatje is gemaakt op mijn WAN. Op de XGS-PON UTP port van KPN -> in een 5 ports switch met mirroring -> UTP naar de pfSense router.

En wat je dan ziet is eigenlijk hetzelfde als in de IGMP-Proxy data. Dit is gecaptured vlak voor het glasvezel wordt, mijn uiterste WAN touwtje in mijn woning.



Deze leave komt vanuit mijn pfSense router die geeft op het WAN een leave naar de KPN centrale...



Als ik dan kijk of ik jouw probleem heb met de vele IGMP joins dan is dat niet het geval, komt mede doordat ik een apart TV vlan heb.

thehog schreef op woensdag 18 januari 2023 @ 13:24:
Wat ik bij jou even niet snap is dit:

code:

RECV V3 member report   from 10.238.169.97   to 224.0.0.22
Got leave message from 10.238.169.97 to 224.0.252.126. Starting last member detection.
The found if for 10.238.169.97 was not downstream. Ignoring leave request.

Wie is die 10.238.169.97? Die zie ik bijv niet in je downstream altnet. En igmpproxy negeert hem dan ook.

Dat is het IPTV KPN WAN adres in VLAN 4 aan mijn zijde vermoed ik, net zoals in bovenstaande capture.

En wat ik ook niet precies begrijp is dat je zegt dat je je pfsense achter EB hebt? Wat is een EB?

Experia Box ;-) ik had vanmorgen mijn experiabox geplaatst om te kijken of de TV dan wel bleef doorgaan, en dat is zeker het geval.

Volgende stap is: tegelijk sniffen op het IPTV WAN, sniffen op het IPTV LAN en dan hopelijk ook nog proxy logging meenemen. Ik kom er op terug, ga ff wat bouwen.

[stormfly]

Het is echt heel vreemd @thehog Dit is links het WAN, rechts het LAN (via pfSense OS gesniffed). En wat je ziet is dat wireshark ziet dat van bepaalde IGMP pakketten de checksum niet klopt. En dat wordt vertaald tot een leave op het WAN...

Bij de eerste leave hakkelt het beeld heel kort, vooral het geluid merk je direct. Dat overleeft de STB en bij de 2e keer komt direct de stb-nmc-400 in beeld.

Deel je die mening de tijdstippen staan leesbaar genoteerd. De proxy lijkt dat te vertalen naar een leave, of mogelijk loopt er een timer af waardoor de proxy een leave op het WAN verstuurd omdat op het LAN het pakket niet de juiste checksum heeft.

Morgen even de UniFi switch er tussenuit proberen te halen.

Hypothese:
Sommige, niet alle, IGMP joins vanaf het LAN komen met verkeerde checksum aan, IGMP proxy verwerkt deze niet. Hierdoor ziet de IGMP proxy op het LAN te weinig IGMP joins om het verkeer in stand te houden, maar heeft geen leave gezien op het LAN. De/een timeout wordt gehit en de IGMP proxy op het WAN stuurt naar KPN dat hij geen actieve luisteraars meer heeft.

code:

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:1, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.0.199. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.0.199. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.

Full igmp-proxy log:

code:

Found upstrem IF #0, will assing as upstream Vif 50
adding VIF, Ix 0 Fl 0x0 IP 0x89aaee0a igc1.4, Threshold: 1, Ratelimit: 0
        Network for [igc1.4] : 10.238.168/22
        Network for [igc1.4] : 0/1
        Network for [igc1.4] : 128/1
adding VIF, Ix 1 Fl 0x0 IP 0x011a10ac igc0.26, Threshold: 1, Ratelimit: 0
        Network for [igc0.26] : 172.16.26/24
        Network for [igc0.26] : 172.16.26/24
Got 262144 byte buffer size in 0 iterations
Joining all-routers group 224.0.0.2 on vif 172.16.26.1
Joining group 224.0.0.2 on interface igc0.26
Joining all igmpv3 multicast routers group 224.0.0.22 on vif 172.16.26.1
Joining group 224.0.0.22 on interface igc0.26
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 1 (#0) - delay 10 secs
(Id:1, Time:10)
Created timeout 2 (#1) - delay 21 secs
(Id:1, Time:10)
(Id:2, Time:21)
RECV V3 member report   from 172.16.26.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 172.16.26.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
About to call timeout 1 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 2 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 3 (#0) - delay 10 secs
(Id:3, Time:10)
Created timeout 4 (#1) - delay 21 secs
(Id:3, Time:10)
(Id:4, Time:21)
About to call timeout 3 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 4 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 5 (#0) - delay 10 secs
(Id:5, Time:10)
Created timeout 6 (#1) - delay 115 secs
(Id:5, Time:10)
(Id:6, Time:115)
About to call timeout 5 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 6 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 7 (#0) - delay 10 secs
(Id:7, Time:10)
Created timeout 8 (#1) - delay 115 secs
(Id:7, Time:10)
(Id:8, Time:115)
About to call timeout 7 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
RECV Membership query   from 10.10.10.10     to 224.0.0.1
About to call timeout 8 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 9 (#0) - delay 10 secs
(Id:9, Time:10)
Created timeout 10 (#1) - delay 115 secs
(Id:9, Time:10)
(Id:10, Time:115)
About to call timeout 9 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 10 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 11 (#0) - delay 10 secs
(Id:11, Time:10)
Created timeout 12 (#1) - delay 115 secs
(Id:11, Time:10)
(Id:12, Time:115)
About to call timeout 11 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 12 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 13 (#0) - delay 10 secs
(Id:13, Time:10)
Created timeout 14 (#1) - delay 115 secs
(Id:13, Time:10)
(Id:14, Time:115)
About to call timeout 13 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 14 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 15 (#0) - delay 10 secs
(Id:15, Time:10)
Created timeout 16 (#1) - delay 115 secs
(Id:15, Time:10)
(Id:16, Time:115)
About to call timeout 15 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
The IGMP message was local multicast. Ignoring.
About to call timeout 16 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 17 (#0) - delay 10 secs
(Id:17, Time:10)
Created timeout 18 (#1) - delay 115 secs
(Id:17, Time:10)
(Id:18, Time:115)
About to call timeout 17 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 18 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 19 (#0) - delay 10 secs
(Id:19, Time:10)
Created timeout 20 (#1) - delay 115 secs
(Id:19, Time:10)
(Id:20, Time:115)
About to call timeout 19 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 20 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 21 (#0) - delay 10 secs
(Id:21, Time:10)
Created timeout 22 (#1) - delay 115 secs
(Id:21, Time:10)
(Id:22, Time:115)
About to call timeout 21 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 22 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 23 (#0) - delay 10 secs
(Id:23, Time:10)
Created timeout 24 (#1) - delay 115 secs
(Id:23, Time:10)
(Id:24, Time:115)
About to call timeout 23 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 24 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 25 (#0) - delay 10 secs
(Id:25, Time:10)
Created timeout 26 (#1) - delay 115 secs
(Id:25, Time:10)
(Id:26, Time:115)
About to call timeout 25 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 26 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 27 (#0) - delay 10 secs
(Id:27, Time:10)
Created timeout 28 (#1) - delay 115 secs
(Id:27, Time:10)
(Id:28, Time:115)
About to call timeout 27 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 28 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 29 (#0) - delay 10 secs
(Id:29, Time:10)
Created timeout 30 (#1) - delay 115 secs
(Id:29, Time:10)
(Id:30, Time:115)
About to call timeout 29 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 30 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 31 (#0) - delay 10 secs
(Id:31, Time:10)
Created timeout 32 (#1) - delay 115 secs
(Id:31, Time:10)
(Id:32, Time:115)
About to call timeout 31 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 32 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 33 (#0) - delay 10 secs
(Id:33, Time:10)
Created timeout 34 (#1) - delay 115 secs
(Id:33, Time:10)
(Id:34, Time:115)
About to call timeout 33 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 34 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 35 (#0) - delay 10 secs
(Id:35, Time:10)
Created timeout 36 (#1) - delay 115 secs
(Id:35, Time:10)
(Id:36, Time:115)
The IGMP message was local multicast. Ignoring.
About to call timeout 35 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 36 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 37 (#0) - delay 10 secs
(Id:37, Time:10)
Created timeout 38 (#1) - delay 115 secs
(Id:37, Time:10)
(Id:38, Time:115)
About to call timeout 37 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 38 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 39 (#0) - delay 10 secs
(Id:39, Time:10)
Created timeout 40 (#1) - delay 115 secs
(Id:39, Time:10)
(Id:40, Time:115)
About to call timeout 39 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 40 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 41 (#0) - delay 10 secs
(Id:41, Time:10)
Created timeout 42 (#1) - delay 115 secs
(Id:41, Time:10)
(Id:42, Time:115)
About to call timeout 41 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 42 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 43 (#0) - delay 10 secs
(Id:43, Time:10)
Created timeout 44 (#1) - delay 115 secs
(Id:43, Time:10)
(Id:44, Time:115)
About to call timeout 43 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 44 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 45 (#0) - delay 10 secs
(Id:45, Time:10)
Created timeout 46 (#1) - delay 115 secs
(Id:45, Time:10)
(Id:46, Time:115)
About to call timeout 45 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 46 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 47 (#0) - delay 10 secs
(Id:47, Time:10)
Created timeout 48 (#1) - delay 115 secs
(Id:47, Time:10)
(Id:48, Time:115)
About to call timeout 47 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
RECV Membership query   from 10.10.10.10     to 224.0.0.1
About to call timeout 48 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 49 (#0) - delay 10 secs
(Id:49, Time:10)
Created timeout 50 (#1) - delay 115 secs
(Id:49, Time:10)
(Id:50, Time:115)
About to call timeout 49 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 50 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 51 (#0) - delay 10 secs
(Id:51, Time:10)
Created timeout 52 (#1) - delay 115 secs
(Id:51, Time:10)
(Id:52, Time:115)
About to call timeout 51 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 52 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 53 (#0) - delay 10 secs
(Id:53, Time:10)
Created timeout 54 (#1) - delay 115 secs
(Id:53, Time:10)
(Id:54, Time:115)
About to call timeout 53 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
The IGMP message was local multicast. Ignoring.
About to call timeout 54 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 55 (#0) - delay 10 secs
(Id:55, Time:10)
Created timeout 56 (#1) - delay 115 secs
(Id:55, Time:10)
(Id:56, Time:115)
About to call timeout 55 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 56 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 57 (#0) - delay 10 secs
(Id:57, Time:10)
Created timeout 58 (#1) - delay 115 secs
(Id:57, Time:10)
(Id:58, Time:115)
About to call timeout 57 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 58 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 59 (#0) - delay 10 secs
(Id:59, Time:10)
Created timeout 60 (#1) - delay 115 secs
(Id:59, Time:10)
(Id:60, Time:115)
About to call timeout 59 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 60 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 61 (#0) - delay 10 secs
(Id:61, Time:10)
Created timeout 62 (#1) - delay 115 secs
(Id:61, Time:10)
(Id:62, Time:115)
About to call timeout 61 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 62 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 63 (#0) - delay 10 secs
(Id:63, Time:10)
Created timeout 64 (#1) - delay 115 secs
(Id:63, Time:10)
(Id:64, Time:115)
About to call timeout 63 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 64 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 65 (#0) - delay 10 secs
(Id:65, Time:10)
Created timeout 66 (#1) - delay 115 secs
(Id:65, Time:10)
(Id:66, Time:115)
About to call timeout 65 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 66 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 67 (#0) - delay 10 secs
(Id:67, Time:10)
Created timeout 68 (#1) - delay 115 secs
(Id:67, Time:10)
(Id:68, Time:115)
About to call timeout 67 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 68 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 69 (#0) - delay 10 secs
(Id:69, Time:10)
Created timeout 70 (#1) - delay 115 secs
(Id:69, Time:10)
(Id:70, Time:115)
About to call timeout 69 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 70 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 71 (#0) - delay 10 secs
(Id:71, Time:10)
Created timeout 72 (#1) - delay 115 secs
(Id:71, Time:10)
(Id:72, Time:115)
About to call timeout 71 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 72 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 73 (#0) - delay 10 secs
(Id:73, Time:10)
Created timeout 74 (#1) - delay 115 secs
(Id:73, Time:10)
(Id:74, Time:115)
^Cselect() failure; Errno(4): Interrupted system call
Got a interrupt signal. Exiting.
clean handler called
All routes removed. Routing table is empty.
Shutdown complete....
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root:
[23.01-BETA][[e-mail]]/root: /usr/local/sbin/igmpproxy -d -vvvv /var/etc/igmpproxy.conf
Searching for config file at '/var/etc/igmpproxy.conf'
Config: Quick leave mode enabled.
Config: Got a phyint token.
Config: IF: Config for interface igc1.4.
Config: IF: Got upstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 0.0.0.0/1.
Config: IF: Altnet: Parsed altnet to 0/1.
Config: IF: Got altnet token 128.0.0.0/1.
Config: IF: Altnet: Parsed altnet to 128/1.
IF name : igc1.4
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 1
Allowednet ptr : 2482b000
Config: Got a phyint token.
Config: IF: Config for interface igc0.26.
Config: IF: Got downstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 172.16.26.0/24.
Config: IF: Altnet: Parsed altnet to 172.16.26/24.
IF name : igc0.26
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 2
Allowednet ptr : 2482b020
Config: Got a phyint token.
Config: IF: Config for interface pppoe0.
Config: IF: Got disabled token.
IF name : pppoe0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.60.
Config: IF: Got disabled token.
IF name : igc0.60
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.
Config: IF: Got disabled token.
IF name : igc0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.7.
Config: IF: Got disabled token.
IF name : igc0.7
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.8.
Config: IF: Got disabled token.
IF name : igc0.8
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.2.
Config: IF: Got disabled token.
IF name : igc0.2
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface tun_wg0.
Config: IF: Got disabled token.
IF name : tun_wg0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface ovpnc1.
Config: IF: Got disabled token.
IF name : ovpnc1
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.111.
Config: IF: Got disabled token.
IF name : igc0.111
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igc0.110.
Config: IF: Got disabled token.
IF name : igc0.110
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
buildIfVc: Interface igc0 Addr: 172.16.1.1, Flags: 0xffff8863, Network: 172.16.1/24
buildIfVc: Interface lo0 Addr: 127.0.0.1, Flags: 0xffff8049, Network: 127/8
buildIfVc: Interface lo0 Addr: 10.254.254.254, Flags: 0xffff8049, Network: 10/8
buildIfVc: Interface igc0.2 Addr: 172.16.2.1, Flags: 0xffff8843, Network: 172.16.2/24
buildIfVc: Interface igc0.7 Addr: 172.16.7.1, Flags: 0xffff8843, Network: 172.16.7/24
buildIfVc: Interface igc0.8 Addr: 172.16.8.1, Flags: 0xffff8843, Network: 172.16.8/24
buildIfVc: Interface igc0.60 Addr: 172.16.6.1, Flags: 0xffff8843, Network: 172.16.6/24
buildIfVc: Interface igc0.110 Addr: 10.110.1.1, Flags: 0xffff8843, Network: 10.110.1/24
buildIfVc: Interface igc0.111 Addr: 10.110.2.1, Flags: 0xffff8843, Network: 10.110.2/24
buildIfVc: Interface igc1.4 Addr: 10.238.170.137, Flags: 0xffff8843, Network: 10.238.168/22
buildIfVc: Interface igc0.26 Addr: 172.16.26.1, Flags: 0xffff8843, Network: 172.16.26/24
buildIfVc: Interface ovpnc1 Addr: 10.122.154.36, Flags: 0xffff8043, Network: 10.122.154/23
buildIfVc: Interface tailscale0 Addr: 100.81.208.3, Flags: 0xffff8043, Network: 100.81.208.3/32
buildIfVc: Interface tun_wg0 Addr: 10.10.10.254, Flags: 0xffff80c1, Network: 10.10.10/24
buildIfVc: Interface pppoe0 Addr: 86.80.171.118, Flags: 0xffff88d1, Network: 86.80.171.118/32
Found config for igc0
Found config for igc0.2
Found config for igc0.7
Found config for igc0.8
Found config for igc0.60
Found config for igc0.110
Found config for igc0.111
Found config for igc1.4
Found config for igc0.26
Found config for ovpnc1
Found config for tun_wg0
Found config for pppoe0
Found upstrem IF #0, will assing as upstream Vif 50
adding VIF, Ix 0 Fl 0x0 IP 0x89aaee0a igc1.4, Threshold: 1, Ratelimit: 0
        Network for [igc1.4] : 10.238.168/22
        Network for [igc1.4] : 0/1
        Network for [igc1.4] : 128/1
adding VIF, Ix 1 Fl 0x0 IP 0x011a10ac igc0.26, Threshold: 1, Ratelimit: 0
        Network for [igc0.26] : 172.16.26/24
        Network for [igc0.26] : 172.16.26/24
Got 262144 byte buffer size in 0 iterations
Joining all-routers group 224.0.0.2 on vif 172.16.26.1
Joining group 224.0.0.2 on interface igc0.26
Joining all igmpv3 multicast routers group 224.0.0.22 on vif 172.16.26.1
Joining group 224.0.0.22 on interface igc0.26
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 1 (#0) - delay 10 secs
(Id:1, Time:10)
Created timeout 2 (#1) - delay 21 secs
(Id:1, Time:10)
(Id:2, Time:21)
RECV V3 member report   from 172.16.26.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 172.16.26.1     to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was from myself. Ignoring.
RECV Membership query   from 10.10.10.10     to 224.0.0.1
About to call timeout 1 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 2 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 3 (#0) - delay 10 secs
(Id:3, Time:10)
Created timeout 4 (#1) - delay 21 secs
(Id:3, Time:10)
(Id:4, Time:21)
About to call timeout 3 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 4 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 5 (#0) - delay 10 secs
(Id:5, Time:10)
Created timeout 6 (#1) - delay 115 secs
(Id:5, Time:10)
(Id:6, Time:115)
The IGMP message was local multicast. Ignoring.
About to call timeout 5 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 6 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 7 (#0) - delay 10 secs
(Id:7, Time:10)
Created timeout 8 (#1) - delay 115 secs
(Id:7, Time:10)
(Id:8, Time:115)
About to call timeout 7 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
RECV Leave message      from 172.16.26.11    to 224.0.0.2
Got leave message from 172.16.26.11 to 224.0.251.126. Starting last member detection.
Created timeout 9 (#0) - delay 10 secs
(Id:9, Time:10)
(Id:8, Time:105)
RECV Leave message      from 172.16.26.11    to 224.0.0.2
Got leave message from 172.16.26.11 to 224.0.0.199. Starting last member detection.
Created timeout 10 (#1) - delay 2 secs
(Id:9, Time:8)
(Id:10, Time:2)
(Id:8, Time:103)
RECV V2 member report   from 172.16.26.11    to 224.0.0.199
Should insert group 224.0.0.199 (from: 172.16.26.11) to route table. Vif Ix : 1
No existing route for 224.0.0.199. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 224.0.0.199 on VIF #1
Joining group 224.0.0.199 upstream on IF address 10.238.170.137
Joining group 224.0.0.199 on interface igc1.4

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
About to call timeout 9 (#0)
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
No existing route for 224.0.251.125. Create new.
Found existing routes. Find insert location.
Inserting at beginning, before route 224.0.0.199
Inserted route table entry for 224.0.251.125 on VIF #1
Joining group 224.0.251.125 upstream on IF address 10.238.170.137
Joining group 224.0.251.125 on interface igc1.4

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.251.125, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
About to call timeout 10 (#0)
Route activate request from 217.166.225.125 to 224.0.251.125 on VIF[0]
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0

Current routing table (Activate Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from 172.16.26.11    to 224.0.0.199
Should insert group 224.0.0.199 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.0.199 on VIF #1

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 172.16.26.11    to 224.0.0.199
Should insert group 224.0.0.199 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.0.199 on VIF #1

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.251.125 on VIF #1
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 8 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 11 (#0) - delay 10 secs
(Id:11, Time:10)
Created timeout 12 (#1) - delay 115 secs
(Id:11, Time:10)
(Id:12, Time:115)
About to call timeout 11 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 12 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 13 (#0) - delay 10 secs
(Id:13, Time:10)
Created timeout 14 (#1) - delay 115 secs
(Id:13, Time:10)
(Id:14, Time:115)
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.251.125 on VIF #1
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 13 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
#1: Dst: 224.0.0.199, Age:1, St: I, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 14 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 15 (#0) - delay 10 secs
(Id:15, Time:10)
Created timeout 16 (#1) - delay 115 secs
(Id:15, Time:10)
(Id:16, Time:115)
About to call timeout 15 (#0)
Aging routes in table.
Removing group 224.0.0.199. Died of old age.
Removed route entry for 224.0.0.199 from table.
Leaving group 224.0.0.199 upstream on IF address 10.238.170.137
Leaving group 224.0.0.199 on interface igc1.4

Current routing table (Remove route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:1, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:1, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.0.199. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.0.199. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
About to call timeout 16 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 17 (#0) - delay 10 secs
(Id:17, Time:10)
Created timeout 18 (#1) - delay 115 secs
(Id:17, Time:10)
(Id:18, Time:115)
About to call timeout 17 (#0)
Aging routes in table.
Removing group 224.0.251.125. Died of old age.
Removed route entry for 224.0.251.125 from table.
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Removing MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0
Leaving group 224.0.251.125 upstream on IF address 10.238.170.137
Leaving group 224.0.251.125 on interface igc1.4

Current routing table (Remove route):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
Route activate request from 217.166.225.125 to 224.0.251.125 on VIF[0]
No table entry for 224.0.251.125 [From: 217.166.225.125]. Inserting route.
No existing route for 224.0.251.125. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 224.0.251.125 on VIF #-1
No downstream listeners for group 224.0.251.125. No join sent.

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.251.125, Age:2, St: I, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------

Current routing table (Activate Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.251.125. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.251.125. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
RECV Leave message      from 172.16.26.11    to 224.0.0.2
Got leave message from 172.16.26.11 to 224.0.251.125. Starting last member detection.
Interface id 1 is in group $d
Created timeout 19 (#0) - delay 10 secs
(Id:19, Time:10)
(Id:18, Time:104)
About to call timeout 19 (#0)
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.251.125 on VIF #1
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0
Joining group 224.0.251.125 upstream on IF address 10.238.170.137
Joining group 224.0.251.125 on interface igc1.4

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.251.125 on VIF #1
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from 172.16.26.11    to 224.0.251.125
Should insert group 224.0.251.125 (from: 172.16.26.11) to route table. Vif Ix : 1
Updated route entry for 224.0.251.125 on VIF #1
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Adding MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 18 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 20 (#0) - delay 10 secs
(Id:20, Time:10)
Created timeout 21 (#1) - delay 115 secs
(Id:20, Time:10)
(Id:21, Time:115)
About to call timeout 20 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 21 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 22 (#0) - delay 10 secs
(Id:22, Time:10)
Created timeout 23 (#1) - delay 115 secs
(Id:22, Time:10)
(Id:23, Time:115)
About to call timeout 22 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:1, St: A, OutVifs: 0x00000002, dHosts: yes
-----------------------------------------------------
About to call timeout 23 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 24 (#0) - delay 10 secs
(Id:24, Time:10)
Created timeout 25 (#1) - delay 115 secs
(Id:24, Time:10)
(Id:25, Time:115)
About to call timeout 24 (#0)
Aging routes in table.
Removing group 224.0.251.125. Died of old age.
Removed route entry for 224.0.251.125 from table.
Vif bits : 0x00000002
Setting TTL for Vif 1 to 1
Removing MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0
Leaving group 224.0.251.125 upstream on IF address 10.238.170.137
Leaving group 224.0.251.125 on interface igc1.4

Current routing table (Remove route):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
Route activate request from 217.166.225.125 to 224.0.251.125 on VIF[0]
No table entry for 224.0.251.125 [From: 217.166.225.125]. Inserting route.
No existing route for 224.0.251.125. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 224.0.251.125 on VIF #-1
No downstream listeners for group 224.0.251.125. No join sent.

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.251.125, Age:2, St: I, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------

Current routing table (Activate Route):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:2, St: A, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.251.125. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
RECV V3 member report   from 10.238.170.137  to 224.0.0.22
Got leave message from 10.238.170.137 to 224.0.251.125. Starting last member detection.
The found if for 10.238.170.137 was not downstream. Ignoring leave request.
About to call timeout 25 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 26 (#0) - delay 10 secs
(Id:26, Time:10)
Created timeout 27 (#1) - delay 115 secs
(Id:26, Time:10)
(Id:27, Time:115)
About to call timeout 26 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.225.125, Dst: 224.0.251.125, Age:1, St: A, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------
About to call timeout 27 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 28 (#0) - delay 10 secs
(Id:28, Time:10)
Created timeout 29 (#1) - delay 115 secs
(Id:28, Time:10)
(Id:29, Time:115)
About to call timeout 28 (#0)
Aging routes in table.
Removing group 224.0.251.125. Died of old age.
Removed route entry for 224.0.251.125 from table.
Vif bits : 0x00000000
Removing MFC: 217.166.225.125 -> 224.0.251.125, InpVIf: 0
MRT_DEL_MFC; Errno(49): Can't assign requested address

Current routing table (Remove route):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------

Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 29 (#0)
SENT Membership query   from 172.16.26.1     to 224.0.0.1
Sent membership query from 172.16.26.1 to 224.0.0.1. Delay: 10
Created timeout 30 (#0) - delay 10 secs
(Id:30, Time:10)
Created timeout 31 (#1) - delay 115 secs
(Id:30, Time:10)
(Id:31, Time:115)
^Cselect() failure; Errno(4): Interrupted system call
Got a interrupt signal. Exiting.
clean handler called
All routes removed. Routing table is empty.
Shutdown complete....
[23.01-BETA][[e-mail]]/root:

[ Voor 112% gewijzigd door stormfly op 18-01-2023 23:02 ]

[stormfly]

ik222 schreef op woensdag 18 januari 2023 @ 22:58:
@stormfly Kloppen jou firewall regels wel? En dan specifiek het toestaan van IGMP (options enabled) van IPTV LAN naar IPTV WAN en ook omgekeerd van IPTV WAN naar IPTV LAN?

Ik zie namelijk een router die queried maar geen antwoord ziet en ook membership reports van je STB’s die je router niet bereiken of daar gedropt worden. Reden daarvan is meestal ofwel een te strak afgestelde firewall of anders iets op laag 2 niveau (je switch).

Ja die deel ik graag hier onder voor een 4 ogen check, als je een blik wilt werpen? Dank voor je hulp.

In mijn beleving heb ik ze binnen de multicast begrippen op any any gezet.

Ik denk dat er mogelijk nog meer speelt, heb je die rode checksum banner gezien in het wireshark screenshot? Dat zou ook mogelijk uit de UniFi switch kunnen komen, dat moet ik morgen even bekijken.

IPTV WAN


IPTV LAN


Proxy

[stormfly]

@thehog @ik222

Dit is een capture genomen op twee switches, switch 1 direct achter de STB & switch 2 direct in het WAN.

De pakketten zijn op 1 MacBook tegelijk gesniffed, waardoor het qua tijdslijn netjes doorloopt.

172.16.26.11 is de STB
10.238.170.137 is vlan4 WAN




Dit is volgens mij het stukje waar het mis gaat, weten jullie wat de reports zijn naar 224.0.0.1? Zijn dat de reports waarbij pfSense vraag wie er nog lid is van de groep?




Packet 53580 vraagt de STB nog om een stream 224.0.251.125
Packet 71526 vraagt pfSense nog wie er lid is van de groep, alleen heeft deze een defecte checksum.
Packet 85556 besluit de IGMP proxy dat er geen luisteraars meer zijn en stuurt een leave naar het WAN

Volgende stap even een subnet maken en direct op pfSense prikken en nogmaals testen zonder UniFi.



In IGMP V2; General query is used to learn which groups have members on an attached network(type:0x11, group address:0.0.0.0). Group-specific query is used to learn if particular group has any members on an attached network.(type:0x11, group address:group address that being queried)

IGMPv2 Membership Reports are generated by IGMPv2 hosts when they first join a multicast group, and are sent in response to IGMPv2 Membership Queries.

[ Voor 10% gewijzigd door stormfly op 19-01-2023 11:01 ]

[stormfly]

ik222 schreef op donderdag 19 januari 2023 @ 11:37:
In elk L2 multicast netwerk heb je een querier (in je thuisnetwerk is dat eigenlijk altijd de IGMP proxy) die op het query interval een query stuurt. Dat is normaal gedrag en een mechanisme om te voorkomen dat groepen onnodig open blijven staan in het geval er leave messages gemist zijn. Als er niemand antwoord op die queries krijg de groep dan ook een timeout en stopt, dat is exact wat je hier ziet gebeuren.

Het lijkt er heel sterk op dat het in dit geval mis gaat in de switch (daar raken pakketjes corrupt / verdwijnen), dus die er tussenuit halen is de logische volgende stap.

Dit is zonder switch, direct een UTP in port 3 van de TopTon N5105 Intel i-226v NIC. Gaat net zo fout als met switch...

Nadeel is dat je niet snel even kunt downgraden met pfSense, dan moet je echt terug naar een re-install lees ik. En dan loop je tegen het issue aan dat de drivers nog niet in de 1th step install zitten, waardoor je niet goed meer op pfSense plus kunt komen, qua upgrades. Want geen nic-drivers = geen inline upgrade

thehog schreef op donderdag 19 januari 2023 @ 11:13:
Ja nu zie je wel de STB igmp join. Die kwam gisteren niet aan bij pfsense. Ben benieuwd hoe het gaat als je de unify switch er tussen uit haalt.

224.0.0.1 is een algemene group request adres. Daar hoort de STB wel op te reageren (mits checksum goed is inderdaad). Maar de vraag is waarom igmpproxy uberhaupt de vraag stuurt want een paar seconden er voor zou de join nog verstuurd zijn.

Ik denk dat de joins gisteren niet helemaal goed geknipt waren door mij, deze view op de MacBook is beter.

Weet jij de timing waarna ze langs elkaar heen praten, dat lijkt mij dat het groter moet zijn dan een paar seconden...

Zijn alle pakketjes van de pfsense slecht qua checksum of alleen enkele?

Ik denk alleen de IGMP pakketten de eerste 3 zijn gewoon goed. Alles in het geel is corrupt...

[stormfly]

Ga nu even het KPN modem aansluiten en daar eens een capture nemen of mijn metingen goed zijn, mogelijk maakt de 5 port snif-switch het pakket corrupt.

EDIT: dit is met het KPN modem. De IGMP Membership Query, General worden direct door de client beantwoord. En het pakket is niet corrupt wat naar 224.0.0.1 wordt verstuurd.

Arghhh dit is nu in kaart gebracht. Wat ik nog niet doorgrond is waarom het dan via VYOS (wat weken lang goed draaide) nu ook mis gaat. Moet nu even weg maar dat ga ik denk ik ook nog even sniffen en in kaart brengen. VLAN4 in LAN switch -> koppelt uit op proxmox VM WAN -> proxmox VM LAN -> STB. Proxy draait dan ook binnen VYOS.

[ Voor 73% gewijzigd door stormfly op 19-01-2023 12:28 ]

[stormfly]

thehog schreef op donderdag 19 januari 2023 @ 13:35:
[...]

Voor proxmox wil je snooping wel aan hebben staan. De vrituele bridge (vmbr0 bijvoorbeeld) gaat anders de multicast stream ook naar de vm's sturen die het niet nodig hebben (net als een echte switch dus).
multicast router niet, want dat is gelijk aan querier.

Blijkbaar heeft het toch een grote rol bij mijn proxmox installatie, zonder snooping uit te schakelen gaat vyos geen enkele stream starten omdat de IGMP joins niet aankomen bij de Vyos VM. Gelukkig doet deze het nu weer en zit mijn vrouw fijn tv te kijken.

VYOS = OK -> ook via de UniFi switch

Aangaande pfSense het volgende; daar ga ik morgen nog even goed naar kijken. Vandaag met een fris hoofd VYOS werkend gekregen, dat moet voor pfSense ook mogelijk zijn. Je triggerde mij wel met de volgende opmerking.

thehog schreef op donderdag 19 januari 2023 @ 12:40:
Doe echt nog even een tcpdump op je iptv-lan interface van pfsense (ipv via de switch mirror port). Wees er zeker van dat de igmp verzoeken van de STB daar aankomen (daar heb ik tot nu toe nog twijfels over namelijk). Igmpproxy kan niet z'n werk doen zonder.

Ik moet daar morgen nog even goed induiken, heb het meer gehad dat pfSense een reboot nodig had na veel hobby werk. Dat doe ik morgen even, ik ga dan toch weer de STB capture switch ertussen plaatsen. Had het net ff netjes gemaakt omdat het met VYOS nu stabiel is. Want wat jij hierboven zegt lijkt wel te kloppen, bijna bijzonder te noemen hoe scherp jij bent

Dit is van net, op pfSense gecaptured op de LAN interface, zappend over 3 kanalen.

edit: en verzeker je dat je met "-s 0" de packet capture doet. Anders kan tcpdump de checksum niet berekenen als de lengte groter is dan standaard.

Yes doe ik via de GUI, captures zijn te groot om lekker via de CLI te doen, de download knop is gemakkelijker.




Je hebt gelijk er is geen screenshot te vinden waarbij pfSense laat zien dat hij een IGMP join voor een stream ziet. Er zijn wel veel screenshots waarin het op het LAN zichtbaar is dmv het capture switch tussen de STB kabel zoals in onderstaande post.

Goed punt ik ga daar morgen nog even goed naar kijken.

stormfly schreef op donderdag 19 januari 2023 @ 10:58:
@thehog @ik222

Dit is een capture genomen op twee switches, switch 1 direct achter de STB & switch 2 direct in het WAN.

De pakketten zijn op 1 MacBook tegelijk gesniffed, waardoor het qua tijdslijn netjes doorloopt.

172.16.26.11 is de STB
10.238.170.137 is vlan4 WAN

[Afbeelding]


Dit is volgens mij het stukje waar het mis gaat, weten jullie wat de reports zijn naar 224.0.0.1? Zijn dat de reports waarbij pfSense vraag wie er nog lid is van de groep?

[Afbeelding]


Packet 53580 vraagt de STB nog om een stream 224.0.251.125
Packet 71526 vraagt pfSense nog wie er lid is van de groep, alleen heeft deze een defecte checksum.
Packet 85556 besluit de IGMP proxy dat er geen luisteraars meer zijn en stuurt een leave naar het WAN

Volgende stap even een subnet maken en direct op pfSense prikken en nogmaals testen zonder UniFi.

[Afbeelding]

[stormfly]

@thehog feit is dat VYOS via UniFi goed werkt, hou dat in gedachten bij de volgende screenshots ;-)

Dit zijn capture acties op het LAN omdat jij terecht een vermoeden uitsprak over het niet aankomen van IGMP joins op pfSense. Dat is waar voor de vlan tagged meervoudige LAN poort daar komen 0,0 joins aan waardoor multicast niet op gang komt, de joins worden zeker de UniFi switch ingestuurd.
Het is niet waar voor de unieke losse LAN port op pfSense, daar komt de multicast stream wel op gang maar gaat stotteren. Heb de rulesets gekopieerd vanaf de werkende unieke LAN port naar de vlan tagged LAN poort, daar kan geen foutje in zitten voor wat betreft zichtbare firewalling.

Heel bijzonder want juist deze setup werkte weken lang goed, nu is 23.01 nog beta met een RC in de komende dagen. Maar omdat pfSense zo weinig update hoop ik dat ik nog wat aandacht kan krijgen voor deze uitdaging het lijkt wel alsof IGMP snooping aanstaat die in de kernel van pfSense.

Ga het nog even testen in een ander vlan, gisteren werkte de stream dan niet. Nu gerichter kijken of die joins aankomen.





Kijken we naar de pfSense directe kabel op een vrije NIC dan gaat het concept wel goed, stream komt to stand en hij schakelt netjes over op MC. Als hij direct gekoppeld is dan lijkt het meer een forwarding issue dan een IGMP issue. De stream wordt wat stroperiger en dan stuurt de STB een leave waarna hij hem opnieuw opbouwt, het concept met de IGMP proxy werkt hier goed. IGMP joins komen aan op de LAN port bij pfSense.

[TweedeHandsPCs]

stormfly schreef op vrijdag 3 februari 2023 @ 18:36:
[...]


Hoe ziet je igmp proxy eruit?

Die proxy is niet even stabiel, ook niet in versie 23.x

Het is inderdaad verstandig onderin je FW rules een allow all zetten, zodat je ook NTP en DNS kunt doen. Ik hou mijn antwoorden even hier.

[Boomerang]

Ik heb een Intel 5105 mini PC met Proxmox VE (laatste stable) en daarop een OPNSense (23.1.3-amd64) VM draaien. Drie van de vier NICs heb ik via PCI passthrough doorgezet naar de OPNSense VM. NIC0 = WAN (direct verbonden met de FTU), NIC1 = LAN, NIC2 = direct verbonden met STB. Ik probeer routed IPTV via KPN werkende te krijgen, maar tot nu toe zonder succes. Internet over IPv4 en IPv6 werkt prima. De configuratie heb ik vrijwel volledig overgenomen van https://helpdesk.nolim-it...lasvezel-IPv6-Routed-IPTV.

Op de WAN_IPTV interface krijg ik netjes een IP-adres via DHCP van KPN over VLAN 4. De howto heeft het over een aparte gateway configureren voor WAN_IPTV, maar die blijft vervolgens inactief, waarschijnlijk omdat KPN geen gateway meer meestuurt:



Ik heb daarom een NAT rule toegevoegd op de WAN_IPTV interface:



Tijdens het opstarten van de STB ziet de routes tabel er zo uit (vlan02 is alleen de naam in OPNsense, maar is VLANid 4):



Als ik nu mijn STB (ZTE ZXV8001) opstart, blijft het bootproces hangen op 85% (configuratie geactiveerd). Daarna treedt de foutcode 561 op ("ophalen instellingen mislukt").

Gisteren weer even de ExperiaBox v10 verbonden met de FTU en de STB. Opstarten gaat dan wel goed. Het vreemde is dat als ik de STB ingeschakeld laat en vervolgens de FTU weer op de NIC1 inprik de STB vervolgens wel blijft werken. Zappen werkt soepel. Alleen het terugkijken van programma's is dan niet mogelijk, omdat er geen verbinding kan worden gemaakt met de server. Dat lijkt er op te duiden dat de STB geen verbinding met internet kan maken.

Iemand enig idee wat ik nog kan proberen om deze setup werkende te krijgen?

[Boomerang]

thehog schreef op zondag 12 maart 2023 @ 14:12:
Heb je wel een NAT van je STB vlan naar het normale internet? En heb je alle info in de opening post gelezen van deze topic?

Scherp gezien, bedankt! De openingspost heb ik gezien, maar deze had ik over het hoofd gezien.

Ik heb de NAT-rule net aangemaakt, klopt dit zo?



De STB gaat nu wel door het opstartproces heen, maar hangt vervolgens op "Verbinding met zender is verbroken". Ik kan wel programma's terugkijken, dus internet werkt. Volgens een andere post in dit topic kon dat liggen aan firewall regels voor IGMP (allow-options moet aanstaan). Die heb ik net allemaal gecheckt en staan aan voor deze regels op LAN_IPTV en WAN_IPTV:

LAN_IPTV rules:


WAN_IPTV rules:


En ter aanvulling nog de IGMP proxy settings (192.168.250.0/24 betreft mijn LAN_IPTV). De igmp proxy draait uiteraard gewoon.

[stormfly]

Boomerang schreef op zondag 12 maart 2023 @ 15:03:
[...]


Scherp gezien, bedankt! De openingspost heb ik gezien, maar deze had ik over het hoofd gezien.

Ik heb de NAT-rule net aangemaakt, klopt dit zo?

[Afbeelding]

De STB gaat nu wel door het opstartproces heen, maar hangt vervolgens op "Verbinding met zender is verbroken". Ik kan wel programma's terugkijken, dus internet werkt. Volgens een andere post in dit topic kon dat liggen aan firewall regels voor IGMP (allow-options moet aanstaan). Die heb ik net allemaal gecheckt en staan aan voor deze regels op LAN_IPTV en WAN_IPTV:

LAN_IPTV rules:
[Afbeelding]

WAN_IPTV rules:
[Afbeelding]

En ter aanvulling nog de IGMP proxy settings (192.168.250.0/24 betreft mijn LAN_IPTV). De igmp proxy draait uiteraard gewoon.

[Afbeelding]

Vergelijk eens met jouw NAT rules, de destination ontbreekt bij jou.

[stormfly]

Boomerang schreef op zondag 12 maart 2023 @ 17:07:
[...]


Dank je, net aangepast, maar helaas nog steeds dezelfde problemen.

Heb je de specifieke route in je route tabel staan?

[ Voor 41% gewijzigd door stormfly op 12-03-2023 20:58 ]

[Boomerang]

Ik dacht eerst dat ik het probleem had gevonden... Na deze aanpassing werkt de stream na het zappen veel langer (30 sec tot paar minuten). Daarna zie ik nog steeds de stb-nmc-400 code... Erg vreemd.

Als NAT-rules had ik eerst:


Daar heb ik nu van gemaakt:

stormfly schreef op zondag 12 maart 2023 @ 20:57:
[...]


Heb je de specifieke route in je route tabel staan?

[Afbeelding]

Die heb ik er inderdaad in staan.

filibuster schreef op maandag 13 maart 2023 @ 21:23:
[...]


Weet je zeker dat deze IGMP proxy setting goed is? Voor KPN heb ik bij upstream staan: 217.166.128.0/17, 213.75.167.0/24

Volgensmij bevat de door mij opgegeven ranges ook deze range.

thehog schreef op zondag 12 maart 2023 @ 17:36:
Dat zou ook niks moeten uitmaken. Alles of een beperkte zet.

Ik denk dat je even moet meekijken (tcpdump) op iptv_wan terwijl je aan het zappen bent.
De STB moet daar (uitgaand) een verzoek sturen via unicast (naar die 213.75 adressen) waarna vervolgens voor een 1-2 seconden lang een unicast stream op wordt gestart. Tegenlijk zal de STB via igmproxy een group join doen voor een multicast groep, die komt na 1-2seconden er bij waarna de STB overstapt op deze multicast stream. De unicast stream zal dan stoppen.

Als niet eens de eerste unicast opstart lijkt het er op dat de STB dus niet hiervoor naar je iptv_wan gaat. Check nog een keer of die route er echt wel in staat.

Even met tcpdump gekeken en na het zappen zie ik op de iptv_wan interface:

code:

20:39:17.720081 IP 10.138.241.117 > igmp.mcast.net: igmp v3 report, 2 group record(s)
20:39:19.120423 IP 10.138.241.117 > igmp.mcast.net: igmp v3 report, 3 group record(s)

En op de LAN 2 interface die naar de STB gaat:

code:

20:40:33.074873 IP 192.168.250.100 > all-routers.mcast.net: igmp leave 224.0.251.137

Ik heb ook nog even zitten neuzen in de states tabel en daar zie ik de volgende entries (mijn externe IP geblurred):



Er lijkt dus nog iets mis te gaan met de NAT-rules...

[ Voor 157% gewijzigd door Boomerang op 13-03-2023 23:05 ]

[stormfly]

Philip J. Dijkstra schreef op dinsdag 4 april 2023 @ 08:00:
Ik ben overgestapt van Ziggo naar KPN Glasvezel.
Tot nu toe heb ik met een PfSense router gewerkt en ik lees dat het mogelijk moet zijn om de NTU rechtstreeks in die router te steken en de ExperiaBox niet aan te raken.
Alle artikelen verwijzen echter naar deze originele post 'https://venxir.tweakblogs.net/blog/12507/kpn-glasvezel-via-pfsense' en die werkt niet meer.

Overal komen mensen met diagnose en oplossingen voor IPTV maar die heb ik niet nodig want ik heb slechts Internet omdat wij alles via streaming diensten (Nvidia Shield) kijken.
Op geen enkele plek kan ik tot nu toe vinden hoe ik de WAN en LAN interface moet configureren voor mijn internet-only situatie.

Ik kan vinden dat ik de WAN interface op PPPoE moet zetten maar vervolgens zijn er tegenstrijdige berichten over de username en passw: de een zegt dat daar je MAC-adres@Internet moet staan, de ander zegt dat het Internet/Internet moet zijn.
Moet ik ook met VLAN's aan de slag als ik alleen internet wil configuren?
Kan mijn LAN interface blijven staan zoals deze nu voor Ziggo is geconfigureerd (DHCP) ?

Scrollen door de 6 pagina's van deze post en het KPN forum heeft helaas ook geen duidelijkheid gebracht dus ik hoop dat iemand hier mij uit de brand kan helpen.

Alstu

[stormfly]

Blijkbaar is er ook een server in een RFC1918 segment waar een VIP520x naar toe wil verbinden. Heb dit verkeer zojuist toegelaten. Het werd geblokkeerd door mijn LAN block rule.

[stormfly]

R0GGER schreef op zaterdag 24 juni 2023 @ 12:43:
Het probleem lijkt erg veel op deze...
https://forum.netgate.com...ing-under-2-5-0-release/2

Het probleem doet zich namelijk alleen voor als de STB geüpdatet wordt en soms wanneer hij in standby staat.

Watchdog herstart e.a. voor je zonder tussenkomst van gebruikers.