Toon posts:

OPNsense & pfSense KPN/Telfort IPTV how-to

Pagina: 1 ... 5 ... 9 Laatste
Acties:

Onderwerpen

KPN Iptv Pfsense

dinsdag 3 januari 2023 20:20

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Nu de fritzbox weer aangesloten maar z'n WAN poort via twee interfaces van de proxmox host (in een bridge met vlan capable enabled). En ook de LAN poort van de fritzbox zit aangesloten aan deze proxmox host (de LAN bridge uiteraard). En dat gaat gewoon goed. Wou hiermee aantonen dat het aan proxmox/linux bridging/netwerkkaart in host zou liggen maar dat is het dus ook niet.

Volgende stap zal zijn om pfsense/opnsense native op de host te installeren en kijken of dat wel goed gaat.

dinsdag 3 januari 2023 21:28

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
[b]thehog schreef op dinsdag 3 januari 2023 @ 17:14:[/b

Wie weet welke pakketje ik zou moeten zien die er moet voor zorgen dat het beeld blijft lopen? Ik zie op de IPTV-WAN in tcpdump met igmp filter niks anders in de periode dat het werkt en dat het niet werkt. En ook niet op LAN.
Je schrijft heel veel maar deelt daarin weinig informatie waarmee we je kunnen helpen. De guide van de eerste posts werkt nog steeds. Ik ben vorige maand overgestapt van een NUC met 1 nic met af en toe stotterend beeld na het zappen. Naar een AliExpress Topton met 2 nics via IOMMU passtrough in Proxmox. Super stabiel, geen glitches meer. Los van Intel N5105 issues reboots van vms onder Proxmox.


IGMP proxy stoppen in de gui en starten op de CLI wat zie je dan in de cli?

code:
1

/usr/local/sbin/igmpproxy -d -vvvv /var/etc/igmpproxy.conf



Zoiets:
code:
1
2

The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].
The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].

dinsdag 3 januari 2023 23:18

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

@stormfly Ik heb ook een topton van Aliexpress. Dus als jij het werkend kan maken dan geeft het mij ook hoop!
Het lijk steeds voor lange tijd te werken. Heel erg hoopvol. Maar dan ineens na lange tijd valt het toch weer weg en zodra het een keer mis gaat, gaat het daarna veel sneller mis (na een paar minuten).
Ik heb het halverweg de avond omgebouwd naar (2x NIC) passthrough (IOMMU denk ik nog niet, moet ik nog over lezen) en dat lijkt nu wel stabiel.

Ik heb de hele dag al naar de extra verbose logging van igmpproxy gekeken maar ik zie niks wat mij opvalt. Is groep 224.3.2.6 belangrijk naast de stream voor het kanaal zelf? Die zie ik namelijk inderdaad niet altijd voorbij komen.

edit: zojuist IOMMU ook maar aangezet (gek, ik kon al pci passthrough doen zonder dit aan te zetten)

[ Voor 8% gewijzigd door thehog op 04-01-2023 09:41 ]

woensdag 4 januari 2023 00:26

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Op het moment dat het beeld vast loopt met de bekende foutmelding (stb-nmc-400) zie ik bijv. gewoon een active tabel in igmpproxy:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Src0: 213.75.167.58, Dst: 224.3.2.6, Age:2, St: A, OutVifs: 0x00000001, dHosts: yes
#2: Dst: 224.0.0.7, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#3: Dst: 225.0.0.9, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#4: Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#5: Src0: 217.166.225.126, Dst: 224.0.251.126, Age:2, St: A, OutVifs: 0x00000001, dHosts: yes
#6: Dst: 224.0.1.187, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#7: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#8: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
#9: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#10: Dst: 239.255.255.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#11: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------


ook verstuurd hij netjes de igmp update naar IPTV-WAN:
code:
1
2

23:22:22.455939 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 120, options (RA))
    10.227.237.182 > 224.0.0.22: igmp v3 report, 11 group record(s) [gaddr 225.0.0.9 is_ex { }] [gaddr 224.0.1.187 is_ex { }] [gaddr 224.0.2.3 is_ex { }] [gaddr 239.255.255.251 is_ex { }] [gaddr 224.0.0.7 is_ex { }] [gaddr 224.3.2.6 is_ex { }] [gaddr 224.0.251.126 is_ex { }] [gaddr 224.0.0.199 is_ex { }] [gaddr 224.0.0.252 is_ex { }] [gaddr 239.255.3.22 is_ex { }] [gaddr 224.0.0.251 is_ex { }]



toch stopt de multicast stream ineens met binnenkomen en is een restart van igmproxy of een kanaal swap nodig om weer verder te gaan...

Heeft vanavond weer een hele tijd gewerkt todat ik die IOMMU had aangezet. Sinds dien is het weer onbetrouwbaar (ook na weer uitzetten). Er is geen touw aan te knopen wanneer het goed gaat en wanneer mis.

woensdag 4 januari 2023 10:28

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 00:26:
Op het moment dat het beeld vast loopt met de bekende foutmelding (stb-nmc-400) zie ik bijv. gewoon een active tabel in igmpproxy:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Src0: 213.75.167.58, Dst: 224.3.2.6, Age:2, St: A, OutVifs: 0x00000001, dHosts: yes
#2: Dst: 224.0.0.7, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#3: Dst: 225.0.0.9, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#4: Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#5: Src0: 217.166.225.126, Dst: 224.0.251.126, Age:2, St: A, OutVifs: 0x00000001, dHosts: yes
#6: Dst: 224.0.1.187, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#7: Dst: 224.0.0.199, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#8: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
#9: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#10: Dst: 239.255.255.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#11: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------


ook verstuurd hij netjes de igmp update naar IPTV-WAN:
code:
1
2

23:22:22.455939 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 120, options (RA))
    10.227.237.182 > 224.0.0.22: igmp v3 report, 11 group record(s) [gaddr 225.0.0.9 is_ex { }] [gaddr 224.0.1.187 is_ex { }] [gaddr 224.0.2.3 is_ex { }] [gaddr 239.255.255.251 is_ex { }] [gaddr 224.0.0.7 is_ex { }] [gaddr 224.3.2.6 is_ex { }] [gaddr 224.0.251.126 is_ex { }] [gaddr 224.0.0.199 is_ex { }] [gaddr 224.0.0.252 is_ex { }] [gaddr 239.255.3.22 is_ex { }] [gaddr 224.0.0.251 is_ex { }]



toch stopt de multicast stream ineens met binnenkomen en is een restart van igmproxy of een kanaal swap nodig om weer verder te gaan...

Heeft vanavond weer een hele tijd gewerkt todat ik die IOMMU had aangezet. Sinds dien is het weer onbetrouwbaar (ook na weer uitzetten). Er is geen touw aan te knopen wanneer het goed gaat en wanneer mis.
toon volledige bericht
Wat is de uptime van je xSense router als je problemen hebt?

Staat de route dan nog in je tabel?

woensdag 4 januari 2023 11:44

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op woensdag 4 januari 2023 @ 10:28:
[...]


Wat is de uptime van je xSense router als je problemen hebt?

Staat de route dan nog in je tabel?
Uptime lijkt niet een punt te zijn. Die is niet erg hoog steeds (in de paar uur) omdat ik constant nog dingen probeer. Maar na mijn laatste poging gisteravond lijkt hij nu vanochtend het weer goed te doen (maar voor hoelang...)
Route staat er gewoon nog in ja, dat is het ook niet. Dan zou ie het ook niet meer doen na een kanaal swap immers.

Het zou erg helpen als er een beschrijving is van de kritieke communicatie paden. Voor zover ik nu zelf heb begrepen is dat na een kanaal swap de decoder eerst via IPTV-WAN een unicast udp stream vraagt van het kanaal dat na een seconde of twee zal moeten worden opgevolgd door een multicast udp stream door een igmp join van het multicast kanaal die vervolgens door igmproxy wordt doorgestuurd. Elke minuut of twee stuurt de STB een nieuwe join die de igmproxy table blijft refreshen wat als gevolg is dat igmpproxy een group report blijft sturen naar KPN. Dit gaat ook gewoon goed.

Maar wat er dan mis gaat zodra het bij mij vast loopt is mij nog niet duidelijk. De group reports lopen gewoon, de translation table is ook in orde. Maar de multicast stream stopt ineens en dat zou niet moeten omdat de group reports immers worden verstuurd door igmpproxy. Net alsof deze dus niet aankomen en worden gefilterd (maar alleen in enkele gevallen). De NTU zit gewoon rechtstreeks aan de proxmox en dus via PCI passthrough direct aan de pfsense/opnsense. Allow-opts staat goed.

woensdag 4 januari 2023 12:18

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 11:44:
[...]


Uptime lijkt niet een punt te zijn. Die is niet erg hoog steeds (in de paar uur) omdat ik constant nog dingen probeer. Maar na mijn laatste poging gisteravond lijkt hij nu vanochtend het weer goed te doen (maar voor hoelang...)
Ik zou dat wel in de gaten houden, VM's rebooten op de default kernel meerdere keren per dag.
Route staat er gewoon nog in ja, dat is het ook niet. Dan zou ie het ook niet meer doen na een kanaal swap immers.
Correct
Het zou erg helpen als er een beschrijving is van de kritieke communicatie paden. Voor zover ik nu zelf heb begrepen is dat na een kanaal swap de decoder eerst via IPTV-WAN een unicast udp stream vraagt van het kanaal dat na een seconde of twee zal moeten worden opgevolgd door een multicast udp stream door een igmp join van het multicast kanaal die vervolgens door igmproxy wordt doorgestuurd. Elke minuut of twee stuurt de STB een nieuwe join die de igmproxy table blijft refreshen wat als gevolg is dat igmpproxy een group report blijft sturen naar KPN. Dit gaat ook gewoon goed.
Ik ben er ook geen expert in, maar volgens mij is het als volgt. De STB vraagt een stream aan via een IGMP join, deze zet de IGMP proxy door. En daarna haalt de STB de (UDP) stream op en zet deze door naar het STB LAN.

Zelf is het mij onbekend dat er eerst een unicast stream wordt opgezet, er wordt alleen een plaatje opgehaald om het wachten te verzachten voor de kijker, tot de echte stream loopt.
Maar wat er dan mis gaat zodra het bij mij vast loopt is mij nog niet duidelijk. De group reports lopen gewoon, de translation table is ook in orde. Maar de multicast stream stopt ineens en dat zou niet moeten omdat de group reports immers worden verstuurd door igmpproxy. Net alsof deze dus niet aankomen en worden gefilterd (maar alleen in enkele gevallen). De NTU zit gewoon rechtstreeks aan de proxmox en dus via PCI passthrough direct aan de pfsense/opnsense. Allow-opts staat goed.
Ik zou eens je onderzoek verplaatsen naar je switch laag. Kan je daar IGMP snooping uitschakelen, of switches van locatie wisselen?

Wil je nog screenshots delen van je xSense installatie, of neem je aan dat het daar goed staat?

[ Voor 8% gewijzigd door stormfly op 04-01-2023 12:20 ]

woensdag 4 januari 2023 16:22

Acties:
  • +1 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op woensdag 4 januari 2023 @ 12:18:

Zelf is het mij onbekend dat er eerst een unicast stream wordt opgezet, er wordt alleen een plaatje opgehaald om het wachten te verzachten voor de kijker, tot de echte stream loopt.
Dat gebeurd bij mij wel zeker. Om het zappen te versnellen denk ik. Ik heb een Arris VIP5202. Wat jij aangeeft (plaatje) herken ik wel van mijn vorige ontvanger (weet merk niet meer).
Ik zou eens je onderzoek verplaatsen naar je switch laag. Kan je daar IGMP snooping uitschakelen, of switches van locatie wisselen?
Daar is niks in veranderd met de fritzbox in mijn eerste config. Daar ging gewoon de WAN kabel in een 1x pci passthrough (dus uit de fritzbox halen en in de router drukken) en de 4x lan kabel van de fritzbox in een vmbr0 (proxmox niveau) in de andere poorten van de router. Hierdoor is het onmogelijk dat er wat mis is met de rest van het netwerk.
Nu zit er wel een extra switch tussen ivm de 2x pci passthrough. De router/proxmox hangt dus nu alleen met 2x (WAN, LAN) pci passthrough aan het rest van het netwerk (en nog een management interface voor proxmox). Initieel leek dit de oplossing te zijn maar gisterenavond ging het toch na een paar uur tv kijken toch weer mis (en toen bleef het mis gaan).
Wil je nog screenshots delen van je xSense installatie, of neem je aan dat het daar goed staat?
Daar staat het echt wel goed. En het werkt immers ook gewoon voor een tijdje. Dus in de basis klopt de configuratie.

Nee, wat mij enorm zou helpen is beschrijving van het in stand houden van het beeld en voornamelijk waarom een multicast stream besluit te stoppen terwijl er gewoon subscribers zijn (via igmp group reports).

Ik bedenk mij, terwijl ik dit schrijf, of QoS een ding kan zijn. De igmp group report verlaat nu de router richting KPN zonder QoS. Als het drukker wordt (later op de avond?) kan het netwerk wellicht dit weggooien (ook al zit het in vlan 4). Zou de fritzbox QoS op uitgaande vlan 4 verkeer zetten? Misschien daar even een dump van maken. Iemand die QoS heeft aangezet op vlan4?
edit: nee dit is het ook niet. Wordt netjes met tos 0xc0 uitgezonden (zie mijn packet dump hierboven) en door igmpproxy gezet.

[ Voor 3% gewijzigd door thehog op 04-01-2023 16:35 ]

woensdag 4 januari 2023 18:15

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

@stormfly heeft jouw Topton ook een 2.5Gbps interface (I225-V chipset)? Ik begin te vermoedden dat het daar aan ligt. Als ik daar op zoek op zie ik wel meer problemen daarmee met pfsense. Ik ga er maar eens een USB netwerk adapter in stoppen om te zien of dat wat veranderd.

woensdag 4 januari 2023 19:36

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 18:15:
@stormfly heeft jouw Topton ook een 2.5Gbps interface (I225-V chipset)? Ik begin te vermoedden dat het daar aan ligt. Als ik daar op zoek op zie ik wel meer problemen daarmee met pfsense. Ik ga er maar eens een USB netwerk adapter in stoppen om te zien of dat wat veranderd.
Nee de 226 variant. Feitelijk rev 4 van de 225, jij hebt dan de 225 rev 3?

woensdag 4 januari 2023 19:39

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 16:22:
[...]
Dat gebeurd bij mij wel zeker. Om het zappen te versnellen denk ik. Ik heb een Arris VIP5202. Wat jij aangeeft (plaatje) herken ik wel van mijn vorige ontvanger (weet merk niet meer)..
Het is een bijna CPU loos doosje. Ik kan mij niet voorstellen dat ze starten met een unicast stream, en die seamless omzetten naar een multicast stream.

Hoe en wat heb je gemeten? Heb je onderscheid kunnen maken tussen stream verkeer en unicast verkeer zoals gids en versnelling plaatje tijdens het zappen?

woensdag 4 januari 2023 19:55

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op woensdag 4 januari 2023 @ 19:36:
[...]


Nee de 226 variant. Feitelijk rev 4 van de 225, jij hebt dan de 225 rev 3?
Ja blijkbaar:
Intel Corporation Ethernet Controller I225-V (rev 03)

Is daar wat mee?

woensdag 4 januari 2023 20:03

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 19:55:
[...]

Ja blijkbaar:
Intel Corporation Ethernet Controller I225-V (rev 03)

Is daar wat mee?
Zover ik weet niet, blijkbaar hangt er een donkere wolk rond de 225 zodat er een 226 nodig was. De gen 1 en gen 2 waren blijkbaar erg slecht.

woensdag 4 januari 2023 20:09

Acties:
  • +1 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op woensdag 4 januari 2023 @ 19:39:
[...]


Het is een bijna CPU loos doosje. Ik kan mij niet voorstellen dat ze starten met een unicast stream, en die seamless omzetten naar een multicast stream.

Hoe en wat heb je gemeten? Heb je onderscheid kunnen maken tussen stream verkeer en unicast verkeer zoals gids en versnelling plaatje tijdens het zappen?
En toch zie ik dat na het zappen door een tcpdump op vlan4. Eerst een unicast stream van data naar het NAT adres en doorgezet naar de STB waarna multicast direct erna komt (seconde later).

Hier zap ik naar een ander kanaal (filter even het verkeer van vorige kanaal omdat dat er nog voor een paar seconden tussen zit). Een udp stroom komt op gang (length 1330)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13

20:02:46.233179 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 347
20:02:46.264303 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 322
20:02:46.275397 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 371
20:02:46.477431 IP 10.227.237.182.42946 > 213.75.118.4.50649: UDP, length 148
20:02:46.487518 IP 10.227.237.182.39457 > 213.75.118.161.50321: UDP, length 28
20:02:46.487567 IP 10.227.237.182.53215 > 213.75.118.161.50320: UDP, length 28
20:02:46.491319 IP 213.75.118.161.50321 > 10.227.237.182.39457: UDP, length 52
20:02:46.491367 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 52
20:02:46.498853 IP 10.227.237.182.35268 > 213.75.118.161.6323: UDP, length 112
20:02:46.502590 IP 213.75.118.161.50321 > 10.227.237.182.39457: UDP, length 236
20:02:46.512467 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.512517 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.513256 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


200ms later loopt de stream nog steeds in UDP

code:
1
2
3
4
5
6
7
8
9
10
11
12
13

20:02:46.703877 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.704870 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.705028 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.705901 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.706055 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.707030 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.707205 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.708053 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.708230 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.709228 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.709379 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.710248 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.710405 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Ongeveer na nog eens 200ms komt de igmp join

code:
1
2
3
4
5
6
7

20:02:46.857355 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858355 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858499 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858753 IP 10.227.237.182 > 224.0.0.22: igmp v3 report, 1 group record(s)
20:02:46.859381 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.859382 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.860522 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Waarna 100ms later de multicast op gang komt terwijl unicast nog loopt.

code:
1
2
3
4
5
6
7
8
9
10
11
12

20:02:46.902788 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903644 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903813 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903818 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193347
20:02:46.904813 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.904814 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.905347 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193348
20:02:46.905828 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.906004 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.906844 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193349
20:02:46.906965 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.907141 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Uiteindelijk sterft udp af na nog eens 500ms en neemt multicast alles over.
Best slim eigenlijk :)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

20:02:47.453689 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193710
20:02:47.454050 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:47.454226 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:47.455208 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193711
20:02:47.456736 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193712
20:02:47.458256 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193713
20:02:47.459753 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193714
20:02:47.461270 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193715
20:02:47.462783 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193716
20:02:47.464300 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193717
20:02:47.465811 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193718
20:02:47.467325 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193719
20:02:47.468841 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193720
20:02:47.470364 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193721
20:02:47.471888 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193722
20:02:47.473383 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193723



Dit is wat mensen die multicast niet in order hebben dan ook zien. Ze zeggen dan, "ik zie wel voor 2 seconden bewegend beeld". Zien dus wel de unicast maar niet de multicast.

woensdag 4 januari 2023 20:11

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op woensdag 4 januari 2023 @ 20:03:
[...]


Zover ik weet niet, blijkbaar hangt er een donkere wolk rond de 225 zodat er een 226 nodig was. De gen 1 en gen 2 waren blijkbaar erg slecht.
Ok, dan ben ik benieuwd wat de USB adapter gaat doen morgen (als ie op tijd binnenkomt).

woensdag 4 januari 2023 20:23

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op woensdag 4 januari 2023 @ 20:09:
[...]


En toch zie ik dat na het zappen door een tcpdump op vlan4. Eerst een unicast stream van data naar het NAT adres en doorgezet naar de STB waarna multicast direct erna komt (seconde later). Source IP adres is zelfde als tijdens de unicast als de multicast, destination is uiteraard anders.

Hier zap ik naar een ander kanaal (filter even het verkeer van vorige kanaal omdat dat er nog voor een paar seconden tussen zit). Een udp stroom komt op gang (length 1330)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13

20:02:46.233179 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 347
20:02:46.264303 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 322
20:02:46.275397 IP 213.75.167.58.45566 > 224.3.2.6.9875: UDP, length 371
20:02:46.477431 IP 10.227.237.182.42946 > 213.75.118.4.50649: UDP, length 148
20:02:46.487518 IP 10.227.237.182.39457 > 213.75.118.161.50321: UDP, length 28
20:02:46.487567 IP 10.227.237.182.53215 > 213.75.118.161.50320: UDP, length 28
20:02:46.491319 IP 213.75.118.161.50321 > 10.227.237.182.39457: UDP, length 52
20:02:46.491367 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 52
20:02:46.498853 IP 10.227.237.182.35268 > 213.75.118.161.6323: UDP, length 112
20:02:46.502590 IP 213.75.118.161.50321 > 10.227.237.182.39457: UDP, length 236
20:02:46.512467 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.512517 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.513256 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


200ms later loopt de stream nog steeds in UDP

code:
1
2
3
4
5
6
7
8
9
10
11
12
13

20:02:46.703877 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.704870 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.705028 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.705901 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.706055 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.707030 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.707205 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.708053 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.708230 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.709228 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.709379 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.710248 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.710405 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Ongeveer na nog eens 200ms komt de igmp join

code:
1
2
3
4
5
6
7

20:02:46.857355 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858355 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858499 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.858753 IP 10.227.237.182 > 224.0.0.22: igmp v3 report, 1 group record(s)
20:02:46.859381 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.859382 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.860522 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Waarna 100ms later de multicast op gang komt terwijl unicast nog loopt.

code:
1
2
3
4
5
6
7
8
9
10
11
12

20:02:46.902788 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903644 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903813 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.903818 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193347
20:02:46.904813 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.904814 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.905347 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193348
20:02:46.905828 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.906004 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.906844 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193349
20:02:46.906965 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:46.907141 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330


Uiteindelijk sterft udp af na nog eens 500ms en neemt multicast alles over.
Best slim eigenlijk :)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

20:02:47.453689 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193710
20:02:47.454050 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:47.454226 IP 213.75.118.161.50320 > 10.227.237.182.53215: UDP, length 1330
20:02:47.455208 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193711
20:02:47.456736 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193712
20:02:47.458256 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193713
20:02:47.459753 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193714
20:02:47.461270 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193715
20:02:47.462783 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193716
20:02:47.464300 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193717
20:02:47.465811 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193718
20:02:47.467325 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193719
20:02:47.468841 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193720
20:02:47.470364 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193721
20:02:47.471888 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193722
20:02:47.473383 IP 217.166.224.161.49152 > 224.0.250.161.6322: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2193723



Dit is wat mensen die multicast niet in order hebben dan ook zien. Ze zeggen dan, "ik zie wel voor 2 seconden bewegend beeld". Zien dus wel de unicast maar niet de multicast.
toon volledige bericht
Mooie onderbouwing, lijkt inderdaad zo te werken.

donderdag 5 januari 2023 13:13

Acties:
  • +1 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ik heb er nu twee usb-ethernet sticks aan hangen waar WAN (vlan 4 en 6) en LAN aan hangt. En nog steeds zelfde problemen. Draai zelfs nu bare metal pfSense.
Ik geef het nu even op. Ga het later nog wel eens proberen met oude NUC die ik nog heb liggen.

donderdag 5 januari 2023 21:22

Acties:
  • +2 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Nou, toch nog even verder gegaan. Helemaal opnieuw opgebouwd met proxmox en pfsense en pci passthrough. Maar nee, nog steeds ging het mis.

Totdat ik nog een keer de fritzbox tcpdump ben gaan vergelijken met pfsense. Wat mij als enige opviel is dat pfsense in de update naar KPN (WAN IPTV) een igmp bericht stuurt met 11 groepen (zie hierboven ook ergens in een packet dump van me, 11 group record(s)). Voor TV beeld is maar 1 groep nodig, en nog 1 of 2 groepen voor andere zaken. De fritzbox stuurt dan ook maar 3 groep verzoeken (en tijdens zappen kort even 4).

Ik heb m'n STB gewoon in het LAN zitten met best veel spul wat ook veel IGMP doet voor allerlei andere zaken. PFsense pakt dat gewoon op en geeft dat dus ook door als group verzoeken naar KPN, en komt zo dus op 11 groepen. Nu heb ik het vermoedden dat KPN er een limiet op heeft zitten. Zou het 10 groepen zijn? Dat verklaard dan gelijk ook mijn ervaring dat het soms wel werkt en soms niet.

Nu via igmpproxy.conf een whitelist gezet:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igc1.4 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/1
altnet 128.0.0.0/1

phyint igc0 downstream ratelimit 0 threshold 1 whitelist 224.0.2.3/32 whitelist 224.3.2.6/32 whitelist 224.0.248.0/21

altnet 192.168.178.0/24

phyint pppoe0 disabled


En dat werkt nu! Althans fingers crossed... maar ben al de hele avond aan het kijken en het gaat niet stuk als ik even wat doen op pfsense (hiervoor vaak wel).

De whitelist is zoveel mogelijk beperkt voor wat ik heb kunnen zien waar KPN waarschijnlijk multicast nodig heeft. Dat kan nog te beperkt zijn maar voor nu werkt het voor mij.

Een nadeel,.. de pfsense GUI overschrijft de file bij elke save en bij service start. Je zult dus zelf een andere copy van het bestand moeten maken en met de hand igmpproxy starten ("igmpproxy /root/igmpproxy.conf in command line bijv"). En zorgen dat hij bij reboot ook wordt gestart (dat moet ik nog uitzoeken).

donderdag 5 januari 2023 21:42

Acties:
  • +1 Henk 'm!
  • StaticZ
  • Registratie: September 2000
  • Laatst online: 23:29

StaticZ

Heb hier exact hetzelfde gehad met OPNsense ook uren achter elkaar werken en ineens stoppen met werken.
Even heen en weer zappen tussen de zenders en het ging weer.
Ik heb destijds gedacht dat Sonos roet in het eten gooide en heb een apart vlan voor mijn stb's gemaakt.
Sindsdien geen problemen meer.

Als ik jou verhaal zo lees heb ik hetzelfde probleem gehad.

Ik zie zo alleen geen optie in OPNsense om multicast ranges te whitelisten.

donderdag 5 januari 2023 21:44

Acties:
  • +1 Henk 'm!
  • supayoshi
  • Registratie: November 2013
  • Laatst online: 29-06 17:07

supayoshi

Mag ik even mijn respect tonen? Ik volg al twee dagen op de voet hoe je reageert, want ik heb hetzelfde probleem... op mijn kleine kastje... het is de laatste paar maanden erger geworden... het werkte voorheen altijd perfect... Na een herstart van igmpproxy werkte het altijd weer goed... Jouw oplossing is echt heel goed uitgedacht en samen met Wireshark zo goed gedaan, vind ik echt heel erg netjes. Dankjewel. Misschien kunnen ze deze aangepaste configuratie in igmpproxy zetten bij OPNsense of PFsense, zodat die niet steeds overschreven wordt?
thehog schreef op donderdag 5 januari 2023 @ 21:22:
Nou, toch nog even verder gegaan. Helemaal opnieuw opgebouwd met proxmox en pfsense en pci passthrough. Maar nee, nog steeds ging het mis.

Totdat ik nog een keer de fritzbox tcpdump ben gaan vergelijken met pfsense. Wat mij als enige opviel is dat pfsense in de update naar KPN (WAN IPTV) een igmp bericht stuurt met 11 groepen (zie hierboven ook ergens in een packet dump van me, 11 group record(s)). Voor TV beeld is maar 1 groep nodig, en nog 1 of 2 groepen voor andere zaken. De fritzbox stuurt dan ook maar 3 groep verzoeken (en tijdens zappen kort even 4).

Ik heb m'n STB gewoon in het LAN zitten met best veel spul wat ook veel IGMP doet voor allerlei andere zaken. PFsense pakt dat gewoon op en geeft dat dus ook door als group verzoeken naar KPN, en komt zo dus op 11 groepen. Nu heb ik het vermoedden dat KPN er een limiet op heeft zitten. Zou het 10 groepen zijn? Dat verklaard dan gelijk ook mijn ervaring dat het soms wel werkt en soms niet.

Nu via igmpproxy.conf een whitelist gezet:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igc1.4 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/1
altnet 128.0.0.0/1

phyint igc0 downstream ratelimit 0 threshold 1 whitelist 224.0.2.3/32 whitelist 224.3.2.6/32 whitelist 224.0.248.0/21

altnet 192.168.178.0/24

phyint pppoe0 disabled


En dat werkt nu! Althans fingers crossed... maar ben al de hele avond aan het kijken en het gaat niet stuk als ik even wat doen op pfsense (hiervoor vaak wel).

De whitelist is zoveel mogelijk beperkt voor wat ik heb kunnen zien waar KPN waarschijnlijk multicast nodig heeft. Dat kan nog te beperkt zijn maar voor nu werkt het voor mij.

Een nadeel,.. de pfsense GUI overschrijft de file bij elke save en bij service start. Je zult dus zelf een andere copy van het bestand moeten maken en met de hand igmpproxy starten ("igmpproxy /root/igmpproxy.conf in command line bijv"). En zorgen dat hij bij reboot ook wordt gestart (dat moet ik nog uitzoeken).
toon volledige bericht

donderdag 5 januari 2023 21:53

Acties:
  • 0 Henk 'm!
  • Thralas
  • Registratie: December 2002
  • Laatst online: 00:32

Thralas

thehog schreef op donderdag 5 januari 2023 @ 21:22:
De whitelist is zoveel mogelijk beperkt voor wat ik heb kunnen zien waar KPN waarschijnlijk multicast nodig heeft. Dat kan nog te beperkt zijn maar voor nu werkt het voor mij.
Je zou kunnen kijken of 224.0.0.0/8 werkt, dat is het simpelste dat alles zeker dekt.
Een nadeel,.. de pfsense GUI overschrijft de file bij elke save en bij service start.
Je kunt proberen om 'm immutable te maken.

donderdag 5 januari 2023 22:19

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Thralas schreef op donderdag 5 januari 2023 @ 21:53:
[...]


Je zou kunnen kijken of 224.0.0.0/8 werkt, dat is het simpelste dat alles zeker dekt.


[...]


Je kunt proberen om 'm immutable te maken.
Nee 224.0.0.0/8 (of bedoel je /4?) werkt niet omdat je dan ook alle andere groups mee krijgt die je niet zou willen. Je wil echt alleen de groepen willen accepteren die KPN gebruikt.

Immutable werkt ook niet omdat hij dan niet meer wil starten. Maar ik heb inmiddels de juiste files kunnen aanpassen (werkend voor 2.6.0 release) zodat hij in de GUI aan te passen is. Zal even een plek zoeken waar ik de edits kan plaatsen zodat anderen hem ook kunnen gebruiken.

donderdag 5 januari 2023 22:19

Acties:
  • 0 Henk 'm!
  • ik222
  • Registratie: Maart 2007
  • Niet online

ik222

Topicstarter
Andere apparaten die IGMP doen kunnen zeker roet in het eten gooien.

Beste oplossing is managed switches gebruiken en dan je STB’s in een eigen VLAN. Vervolgens kun je IGMPProxy dan alleen de interface in dat VLAN als downstream instellen. Op die manier heb je nooit dit soort issues en hoeft je geen whitelist bij te houden.

donderdag 5 januari 2023 22:20

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

supayoshi schreef op donderdag 5 januari 2023 @ 21:44:
Mag ik even mijn respect tonen? Ik volg al twee dagen op de voet hoe je reageert, want ik heb hetzelfde probleem... op mijn kleine kastje... het is de laatste paar maanden erger geworden... het werkte voorheen altijd perfect... Na een herstart van igmpproxy werkte het altijd weer goed... Jouw oplossing is echt heel goed uitgedacht en samen met Wireshark zo goed gedaan, vind ik echt heel erg netjes. Dankjewel. Misschien kunnen ze deze aangepaste configuratie in igmpproxy zetten bij OPNsense of PFsense, zodat die niet steeds overschreven wordt?


[...]
Ja ik heb een aanpassing op de GUI kunnen schrijven. Ga ik zo even ergens plaatsen.

donderdag 5 januari 2023 22:21

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

ik222 schreef op donderdag 5 januari 2023 @ 22:19:
Andere apparaten die IGMP doen kunnen zeker roet in het eten gooien.

Beste oplossing is managed switches gebruiken en dan je STB’s in een eigen VLAN. Vervolgens kun je IGMPProxy dan alleen de interface in dat VLAN als downstream instellen. Op die manier heb je nooit dit soort issues en hoeft je geen whitelist bij te houden.
Dat klopt. Dat werkt ook.
Maar ik had het gewoon in mijn eigen LAN en met de fritzbox werkt het ook. Dus dan wil ik dat werkend hebben en begrijpen waarom dat niet werkt.

donderdag 5 januari 2023 22:42

Acties:
  • +2 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ok, hier staat de commit: https://github.com/IgorYb...6d048ad9bcec20024d6b1c9a6

Is dus op basis van de pfsense 2.6.0 release. De drie bestanden kan je zelf aanpassen of downloaden van github en vervangen.
Ik ga het ook aanmelden bij netgate en hopen dat ze he meenemen in een vervolg.

vrijdag 6 januari 2023 01:16

Acties:
  • 0 Henk 'm!
  • supayoshi
  • Registratie: November 2013
  • Laatst online: 29-06 17:07

supayoshi

thehog schreef op donderdag 5 januari 2023 @ 22:20:
[...]


Ja ik heb een aanpassing op de GUI kunnen schrijven. Ga ik zo even ergens plaatsen.
Ik zie dat je de commit voor PFsense hebt gedaan, maar ik gebruik OPNsense, kunnen we dit ook voor OPNsense fixen?

vrijdag 6 januari 2023 09:59

Acties:
  • +1 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

supayoshi schreef op vrijdag 6 januari 2023 @ 01:16:
[...]


Ik zie dat je de commit voor PFsense hebt gedaan, maar ik gebruik OPNsense, kunnen we dit ook voor OPNsense fixen?
Ga ik doen. Denk dat het bijna hetzelfde is. Zal wel even kijken.

vrijdag 6 januari 2023 12:08

Acties:
  • +1 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Hier de commit voor opnsense (check even of je wel plugin versie 1.5_2 hebt, dan kan je de bestanden gewoon overschrijven, ergens in /usr/local)

https://github.com/opnsen...d79e554ab2c06c9a34f92ab8b

Ook hier een PR voor ingeschoten bij de OPNsense community

vrijdag 6 januari 2023 16:04

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ben benieuwd wat de ervaringen van anderen zijn. Bij mij lijkt het opgelost. Gisteravond goed TV kunnen kijken. Vandaag nog niet de tv aangehad maar ik denk wel dat dit het is.

vrijdag 6 januari 2023 17:33

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op vrijdag 6 januari 2023 @ 16:04:
Ben benieuwd wat de ervaringen van anderen zijn. Bij mij lijkt het opgelost. Gisteravond goed TV kunnen kijken. Vandaag nog niet de tv aangehad maar ik denk wel dat dit het is.
Met jouw diepgaande onderzoekskwaliteiten, heb jij al een verdiepingsslag gemaakt in het spontaan rebooten van VM's op de N5105 en N6005 processoren onder QEMU/Proxmox?

Ik heb werkelijk geen idee hoe ik dit zou moeten aanvliegen, mensen zonder proxmox en een handmatige Install van QEMU hebben het ook. Het lijkt diep uit het OS te komen, met het uitschakelen van C-states en kernel 6.1 is het gedrag mogelijk minder.

Arghhh waar knoop je dit verhaal aan vast en wanneer denk je; ik ga wel voor een native pfSense installatie zonder reboots.

[ Voor 5% gewijzigd door stormfly op 06-01-2023 17:34 ]

vrijdag 6 januari 2023 17:45

Acties:
  • 0 Henk 'm!
  • synoniem
  • Registratie: April 2009
  • Niet online

synoniem

Ik heb tijden pfSense onder VMware gedraaid maar ben weer over gegaan op native installatie. Er zijn teveel variabelen onder een hypervisor als er storing is. En in mijn ervaring rebootte ik de hypervisor vaker dan pfSense.

Overigens is een native install ook geen garantie want ik had een leuke minipc met een Gigabyte GA-J3455N-D3H (Celeron J3455 op mITX) met twee Realtek netwerkpoorten maar daar ging PPPOE regelmatig de mist in waardoor ik het systeem hard resetten moest.

vrijdag 6 januari 2023 19:01

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op vrijdag 6 januari 2023 @ 17:33:
[...]


Met jouw diepgaande onderzoekskwaliteiten, heb jij al een verdiepingsslag gemaakt in het spontaan rebooten van VM's op de N5105 en N6005 processoren onder QEMU/Proxmox?
Ik heb nog maar 1 VM (pfsense) draaien en die draait nu gelukkig nog. Ik heb er een i7-1165G7 in zitten overigens (beetje overkill maar wel fijn voor als ik als homelab er nog wat mee wil doen ofzo....) en misschien heeft die daar geen last van. Ik hou het wel even in de gaten.

zaterdag 7 januari 2023 19:28

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

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?

Afbeeldingslocatie: https://tweakers.net/i/44MSWHnZ39yhzgVNsoVR4L_JovE=/800x/filters:strip_exif()/f/image/BnNJ1eyT4zCBZyN2jG5npXGd.png?f=fotoalbum_large

zaterdag 7 januari 2023 19:40

Acties:
  • 0 Henk 'm!
  • synoniem
  • Registratie: April 2009
  • Niet online

synoniem

thehog schreef op zaterdag 7 januari 2023 @ 19:28:
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?

[Afbeelding]
Nee, ik heb geen IPTV meer dus alles wat daar mee te maken had heb ik verwijderd uit mijn config.

zaterdag 7 januari 2023 19:54

Acties:
  • 0 Henk 'm!
  • frietvanpiet
  • Registratie: September 2012
  • Laatst online: 18-01 15:06

frietvanpiet

thehog schreef op zaterdag 7 januari 2023 @ 19:28:
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?

[Afbeelding]
Is die reeks whitelists voldoende?
Ik zag regelmatig ook 239.0.x.x. voorbijkomen bij packet captures.

Ik ben ook nieuwsgierig of je al een keer getest hebt met het opnieuw inladen van de software van de Stb. Of die data ook goed doorkomt.
Zelf heb ik broadcast ranges 224.0.0.0/4 toegepast aangezien deze doorloopt tot 239.x.x.x

Tibber - Dynamic ESS: 3x Multiplus II 3000/48 - 3x US5000 - 15kWh - Cerbo GX - Beta VRM - 3500Wp solar

zaterdag 7 januari 2023 20:37

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

frietvanpiet schreef op zaterdag 7 januari 2023 @ 19:54:
[...]


Is die reeks whitelists voldoende?
Ik zag regelmatig ook 239.0.x.x. voorbijkomen bij packet captures.

Ik ben ook nieuwsgierig of je al een keer getest hebt met het opnieuw inladen van de software van de Stb. Of die data ook goed doorkomt.
Zelf heb ik broadcast ranges 224.0.0.0/4 toegepast aangezien deze doorloopt tot 239.x.x.x
Die 239. is voor andere zaken (zoals upnp) en is dus niet nodig richting KPN (voor zover ik nu zie). En ja ik heb de STB factory reset gegeven en dat werkt ook.

Je mag 224.0.0.0/4 als whitelist opgeven (maar dat heeft dan geen zin eigenlijk wat dat is inderdaad alles). Maar het doel is juist om te beperken omdat KPN blijkbaar gaat blokkeren als je te veel group reports stuurt.

zaterdag 7 januari 2023 21:06

Acties:
  • 0 Henk 'm!
  • ik222
  • Registratie: Maart 2007
  • Niet online

ik222

Topicstarter
Wat ik alleen niet goed begrijp is waarom je die whitelist nodig hebt. Ik zou eerder uitzoeken welke apparaten dan zo veel IGMP joins sturen en vooral ook waarom pfSense die wel doorzet maar de standaard Fritzbox niet.

zaterdag 7 januari 2023 21:11

Acties:
  • +1 Henk 'm!
  • StaticZ
  • Registratie: September 2000
  • Laatst online: 23:29

StaticZ

Chromecast, Sonos, Heos en ga zo maar door gebruiken allemaal multicast om elkaar te vinden.
Waarschijnlijk filtert de Fritzbox en de Experiabox deze adressen.

@thehog ik heb je bestanden voor OPNsense nog niet geprobeerd, heb al een hele tijd de stb's in een apart vlan zitten. En gaan we daar nu mee aan het prutsen dan is het oorlog hier >:) .
Misschien a.s. maandag nog even tijd om te spelen.

[ Voor 43% gewijzigd door StaticZ op 07-01-2023 21:13 ]

zaterdag 7 januari 2023 21:22

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

StaticZ schreef op zaterdag 7 januari 2023 @ 21:11:


@thehog ik heb je bestanden voor OPNsense nog niet geprobeerd, heb al een hele tijd de stb's in een apart vlan zitten. En gaan we daar nu mee aan het prutsen dan is het oorlog hier >:) .
Misschien a.s. maandag nog even tijd om te spelen.
Dan zou ik het gewoon zo laten hoor :)

[ Voor 16% gewijzigd door thehog op 07-01-2023 21:23 ]

zaterdag 7 januari 2023 21:25

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

ik222 schreef op zaterdag 7 januari 2023 @ 21:06:
Wat ik alleen niet goed begrijp is waarom je die whitelist nodig hebt. Ik zou eerder uitzoeken welke apparaten dan zo veel IGMP joins sturen en vooral ook waarom pfSense die wel doorzet maar de standaard Fritzbox niet.
Precies wat @StaticZ al aangeeft. Hoe meer smart devices je in huis hebt die ook multicast doen hoe groter de kans is dat er meer joins komen voor andere groepen. Fritzbox en Experia blokkeren dat zeker. Dat heb ik kunnen bevestigen met mijn dumps.

maandag 9 januari 2023 23:04

Acties:
  • 0 Henk 'm!
  • R0GGER
  • Registratie: September 2011
  • Laatst online: 25-06 23:00

R0GGER

thehog schreef op donderdag 5 januari 2023 @ 22:42:
Ok, hier staat de commit: https://github.com/IgorYb...6d048ad9bcec20024d6b1c9a6

Is dus op basis van de pfsense 2.6.0 release. De drie bestanden kan je zelf aanpassen of downloaden van github en vervangen.
Ik ga het ook aanmelden bij netgate en hopen dat ze he meenemen in een vervolg.
Dank! Werkt goed so far!

De whitelist bestaat nu uit deze ranges 224.0.2.3/32, 224.3.2.6/32 en 224.0.248.0/21, zijn er nog andere nodig?

dinsdag 10 januari 2023 07:07

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

R0GGER schreef op maandag 9 januari 2023 @ 23:04:
[...]


Dank! Werkt goed so far!

De whitelist bestaat nu uit deze ranges 224.0.2.3/32, 224.3.2.6/32 en 224.0.248.0/21, zijn er nog andere nodig?
Tijd zal het leren maar tot nu toe geen problemen met deze lijst gehad

dinsdag 10 januari 2023 09:41

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ik heb even lopen zoeken in de firmware van de fritzbox (via https://boxmatrix.info/ te vinden en elders staat ook wel hoe je dan de image kan uitpakken).

Er zit in de provider specifieke configs niets over een whitelist voor igmp. Toch zag ik duidelijk dat de fritzbox de andere groepen, niet voor iptv bedoeld, er uit haalde (iets wat igmproxy dus niet deed).

Het kan zijn dat er dieper in de code (onleesbaar) een filter zit op alleen igmpproxy voor specifieke aangesloten apparatuur. Zoals bijv. op basis van dhcp identifier bepalen welke aangesloten netwerk apparaten de STB's zijn en dan alleen daar voor igmp proxy te doen.

Helaas doet igmproxy al standaard voor de hele aangesloten (downstream) subnet de igmp doorsturen (dus het is helemaal niet nodig om het subnet van je LAN in te vullen bij igmpproxy instellingen). Anders zouden we dit ook kunnen doen door je STB een vast DHCP adres te geven en alleen die in de downstream te accepteren.

woensdag 18 januari 2023 10:39

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op zaterdag 7 januari 2023 @ 19:28:
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?

[Afbeelding]
Nou goede vraag stel je in de laatste alinea. Ik zit in een meltdown 8) ik heb mijn bare metal pfsense naar 23.01 geüpdate (de beta) om toch nog even te kijken of ik bugs kan hunten voordat hij final is. Nu merk ik dat mijn beeld wegvalt, elke 25 seconden of elke minuut. Noem het goed hinderlijk, en altijd bij de 2e keer wegvallen hangt hij op stb-nmc-400.

Toen ben ik terug gegaan naar mijn VYOS IPTV router, die maanden lang stabiel heeft gedraaid. Hetzelfde effect...het stop met dezelfde timing interval.

Dan ben ik zojuist aanbeland bij jouw eerdere onderzoek en dat ga ik nu nogmaals doornemen met een andere bril op. Ik ben vooral benieuwd hoe jij de lijst opgebouwd hebt en geconstateerd hebt dat filtering nodig was. Vanmiddag komt er een simpele 5 ports vlan-aware switch binnen en kan ik een capture maken op het WAN van KPN en die eens vergelijken met mijn pfSense/VYOS. Met die vlan-aware switch kan ik ook de pfSense WAN poort erbij prikken en kijken of dit effect heeft, mogelijk wel omdat jij aangeeft dat KPN zelf lijkt te filteren in de EB...echter ik prik pfSense na/achter de EB erbij :*)

woensdag 18 januari 2023 10:48

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op zaterdag 7 januari 2023 @ 19:28:
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?

[Afbeelding]
code:
1
2
3
4
5
6
7
8

vyos@STBRTR# run show configuration commands | match igmp
set protocols igmp-proxy interface eth1.25 alt-subnet '172.16.25.0/24'
set protocols igmp-proxy interface eth1.25 role 'downstream'
set protocols igmp-proxy interface eth1.25 whitelist '224.0.2.3/32'
set protocols igmp-proxy interface eth1.25 whitelist '224.0.248.0/21'
set protocols igmp-proxy interface eth1.25 whitelist '224.3.2.6/32'
set protocols igmp-proxy interface eth2.4 alt-subnet '0.0.0.0/0'
set protocols igmp-proxy interface eth2.4 role 'upstream'


Dit is vrij makkelijk te testen -> duikt de meterkast in om de EB er weer uit te patchen.

woensdag 18 januari 2023 10:50

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op dinsdag 10 januari 2023 @ 09:41:
Ik heb even lopen zoeken in de firmware van de fritzbox (via https://boxmatrix.info/ te vinden en elders staat ook wel hoe je dan de image kan uitpakken).
Cool.
Helaas doet igmproxy al standaard voor de hele aangesloten (downstream) subnet de igmp doorsturen (dus het is helemaal niet nodig om het subnet van je LAN in te vullen bij igmpproxy instellingen). Anders zouden we dit ook kunnen doen door je STB een vast DHCP adres te geven en alleen die in de downstream te accepteren.
Ja het is wel zo dat mijn STB als enige in een vlan zit, vreemd dat het effect dan nog ontstaat. Ik zie in vyos wel nog in de IGMP-Proxy dat hij de mgmt interface ook qua multicast uitleest.

woensdag 18 januari 2023 10:57

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Het gaat met pfSense en een handmatige igmp proxy start met whitelist op CLI nog niet goed. Dit is wat IGMP-proxy laat zien van pfSense.

Zal de highlights die ik zelf waarneem er even uit pikken:

Qua timing stop het beeld als deze regels voorbijkomen. Dat lijkt opzicht een hele goede keuze omdat het inderdaad geen downstream is en hij door zou moeten lopen omdat dit verzoek van het WAN komt. Waarom dit verzoek dan wel voorbijkomt is mij een raadsel.

code:
1
2
3
4
5
6

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


Daarna heb je nog een fractie van een seconde en dan geeft de logging ook aan dat er geen routes meer zijn, en dus ook geen beeld meer op de TV |:(

Los van de melding over Errorno(49) over "can't assign requested address" baart het mij grotere zorgen waarom hij besluit om mij routes te gaan age-en. Hieronder nog de full log waar hopelijk @thehog nog een blik op wil werpen.

code:
1
2
3
4
5
6
7
8
9
10
11
12

About to call timeout 96 (#0)
Aging routes in table.
Removing group 224.0.252.126. Died of old age.
Removed route entry for 224.0.252.126 from table.
Vif bits : 0x00000000
Removing MFC: 217.166.226.126 -> 224.0.252.126, InpVIf: 1
MRT_DEL_MFC; Errno(49): Can't assign requested address

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



code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.226.126, Dst: 224.0.252.126, Age:1, St: A, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------
About to call timeout 91 (#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 92 (#0) - delay 10 secs
(Id:92, Time:10)
Created timeout 93 (#1) - delay 115 secs
(Id:92, Time:10)
(Id:93, Time:115)
About to call timeout 92 (#0)
Aging routes in table.
Removing group 224.0.252.126. Died of old age.
Removed route entry for 224.0.252.126 from table.
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Removing MFC: 217.166.226.126 -> 224.0.252.126, InpVIf: 1
Leaving group 224.0.252.126 upstream on IF address 10.238.169.97
Leaving group 224.0.252.126 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.226.126 to 224.0.252.126 on VIF[1]
No table entry for 224.0.252.126 [From: 217.166.226.126]. Inserting route.
No existing route for 224.0.252.126. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 224.0.252.126 on VIF #-1
No downstream listeners for group 224.0.252.126. No join sent.

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

Current routing table (Activate Route):
-----------------------------------------------------
#0: Src0: 217.166.226.126, Dst: 224.0.252.126, Age:2, St: A, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------
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.
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.
About to call timeout 93 (#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 94 (#0) - delay 10 secs
(Id:94, Time:10)
Created timeout 95 (#1) - delay 115 secs
(Id:94, Time:10)
(Id:95, Time:115)
About to call timeout 94 (#0)
Aging routes in table.

Current routing table (Age active routes):
-----------------------------------------------------
#0: Src0: 217.166.226.126, Dst: 224.0.252.126, Age:1, St: A, OutVifs: 0x00000000, dHosts: yes
-----------------------------------------------------
About to call timeout 95 (#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 96 (#0) - delay 10 secs
(Id:96, Time:10)
Created timeout 97 (#1) - delay 115 secs
(Id:96, Time:10)
(Id:97, Time:115)
About to call timeout 96 (#0)
Aging routes in table.
Removing group 224.0.252.126. Died of old age.
Removed route entry for 224.0.252.126 from table.
Vif bits : 0x00000000
Removing MFC: 217.166.226.126 -> 224.0.252.126, InpVIf: 1
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...
-----------------------------------------------------


Voor de volledigheid de igmp proxy configuratie:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igc1.4 upstream ratelimit 0 threshold 1
altnet 213.75.0.0/16
altnet 217.166.0.0/16

phyint igc2 downstream ratelimit 0 threshold 1
altnet 172.16.26.0/24
whitelist 224.0.2.3/32
whitelist 224.0.248.0/21
whitelist 224.3.2.6/32

phyint pppoe0 disabled

[ Voor 230% gewijzigd door stormfly op 18-01-2023 11:29 ]

woensdag 18 januari 2023 13:24

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Mijn besluit om te filteren kwam door de IGMP report die de fritzbox stuurde naar vlan 4 tov wat pfsense stuurde (via tcpdump op proto igmp gezien). Daarin stuurde de fritbzbox een report van steeds max 3 groups en pfsense meer dan 10.

Wat ik bij jou even niet snap is dit:
code:
1
2
3

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.

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

woensdag 18 januari 2023 13:28

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

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.

woensdag 18 januari 2023 22:12

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

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

Afbeeldingslocatie: https://tweakers.net/i/4KBW2gaUkzuk1paSucH30Le73i4=/800x/filters:strip_exif()/f/image/Z2fdWCK7ltYkoUpm7uTaw0Qq.png?f=fotoalbum_large

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

Afbeeldingslocatie: https://tweakers.net/i/ojw8pYy-EI0w0JdFN5PEcsnDitQ=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/hsglF7E8Jy1Q1gV111ZBK6vc.png?f=user_large

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.

Afbeeldingslocatie: https://tweakers.net/i/u2T60lEEN84oBlWqjpLdmOGe_fU=/800x/filters:strip_exif()/f/image/W73YHEp2sLsAie6M40HpBXpg.png?f=fotoalbum_large
thehog schreef op woensdag 18 januari 2023 @ 13:24:
Wat ik bij jou even niet snap is dit:
code:
1
2
3

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.

woensdag 18 januari 2023 22:52

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
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:
1
2
3
4
5
6
7
8
9
10

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.


Afbeeldingslocatie: https://tweakers.net/i/vr2giXYqWBONJuMMuROIlmlfqI4=/800x/filters:strip_exif()/f/image/D3cfkS3aAHJ5bGyyi2892cVb.png?f=fotoalbum_large

Full igmp-proxy log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218

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][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/root:
[23.01-BETA][admin@pfSense.high.local]/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][admin@pfSense.high.local]/root:
toon volledige bericht

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

woensdag 18 januari 2023 22:58

Acties:
  • 0 Henk 'm!
  • ik222
  • Registratie: Maart 2007
  • Niet online

ik222

Topicstarter
@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).

woensdag 18 januari 2023 23:06

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
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
Afbeeldingslocatie: https://tweakers.net/i/5EkUmgMfLuzfmdI6hFcLqBgWWfQ=/800x/filters:strip_exif()/f/image/spDFWrziWVMAk1j09qqpjgfN.png?f=fotoalbum_large

IPTV LAN
Afbeeldingslocatie: https://tweakers.net/i/hkXpi6UtjS5f1Y966YyQnK61Qno=/800x/filters:strip_exif()/f/image/2QTHDV3xJX9o3kQBA8lqc7fl.png?f=fotoalbum_large

Proxy
Afbeeldingslocatie: https://tweakers.net/i/zBye1sHJsyBn074NMyDfh12dduw=/800x/filters:strip_exif()/f/image/Sd6LneQt1wD8DmX2rq3LhHjd.png?f=fotoalbum_large

woensdag 18 januari 2023 23:09

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Je checksum errors kunnen ook komen door checksum offloading van je NIC. Kan je in pfsense uitzetten. Tcpdump krijgt dan namelijk niet juiste checksum door.

Dat de STB de eerste storing overleeft zag ik ook altijd (maar bij mij pas na 5 minuten) en de tweede (na nog eens 5 minuten) niet. Dat lijkt dus een standaard ding van de STB te zijn. Probeer het na eerste storing echt nog even helemaal opnieuw maar na twee storingen geeft ie het blijkbaar op.

Ik mis in je rechter plaatje even alle source en destinations. Welke paketten komen van de STB bijv.

En check even of de timestamps matchen. Ik heb het idee van niet.

Overigens, leave groups heb ik nooit gezien bij mijn storing. Het was dan bij mij ook dat KPN besloot te stoppen (na 5 minuten) met de stream doordat hij mijn group reports negeerde.

woensdag 18 januari 2023 23:11

Acties:
  • +1 Henk 'm!
  • ik222
  • Registratie: Maart 2007
  • Niet online

ik222

Topicstarter
@stormfly Dat ziet er inderdaad goed uit. Ik zou dan de switch verdenken, want je log laat duidelijk zien dat je IGMP berichten mist, al dan niet omdat ze corrupt zijn.

De leave is in elk geval simpelweg een gevolg van het feit dat de IGMP Proxy geen membership reports meer binnen krijgt en ook geen antwoord krijgt op zijn queries of er nog clients zijn op die groep.

woensdag 18 januari 2023 23:20

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ben het volledig eens met deze analyse. Igmpproxy ziet geen downstream hosts. Ziet wel de multicast opgestart worden door kpn iptv (waarschijnlijk door een unicast verzoek van de stb gaat dit nog voor een join overkomt al starten).
De igmp joins van de stb lijken niet over te komen.

woensdag 18 januari 2023 23:21

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Zet eventueel even hardware checksum uit in pfsense:
System - Advanced - Networking - Hardware Checksum Offloading

woensdag 18 januari 2023 23:35

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
ik222 schreef op woensdag 18 januari 2023 @ 23:11:
@stormfly Dat ziet er inderdaad goed uit. Ik zou dan de switch verdenken, want je log laat duidelijk zien dat je IGMP berichten mist, al dan niet omdat ze corrupt zijn.
Eens dit is wel de rode draad.
De leave is in elk geval simpelweg een gevolg van het feit dat de IGMP Proxy geen membership reports meer binnen krijgt en ook geen antwoord krijgt op zijn queries of er nog clients zijn op die groep.
Wat jij zegt is dat het op mijn LAN al mis gaat. Capture is van pfSense OS, feitelijk nog niet het échte LAN. Ik ga morgen met een fris hoofd dit artikel eens doornemen. Waar jij op doelt is dat de proxy vraagt of er nog clients luisteren in die groep met een "Membership report group a.b.c.d"?
thehog schreef op woensdag 18 januari 2023 @ 23:21:
Zet eventueel even hardware checksum uit in pfsense:
System - Advanced - Networking - Hardware Checksum Offloading
Die stond al uit, heb hem net aangezet maar dan blijft hij corrupte checksums zien. Morgen verder zoeken op de UniFi switch. Ik heb ook de UTP direct in de router gehad afgelopen weken, ben nu vooral benieuwd wat het uitmaakt qua IGMP traffic. Vanmorgen liep het met de ExperiaBox goed over de bestaande bekabeling, dus dat is het ook niet op laag 1.
thehog schreef op woensdag 18 januari 2023 @ 23:09:

Dat de STB de eerste storing overleeft zag ik ook altijd (maar bij mij pas na 5 minuten) en de tweede (na nog eens 5 minuten) niet. Dat lijkt dus een standaard ding van de STB te zijn. Probeer het na eerste storing echt nog even helemaal opnieuw maar na twee storingen geeft ie het blijkbaar op.
Eens ik zie exact hetzelfde gedrag hier.
Ik mis in je rechter plaatje even alle source en destinations. Welke paketten komen van de STB bijv.
Morgen maak ik even een nieuwe capture, wil eigenlijk ook bij de STB capturen omdat daar de focus ligt.
En check even of de timestamps matchen. Ik heb het idee van niet.
Niet op de seconden, in mijn beleving scheelt een seconde of 5. Komt omdat de captures gemaakt zijn op verschillende apparaten.
Overigens, leave groups heb ik nooit gezien bij mijn storing. Het was dan bij mij ook dat KPN besloot te stoppen (na 5 minuten) met de stream doordat hij mijn group reports negeerde.
Dat is de bevestiging dat KPN zelf door blijft sturen, wat een goede keuze is om eens een IGMP pakket te missen. Bij mij stopt KPN met sturen om dat mijn IGMP proxy een leave stuurt op het WAN.

Morgen eens fris een capture maken met alle default KPN apparatuur, dan weet ik wat jullie ook al weten over IGMP verkeer. Blijkbaar mis ik een groot aantal joins die ik zelf niet had opgemerkt.

Iemand nog tips om een Arris 5202 (4K plat model) helemaal, maar dan helemaal te voorzien van een reset? Heb gisteren al de fabrieksinstellingen geactiveerd, maar kwam niet tot het activatiemenu. Er blijft ergens nog iets staan zoals een naam "Woonkamer" etc.

woensdag 18 januari 2023 23:42

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Focus vooral op de igmp join van de STB. Die zien we nu nergens. Een tcpdump van de pfsense iptv-lan poort zou die joins moeten laten zien met source IP van de STB, en dan zien je ze ook in de igmpproxy log.

Kan zijn dat je unify switch te veel igmp beperkt (igmp snooping wil je opzich wel aan hebben voor je iptv lan maar alle andere functies uit, want igmp proxy is je querier). Wel gek dat het met de EB wel werkt. Als het echt niet werkt, zet alles qua igmp snooping in je iptv lan even helemaal uit. Je vlan beperkt toch wel de multicast immers toch waarschijnlijk maar 1 poort :)

En gooi voor de grap de STB eens in je normale LAN (nadat je igmpproxy even hebt geleerd dat er een andere downstream net is).

donderdag 19 januari 2023 10:58

Acties:
  • +1 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
@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

Afbeeldingslocatie: https://tweakers.net/i/NGrCzJm2o4_32BCo8fGqUE_1BDM=/800x/filters:strip_exif()/f/image/owoe6iSSxq9Vivhm0IHLVH9r.png?f=fotoalbum_large


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?

Afbeeldingslocatie: https://tweakers.net/i/q8XsXNBRcTrJcGZTjcuRJotR7_w=/800x/filters:strip_exif()/f/image/us3mbyRzx4FX5cHMlNP8ECbL.png?f=fotoalbum_large


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.

Afbeeldingslocatie: https://tweakers.net/i/fr8axVQRwc3Q_MqNCR0Z7q7ZrBg=/800x/filters:strip_exif()/f/image/onY2eo8rpZIF0TaNhW6m8tvX.png?f=fotoalbum_large

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 ]

donderdag 19 januari 2023 11:13

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

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.

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

donderdag 19 januari 2023 11:37

Acties:
  • 0 Henk 'm!
  • ik222
  • Registratie: Maart 2007
  • Niet online

ik222

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

donderdag 19 januari 2023 12:14

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
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.
Afbeeldingslocatie: https://tweakers.net/i/eslMEB0hxhDFjPdoOIk9vlZIXw4=/800x/filters:strip_exif()/f/image/TA8kxbQjmpWERuYY9iIyFqIZ.png?f=fotoalbum_large

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 _/-\o_
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 8)7 de eerste 3 zijn gewoon goed. Alles in het geel is corrupt...

Afbeeldingslocatie: https://tweakers.net/i/FDkgVmZwnqItaVs_Xe9o4y3HxWk=/800x/filters:strip_exif()/f/image/Qja2DQ2keAcu2wbH1ZkekV1P.png?f=fotoalbum_large

donderdag 19 januari 2023 12:15

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

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

Afbeeldingslocatie: https://tweakers.net/i/g5nzgli3yR9nJuvndwQWraJVX2Y=/800x/filters:strip_exif()/f/image/quYnOtWIS4xbApENsrNKMTZS.png?f=fotoalbum_large

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

donderdag 19 januari 2023 12:40

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

4 seconden later is niet echt 'direct' antwoord van de STB op de query hoor :)
Ik denk dat het meer toevallig is. edit: volgens de query mag de reporter er 10 seconden over doen... dus klopt wel

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.

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.

[ Voor 23% gewijzigd door thehog op 19-01-2023 12:46 ]

donderdag 19 januari 2023 13:11

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op donderdag 19 januari 2023 @ 12:40:
4 seconden later is niet echt 'direct' antwoord van de STB op de query hoor :)
Ik denk dat het meer toevallig is. edit: volgens de query mag de reporter er 10 seconden over doen... dus klopt wel
Op een geven moment grijp je alles vast he ;)
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.

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.
Ja ga ik even uitvogelen want in de webgui is het wat lastiger, ik moet even de juiste cli syntax opzoeken ervoor. Inmiddels mijn topic op het pfSense forum bijgewerkt, hoop dat ze reageren.




Net nog even VYOS geboot en daar loop ik in een ander issue, de multicast stream komt niet op gang. Daar gaan de IGMP Paketten wel goed _/-\o_ aan de LAN zijde geen corruptie.

@thehog had jij hier niet een theorie over qua snooping in proxmox wel/niet noodzakelijk? Het is een proxmox VM waarbij de NIC zelf vlantagging doet. Zodat het QoS Priority veld intact blijft.


code:
1
2
3
4

root@pve:~# cat startup.sh
#!/bin/sh
echo 1 > /sys/class/net/vmbr0/bridge/multicast_snooping
echo 0 > /sys/class/net/vmbr0/bridge/multicast_router


Het lijkt erop dat ik van VYOS de IGMP paketten niet op het WAN terug zie :'( Er is wel L2 verbinding _/-\o_ want arp werkt. Dat moet ik vanavond nog even verder onderzoeken. Kijken of alle VLANs op het wan wel goed staan, kan bijna niet fout staan want dan had ik geen WAN IP ontvangen via DHCP.

Dus blijft over IGMP snooping in proxmox of IGMP issues met de proxy.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

vyos@STBRTR:~$ show arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.81.240.1              ether   d8:49:0b:b7:2e:21   C                     eth2.4


vyos@STBRTR:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* 0.0.0.0/0 [1/0] via 172.16.1.1, eth0, weight 1, 00:06:57
C>* 10.81.240.0/22 is directly connected, eth2.4, 00:07:04
C>* 172.16.1.0/24 is directly connected, eth0, 00:07:08
C>* 172.16.25.0/24 is directly connected, eth1.25, 00:07:09
S>* 213.75.112.0/21 [1/0] via 10.81.240.1, eth2.4, weight 1, 00:06:13
S   213.75.112.0/21 [250/0] via 10.81.240.1, eth2.4, weight 1, 00:06:52

vyos@STBRTR:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             172.16.1.235/24                   u/u  LAN
                 2a02:a469:/64

eth1             -                                 u/u
eth1.25          172.16.25.1/24                    u/u  STB
                 2a02:a469:/64

eth2             -                                 u/u
eth2.4           10.81.240.17/22                   u/u  IPTV
lo               127.0.0.1/8                       u/u
                 ::1/128

donderdag 19 januari 2023 13:35

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

stormfly schreef op donderdag 19 januari 2023 @ 13:11:
[...]


@thehog had jij hier niet een theorie over qua snooping in proxmox wel/niet noodzakelijk? Het is een proxmox VM waarbij de NIC zelf vlantagging doet. Zodat het QoS Priority veld intact blijft.


code:
1
2
3
4

root@pve:~# cat startup.sh
#!/bin/sh
echo 1 > /sys/class/net/vmbr0/bridge/multicast_snooping
echo 0 > /sys/class/net/vmbr0/bridge/multicast_router
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.

edit: ik heb overigens m'n pfsense aan twee directe pci passthrough nics hangen momenteel. Niet meer geprobeerd om het naar een virtuele nic te gooien want het werkt nu :)

[ Voor 10% gewijzigd door thehog op 19-01-2023 13:43 ]

donderdag 19 januari 2023 14:56

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
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.
Eens dat ben ik met je eens, alleen bleek snooping de oorzaak van het niet kunnen starten van een stream de vorige keer. Toen heb ik dat startup scriptje in elkaar gefröbeld.
edit: ik heb overigens m'n pfsense aan twee directe pci passthrough nics hangen momenteel. Niet meer geprobeerd om het naar een virtuele nic te gooien want het werkt nu :)
Ja dat had ik ook en werkte top, totdat die VM's steeds uitvielen met die N5105 problemen en QEMU/Proxmox 8)7

donderdag 19 januari 2023 15:00

Acties:
  • 0 Henk 'm!
  • Charlie_Root
  • Registratie: November 2018
  • Laatst online: 29-06 14:06

Charlie_Root

stormfly schreef op donderdag 19 januari 2023 @ 13:11:



Net nog even VYOS geboot en daar loop ik in een ander issue, de multicast stream komt niet op gang. Daar gaan de IGMP Paketten wel goed _/-\o_ aan de LAN zijde geen corruptie.

@thehog had jij hier niet een theorie over qua snooping in proxmox wel/niet noodzakelijk? Het is een proxmox VM waarbij de NIC zelf vlantagging doet. Zodat het QoS Priority veld intact blijft.


code:
1
2
3
4

root@pve:~# cat startup.sh
#!/bin/sh
echo 1 > /sys/class/net/vmbr0/bridge/multicast_snooping
echo 0 > /sys/class/net/vmbr0/bridge/multicast_router


Het lijkt erop dat ik van VYOS de IGMP paketten niet op het WAN terug zie :'( Er is wel L2 verbinding _/-\o_ want arp werkt. Dat moet ik vanavond nog even verder onderzoeken. Kijken of alle VLANs op het wan wel goed staan, kan bijna niet fout staan want dan had ik geen WAN IP ontvangen via DHCP.

Dus blijft over IGMP snooping in proxmox of IGMP issues met de proxy.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

vyos@STBRTR:~$ show arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.81.240.1              ether   d8:49:0b:b7:2e:21   C                     eth2.4


vyos@STBRTR:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* 0.0.0.0/0 [1/0] via 172.16.1.1, eth0, weight 1, 00:06:57
C>* 10.81.240.0/22 is directly connected, eth2.4, 00:07:04
C>* 172.16.1.0/24 is directly connected, eth0, 00:07:08
C>* 172.16.25.0/24 is directly connected, eth1.25, 00:07:09
S>* 213.75.112.0/21 [1/0] via 10.81.240.1, eth2.4, weight 1, 00:06:13
S   213.75.112.0/21 [250/0] via 10.81.240.1, eth2.4, weight 1, 00:06:52

vyos@STBRTR:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             172.16.1.235/24                   u/u  LAN
                 2a02:a469:/64

eth1             -                                 u/u
eth1.25          172.16.25.1/24                    u/u  STB
                 2a02:a469:/64

eth2             -                                 u/u
eth2.4           10.81.240.17/22                   u/u  IPTV
lo               127.0.0.1/8                       u/u
                 ::1/128
toon volledige bericht
Hoe ziet je configuratie op VyOS er uit? Heb je alle interfaces geconfigureerd (ook als ze niets doen; role disabled) met upstream/downstream en een juiste whitelist? Het begon mij bij (ook VyOS) pas te werken nadat ik alle interfaces toevoegde.

The cause of the problem is: network down, IP packets delivered via UPS | AbuseDB

donderdag 19 januari 2023 15:07

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Charlie_Root schreef op donderdag 19 januari 2023 @ 15:00:
[...]


Hoe ziet je configuratie op VyOS er uit? Heb je alle interfaces geconfigureerd (ook als ze niets doen; role disabled) met upstream/downstream en een juiste whitelist? Het begon mij bij (ook VyOS) pas te werken nadat ik alle interfaces toevoegde.
Yes dat heb ik met de handmatige proxystart zeker meegenomen, zal het nog even in de config checken. Als je de interfaces default laat heb je mogelijk het effect dat je te veel IGMP joins naar het WAN to verstuurd, vanuit diverse LAN's zoals @ thehog heeft onderzocht in posts van deze maand.

[ Voor 3% gewijzigd door stormfly op 19-01-2023 15:07 ]

donderdag 19 januari 2023 15:16

Acties:
  • 0 Henk 'm!
  • Charlie_Root
  • Registratie: November 2018
  • Laatst online: 29-06 14:06

Charlie_Root

Mijn config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

interface eth0 {
     role disabled
     threshold 1
 }
 interface eth1 {
     role disabled
     threshold 1
 }
 interface eth2 {
     role disabled
     threshold 1
 }
 interface eth3 {
     role disabled
     threshold 1
 }
 interface eth3.4 {
     alt-subnet 0.0.0.0/0
     role upstream
     threshold 1
 }
 interface eth3.6 {
     role disabled
     threshold 1
 }
[...]
 interface switch0.X {
     role disabled
     threshold 1
 }
 interface switch0.X {
     role disabled
     threshold 1
 }
 interface switch0.X {
     alt-subnet 0.0.0.0/0
     role downstream
     threshold 1
     whitelist 239.0.3.0/16
     whitelist 225.0.71.0/24
     whitelist 224.0.0.0/16
 }


Ik kan bevestigen dat dit werkt, mits alle tussenliggende switches snooping aan hebben staan, ik gebruik het op deze wijze al +/- 6 maanden zonder problemen.

The cause of the problem is: network down, IP packets delivered via UPS | AbuseDB

donderdag 19 januari 2023 21:22

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
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 _/-\o_

Dit is van net, op pfSense gecaptured op de LAN interface, zappend over 3 kanalen. |:(
Afbeeldingslocatie: https://tweakers.net/i/mbg2-73GRAX_78E2pFADwKhOdpc=/800x/filters:strip_exif()/f/image/7L29K9XzJn5eNNnvCd9ZJAXU.png?f=fotoalbum_large
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.

Afbeeldingslocatie: https://tweakers.net/i/_h316V-P0jPwnOM8Mabb7pe0qX0=/800x/filters:strip_exif()/f/image/9oiyA5y6a1xYdf91YslQ1XTt.png?f=fotoalbum_large


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]
toon volledige bericht

donderdag 19 januari 2023 21:55

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

@stormfly als je igmp snooping uit moet zetten in de proxmox virtual bridge dan is er serieus wat mis. Dat betekend dat er ergens wat mis gaat met igmp de juiste kant op te sturen, wellicht de querier die via twee kanten binnen komt ofzoiets. Maar dat is pas beter te beoordelen als je exact uitlegd welke fysieke interface in welke virtual bridge zit en hoe deze dan aan vyos/pfsense worden gepresenteerd inclusief vlans.

Maar uitzetten kan ook niet zo veel kwaad. Het is toch allemaal virtueel verkeer en dat een paar vm's iets meer multicast krijgen gaan ze echt niet veel last van hebben.

donderdag 19 januari 2023 22:11

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op donderdag 19 januari 2023 @ 21:55:
@stormfly als je igmp snooping uit moet zetten in de proxmox virtual bridge dan is er serieus wat mis. Dat betekend dat er ergens wat mis gaat met igmp de juiste kant op te sturen, wellicht de querier die via twee kanten binnen komt ofzoiets. Maar dat is pas beter te beoordelen als je exact uitlegd welke fysieke interface in welke virtual bridge zit en hoe deze dan aan vyos/pfsense worden gepresenteerd inclusief vlans.
Het is een intel NUC met welgeteld 1 fysieke interface, deze zit in de proxmox bridge inclusief vlantagging. Daarin zitten een handvol VM's in diverse VLANs. Het mgmt van proxmox zelf verloopt ook via de bridge en heeft een IP adres in het untagged vlan 1.

Maar ik zou het graag netter inrichten, en net als jij tot de bodem willen zoeken waarom dat nu niet goed werkt.

In VYOS zijn het 3 virtuele NIC's, waarbij de vlantagging wordt gedaan door VYOS zelf eth2.4 etc. Daar draait de IGMP proxy ook op tussen vlan 4 en 25.

Dan is het vrij simpel en gaat het naar een UniFi switch, en aan die switch zit pfSense met een LAN poort.

When an IGMPv2 device receives a general query message, the device compares the source IP address in the message with its own interface address. The device with the lowest IP address on the subnet is elected the IGMP querier.

Hmmm dan zou je in theorie toch niet meerdere queriers kunnen hebben op 1 LAN, hooguit dan vanuit meerdere VLANs.
Maar uitzetten kan ook niet zo veel kwaad. Het is toch allemaal virtueel verkeer en dat een paar vm's iets meer multicast krijgen gaan ze echt niet veel last van hebben.
Het STB vlan bevat alleen de STB en de Vyos VM, relatief weinig impact op het VM cluster van het uitschakelen van IGMP snooping.

vrijdag 20 januari 2023 10:31

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

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

Afbeeldingslocatie: https://tweakers.net/i/1j0gCz3jB9cJ0RZ4aZ3l0ndZOBs=/800x/filters:strip_exif()/f/image/LULpGjkPTG6R2NiPWxvxInwX.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/SiPpPZEd_Ra6qj3CeUOJL0QqRjc=/800x/filters:strip_exif()/f/image/EE9aVQCtm8sVqhIVgWMDXiOR.png?f=fotoalbum_large

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.

Afbeeldingslocatie: https://tweakers.net/i/yHHWhGMaMc_BUXmzrqutXFbJyr8=/800x/filters:strip_exif()/f/image/s7PrTP0iaYvRc33SbOhQXFol.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/ZyGCffvUvCVeuArto0DbGs8-VD8=/800x/filters:strip_exif()/f/image/0hsqtnMB3Ajb6Y7nXrI9KVqT.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/i_wTWfKv-NRJs9xmZDbKvO8WW6Y=/800x/filters:strip_exif()/f/image/TFZP7rSoBvYESRapr6kbb3g0.png?f=fotoalbum_large

vrijdag 20 januari 2023 11:42

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ik ga vanavond wel even upgraden naar 23.01 (na het maken van een snapshot). Kijken wat dat opleverd.

vrijdag 20 januari 2023 12:33

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Ja de samenvatting van afgelopen week is als volgt:

VYOS op proxmox was een beheerders foutje op de bridge, ik had het startup script niet alleen uncommented maar ook van 0 naar 1 aangepast. Waardoor ik dat bij heractivering over het hoofd zag, en snooping alle joins dropte.

pfSense 23.01 heeft op de N5105 en i-226v een forwarding issue, de streams komen goed door op multicast maar blijven niet stabiel

UniFi switch heeft een bijzonder igmp snooping probleem. Net via het UI formum wat testen gedaan met oudere releases in vlan 25 (vyos) en dat gaat allemaal probleemloos. Ik dacht dat ik een klap van de molenwiek had gekregen, totdat ik de STB weer omzette naar van 26 (pfSense) en daar was direct het probleem weer zicht baar. Beide zijn trunked porten met alle VLAN's ik doorgrond nog niet waarom die switch IGMP joins gaat droppen zodra ik dat op de port naar pfSense meet met met mijn inline capture switch.


Nogal veel tegelijk wat wankelt, vandaar ook het uitblijven van een snelle oplossing. Voor dit weekend kijken we lekker via VYOS en VLAN 25 wat prima verloopt ;-)


Ben benieuwd of jouw streams ook sluggy worden <5 minuten. De STB meet het ook en gaat dan een leave en join versturen 2 maal...en dan de bekende foutmelding.

vrijdag 20 januari 2023 18:42

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

Ik ga toch maar even niet upgraden naar (plus) 23.01. Mijn multicast group patch zit daar natuurlijk nog niet in en dan moet ik dat weer allemaal handmatig toevoegen. Zit nu nog op CE 2.6.0

vrijdag 20 januari 2023 19:49

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
thehog schreef op vrijdag 20 januari 2023 @ 18:42:
Ik ga toch maar even niet upgraden naar (plus) 23.01. Mijn multicast group patch zit daar natuurlijk nog niet in en dan moet ik dat weer allemaal handmatig toevoegen. Zit nu nog op CE 2.6.0
Begrijpelijk, ik laat het ook even voor wat het is tot 23.01 helemaal uitgebracht is. UniFi en igmp snooping staat niet vermeld in de datasheets als feature, daardoor kan ik niet herleiden of het zou moeten werken op deze switches.

Port A met pfSense tagged VLAN 26 laat geen IGMP joins door
Port B met VYOS tagged tagged VLAN 25 laat wel IGMP joins door.

Beide VLAN's zijn gelijkwaardig ingesteld, en bij het uitschakelen van igmp snooping op vlan 26 gaat de stream direct weer lopen. Alleen zakt hij dan in qua performance door naar wat ik nu inschat; de laatste pfSense beta upgrade. Heb ook nog een andere UniFi switch gepakt en daarmee getest, exact 100% hetzelfde effect. Deze switch was factory resetted. Het suffe is ook nog dat ik in beide gevallen in dezelfde richting snif, zowel 25 al 26 die gaan beide naar een willekeurig devices toe.

Ga weer even genieten van de TV via VYOS dank voor al je hulp! En als het anders wordt/is met 23.01 qua traagheid laat ik het weten.

Kende je deze al: https://forum.netgate.com...il-alerts?_=1674240434181

zaterdag 21 januari 2023 15:44

Acties:
  • 0 Henk 'm!
  • supayoshi
  • Registratie: November 2013
  • Laatst online: 29-06 17:07

supayoshi

Beste Stormfly,

Ik ben blij dat ik me al een tijdje aan je vorderingen in het oplossen van problemen met OPNsense en IPTV van KPN kan vermaken. Helaas ervaar ik ook deze problemen.

Ik ben erg geïnteresseerd in de resultaten van de testen en bevindingen die je bijna iedere dag nu hier deelt. Helaas mis ik nu nog een stapsgewijze instructie voor het implementeren van de oplossing op mijn OPNsense router. Is het mogelijk om een stapsgewijze handleiding te maken voor het implementeren van de oplossing, inclusief whitelists voor igmp proxy, zodat ik zeker weet dat ik alles juist instel?

Met vriendelijke groet,

SupaYoshi
stormfly schreef op vrijdag 20 januari 2023 @ 19:49:
[...]


Begrijpelijk, ik laat het ook even voor wat het is tot 23.01 helemaal uitgebracht is. UniFi en igmp snooping staat niet vermeld in de datasheets als feature, daardoor kan ik niet herleiden of het zou moeten werken op deze switches.

Port A met pfSense tagged VLAN 26 laat geen IGMP joins door
Port B met VYOS tagged tagged VLAN 25 laat wel IGMP joins door.

Beide VLAN's zijn gelijkwaardig ingesteld, en bij het uitschakelen van igmp snooping op vlan 26 gaat de stream direct weer lopen. Alleen zakt hij dan in qua performance door naar wat ik nu inschat; de laatste pfSense beta upgrade. Heb ook nog een andere UniFi switch gepakt en daarmee getest, exact 100% hetzelfde effect. Deze switch was factory resetted. Het suffe is ook nog dat ik in beide gevallen in dezelfde richting snif, zowel 25 al 26 die gaan beide naar een willekeurig devices toe.

Ga weer even genieten van de TV via VYOS dank voor al je hulp! En als het anders wordt/is met 23.01 qua traagheid laat ik het weten.

Kende je deze al: https://forum.netgate.com...il-alerts?_=1674240434181
toon volledige bericht

zaterdag 21 januari 2023 20:22

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
supayoshi schreef op zaterdag 21 januari 2023 @ 15:44:
Beste Stormfly,

Ik ben blij dat ik me al een tijdje aan je vorderingen in het oplossen van problemen met OPNsense en IPTV van KPN kan vermaken. Helaas ervaar ik ook deze problemen.

Ik ben erg geïnteresseerd in de resultaten van de testen en bevindingen die je bijna iedere dag nu hier deelt. Helaas mis ik nu nog een stapsgewijze instructie voor het implementeren van de oplossing op mijn OPNsense router. Is het mogelijk om een stapsgewijze handleiding te maken voor het implementeren van de oplossing, inclusief whitelists voor igmp proxy, zodat ik zeker weet dat ik alles juist instel?

Met vriendelijke groet,

SupaYoshi


[...]
toon volledige bericht
Ik had last van 3 problemen, welke problemen ervaar jij? Heb je jouw omgeving opgezet met een apart vlan voor de STB zoals in de startpost zichtbaar?

De whitelist optie is vrij complex als dat jou op dit moment geen belletje doet rinkelen. Wat mogelijk overzichtelijker is om 1 apart vlan aan te maken in je netwerk voor de STB, dan heb de whitelists niet nodig als je daarna de IGMP proxy instelt zoals in de startpost, inclusief screenshots, is vermeld.

[ Voor 27% gewijzigd door stormfly op 21-01-2023 20:26 ]

zaterdag 21 januari 2023 21:11

Acties:
  • +1 Henk 'm!
  • supayoshi
  • Registratie: November 2013
  • Laatst online: 29-06 17:07

supayoshi

Ik gebruik idd een apart vlan voor de STB's. Alleen heb ik toch regelmatig de NMB-400 meldingen / wegvallend beeld. / vastlopende streams. herstart igmpproxy helpt dan vaak wel weer een tijdje.

Edit; ach nvm ik had gewoon igmp snooping uistaan in de switch, fixed.

[ Voor 32% gewijzigd door supayoshi op 21-01-2023 21:23 ]

zaterdag 21 januari 2023 22:26

Acties:
  • 0 Henk 'm!
  • thehog
  • Registratie: Oktober 2000
  • Laatst online: 29-06 11:15

thehog

supayoshi schreef op zaterdag 21 januari 2023 @ 21:11:
Ik gebruik idd een apart vlan voor de STB's. Alleen heb ik toch regelmatig de NMB-400 meldingen / wegvallend beeld. / vastlopende streams. herstart igmpproxy helpt dan vaak wel weer een tijdje.

Edit; ach nvm ik had gewoon igmp snooping uistaan in de switch, fixed.
Dat zou opzich voor de stream niks uit moeten maken. Als het uitstaat komt alle multicast gewoon door als broadcast. Dus op alle devices. Maar ja als het nu werkt.. 😉

vrijdag 27 januari 2023 21:22

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Vandaag de nieuwe KPN TV+ (android TV) aangesloten op mijn pfSense netwerk.

Het lijkt er op dat TV kijken nu via internet loopt in plaats van de IPTV interface op mijn pfSense.

Iemand anders die gelijke ervaringen heeft?

Wanneer ik van het weekend tijd heb ga ik de IGMP proxy uitschakelen en de IPTV-WAN vlan interface disablen en zal ik laten weten of alles nog werkt.

Dit zou de pfSense set-up een stuk eenvoudiger moeten maken in de toekomst.

vrijdag 27 januari 2023 21:30

Acties:
  • +1 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op vrijdag 27 januari 2023 @ 21:22:
Vandaag de nieuwe KPN TV+ (android TV) aangesloten op mijn pfSense netwerk.

Het lijkt er op dat TV kijken nu via internet loopt in plaats van de IPTV interface op mijn pfSense.

Iemand anders die gelijke ervaringen heeft?

Wanneer ik van het weekend tijd heb ga ik de IGMP proxy uitschakelen en de IPTV-WAN vlan interface disablen en zal ik laten weten of alles nog werkt.

Dit zou de pfSense set-up een stuk eenvoudiger moeten maken in de toekomst.
Op het KPN forum en in hun KB artikelen staat dat multicast nodig is. Kan je eens een tcpdump maken als je 2 minuten de tv op een zender hebt laten draaien?

Zonder dat ik dat gelezen had dacht ik aan de NEXT mini welke unicast only lijkt. Blijkbaar doet KPN het anders.

Kan jij ons verlossen met feiten?

tcpdump -i igc0 voor bijvoorbeeld je LAN en dan hier de compacte output delen.

Multicast verkeer:
code:
1
2
3
4
5
6
7
8

21:33:23.774644 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 366
21:33:23.801731 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 322
21:33:24.335144 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 366
21:33:24.461223 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 372
21:33:24.795120 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 354
21:33:24.799120 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 328
21:33:24.942266 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 370
21:33:24.968359 IP 213-75-167-58.dc.kpn.net.45566 > 224.3.2.6.9875: UDP, length 366


Unicast verkeer:
code:
1
2
3
4
5
6
7

21:33:57.020246 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.021794 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.023151 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.024713 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.026115 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.027711 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328
21:33:57.029083 IP 213-75-113-13.dc.kpn.net.10000 > 172.16.25.41.3604: UDP, length 1328



Geluid: Wel en geen Dolby bij live kijken (multicast) versus Terugkijken/Opnames (unicast)

Zoals al eerder aangegeven is dit iets dat bekend is. Ik heb hier nu iets meer informatie over.

Voor het live kijken gebruiken we streams die gelijk zijn aan degene voor de andere ontvangers. Deze ondersteunen Dolby en geven dat dus ook door als een zender dat uitzend.

De streams die we gebruiken voor unicast, dus het kijken van opnames, of het Terugkijken van programma's ondersteunen op het moment nog geen Dolby. We hebben op het moment nog een technische beperking waardoor we Dolby (AC3) nog niet kunnen aanzetten voor de TV+ unicast streams. Er wordt dus op dit moment gewerkt om die beperking op te lossen. Zodra dat gedaan is, kunnen we verder met de aanpassing van de unicast streams om daar Dolby ondersteuning op te activeren.

Helaas heb ik daar nog geen verwachte datum voor. Zodra we daar meer over weten komen we het melden. Ik voeg dit ook even toe aan de veelgestelde vragen in het startbericht.

[ Voor 63% gewijzigd door stormfly op 27-01-2023 21:55 ]

zaterdag 28 januari 2023 09:05

Acties:
  • +1 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

tcpdump -i em1.10 host 192.168.10.41

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

09:04:23.969647 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10290179:10291631, ack 6184, win 16383, length 1452
09:04:23.969756 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10291631:10293083, ack 6184, win 16383, length 1452
09:04:23.969769 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10293083:10294535, ack 6184, win 16383, length 1452
09:04:23.969867 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10291631, win 24564, length 0
09:04:23.969993 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10294535, win 24564, length 0
09:04:23.970008 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10294535:10295987, ack 6184, win 16383, length 1452
09:04:23.970021 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10295987:10297439, ack 6184, win 16383, length 1452
09:04:23.970132 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10297439:10298891, ack 6184, win 16383, length 1452
09:04:23.970144 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10298891:10300343, ack 6184, win 16383, length 1452
09:04:23.970242 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10297439, win 24564, length 0
09:04:23.970383 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10300343:10301795, ack 6184, win 16383, length 1452
09:04:23.970395 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10301795:10303247, ack 6184, win 16383, length 1452
09:04:23.970492 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10300343, win 24564, length 0
09:04:23.970617 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10303247, win 24564, length 0
09:04:23.970634 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10303247:10304699, ack 6184, win 16383, length 1452
09:04:23.970645 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10304699:10306151, ack 6184, win 16383, length 1452
09:04:23.970756 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10306151:10307603, ack 6184, win 16383, length 1452
09:04:23.970769 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10307603:10309055, ack 6184, win 16383, length 1452
09:04:23.970868 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10306151, win 24564, length 0
09:04:23.970994 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10309055, win 24564, length 0
09:04:23.971009 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10309055:10310507, ack 6184, win 16383, length 1452
09:04:23.971021 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10310507:10311959, ack 6184, win 16383, length 1452
09:04:23.971132 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10311959:10313411, ack 6184, win 16383, length 1452
09:04:23.971145 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10313411:10314863, ack 6184, win 16383, length 1452
09:04:23.971243 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10311959, win 24564, length 0
09:04:23.971382 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10314863:10316315, ack 6184, win 16383, length 1452
09:04:23.971493 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10314863, win 24564, length 0
09:04:23.971509 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [P.], seq 10316315:10316451, ack 6184, win 16383, length 136
09:04:23.971618 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10316451, win 24564, length 0


tcpdump -i em1.10 net 213.75.0.0/16

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


tcpdump -i em1.10 net 10.0.0.0/8

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


tcpdump -i em1.10 net 217.166.0.0/16

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


tcpdump -i em1.10 net 217.160.0.0/16

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


tcpdump -i em1.10 net 239.0.0.0/8

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes
09:18:53.404239 IP 192.168.10.89.36575 > 239.255.255.250.ssdp: UDP, length 125
09:18:53.524169 IP 192.168.10.41.10101 > 239.255.255.251.10101: UDP, length 38
09:18:54.891867 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:18:54.893116 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:18:54.893239 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:18:54.894615 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:18:56.041316 IP 192.168.10.35 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:56.042565 IP 192.168.10.35 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:56.042815 IP 192.168.10.35 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:56.044064 IP 192.168.10.35 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:58.877654 IP 192.168.10.105 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:58.878920 IP 192.168.10.105 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:58.880277 IP 192.168.10.105 > 239.255.255.250: igmp v2 report 239.255.255.250
09:18:58.881919 IP 192.168.10.105 > 239.255.255.250: igmp v2 report 239.255.255.250
09:19:01.294616 IP 192.168.10.41 > 239.255.3.22: igmp v2 report 239.255.3.22
09:19:01.547963 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:19:01.549212 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:19:01.549230 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:19:01.550586 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:19:02.793361 IP 192.168.10.89.45839 > 239.255.255.250.ssdp: UDP, length 125
09:19:03.093931 IP 192.168.10.89.45839 > 239.255.255.250.ssdp: UDP, length 125
09:19:03.394754 IP 192.168.10.89.45839 > 239.255.255.250.ssdp: UDP, length 125


tcpdump -i em1.10 src net 239.0.0.0/8

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes

[ Voor 27% gewijzigd door Remie op 28-01-2023 09:26 . Reden: Meerdere keren nieuwe packet captures toegevoegd ]

zaterdag 28 januari 2023 09:16

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op zaterdag 28 januari 2023 @ 09:05:
tcpdump -i em1.10 host 192.168.10.41

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

09:04:23.969647 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10290179:10291631, ack 6184, win 16383, length 1452
09:04:23.969756 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10291631:10293083, ack 6184, win 16383, length 1452
09:04:23.969769 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10293083:10294535, ack 6184, win 16383, length 1452
09:04:23.969867 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10291631, win 24564, length 0
09:04:23.969993 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10294535, win 24564, length 0
09:04:23.970008 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10294535:10295987, ack 6184, win 16383, length 1452
09:04:23.970021 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10295987:10297439, ack 6184, win 16383, length 1452
09:04:23.970132 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10297439:10298891, ack 6184, win 16383, length 1452
09:04:23.970144 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10298891:10300343, ack 6184, win 16383, length 1452
09:04:23.970242 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10297439, win 24564, length 0
09:04:23.970383 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10300343:10301795, ack 6184, win 16383, length 1452
09:04:23.970395 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10301795:10303247, ack 6184, win 16383, length 1452
09:04:23.970492 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10300343, win 24564, length 0
09:04:23.970617 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10303247, win 24564, length 0
09:04:23.970634 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10303247:10304699, ack 6184, win 16383, length 1452
09:04:23.970645 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10304699:10306151, ack 6184, win 16383, length 1452
09:04:23.970756 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10306151:10307603, ack 6184, win 16383, length 1452
09:04:23.970769 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10307603:10309055, ack 6184, win 16383, length 1452
09:04:23.970868 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10306151, win 24564, length 0
09:04:23.970994 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10309055, win 24564, length 0
09:04:23.971009 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10309055:10310507, ack 6184, win 16383, length 1452
09:04:23.971021 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10310507:10311959, ack 6184, win 16383, length 1452
09:04:23.971132 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10311959:10313411, ack 6184, win 16383, length 1452
09:04:23.971145 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10313411:10314863, ack 6184, win 16383, length 1452
09:04:23.971243 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10311959, win 24564, length 0
09:04:23.971382 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [.], seq 10314863:10316315, ack 6184, win 16383, length 1452
09:04:23.971493 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10314863, win 24564, length 0
09:04:23.971509 IP pedgewarer24b.wxs.nl.https > 192.168.10.41.52710: Flags [P.], seq 10316315:10316451, ack 6184, win 16383, length 136
09:04:23.971618 IP 192.168.10.41.52710 > pedgewarer24b.wxs.nl.https: Flags [.], ack 10316451, win 24564, length 0



tcpdump -i em1.10 net 213.75.0.0/16
code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes

tcpdump -i em1.10 net 10.0.0.0/8
code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


tcpdump -i em1.10 net 217.166.0.0/16

code:
1
2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1.10, link-type EN10MB (Ethernet), capture size 262144 bytes


~edit: Ik ben nog meer info aan het verzamelen met de multicast netwerken gedefinieerd in mijn igmp proxy
toon volledige bericht
Cool dat lijkt unicast verkeer, nog even wat vragen:

Zou je de volgende capture met -n willen nemen, dan resolved hij de DNS namen niet. Zo zie je sneller of het multicast is. We leuk dat de DNS naam erbij staat, die zal ik eens in smokeping zetten.

Mijn advies zou zijn om de net statements eraf te halen, we zijn juist op zoek naar de nieuwe locaties vanwaar de streams ontstaan.

Je hebt 3 verschillende streams bij KPN:
-LiveTV
-Uit de gids terugkijken (doorspoelen werkt dan niet)
-Uit de opnames terug kijken (doorspoelen werkt dan wel)

Welke capture is dit?

Enne: tnx! Dit is unicast verkeer:

code:
1
2
3
4

PING pedgewarer24b.wxs.nl (195.121.69.170): 56 data bytes
64 bytes from 195.121.69.170: icmp_seq=0 ttl=61 time=5.763 ms
64 bytes from 195.121.69.170: icmp_seq=1 ttl=61 time=6.765 ms
64 bytes from 195.121.69.170: icmp_seq=2 ttl=61 time=7.063 ms

[ Voor 3% gewijzigd door stormfly op 28-01-2023 09:17 ]

zaterdag 28 januari 2023 09:23

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Ok ik ben klaar met mijn vorige post.
Ik zal mijn eerste capture eens met -n draaien. Komt zo onder mijn post

tcpdump -n -i em1.10 host 192.168.10.41

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

09:23:38.249075 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4368437, win 24564, length 0
09:23:38.249200 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4371341, win 24564, length 0
09:23:38.249218 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4371341:4372793, ack 2260, win 16383, length 1452
09:23:38.249232 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4372793:4374245, ack 2260, win 16383, length 1452
09:23:38.249336 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4374245:4375697, ack 2260, win 16383, length 1452
09:23:38.249348 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4375697:4377149, ack 2260, win 16383, length 1452
09:23:38.249459 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4374245, win 24564, length 0
09:23:38.249574 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4377149, win 24564, length 0
09:23:38.249593 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4377149:4378601, ack 2260, win 16383, length 1452
09:23:38.249606 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4378601:4380053, ack 2260, win 16383, length 1452
09:23:38.249713 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4380053:4381505, ack 2260, win 16383, length 1452
09:23:38.249729 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4381505:4382957, ack 2260, win 16383, length 1452
09:23:38.249825 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4380053, win 24564, length 0
09:23:38.249949 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4382957, win 24564, length 0
09:23:38.249968 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4382957:4384409, ack 2260, win 16383, length 1452
09:23:38.249981 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4384409:4385861, ack 2260, win 16383, length 1452
09:23:38.250198 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4385861, win 24564, length 0
09:23:38.250219 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4385861:4387313, ack 2260, win 16383, length 1452
09:23:38.250233 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4387313:4388765, ack 2260, win 16383, length 1452
09:23:38.250337 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4388765:4390217, ack 2260, win 16383, length 1452
09:23:38.250350 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4390217:4391669, ack 2260, win 16383, length 1452
09:23:38.250588 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4391669:4393121, ack 2260, win 16383, length 1452
09:23:38.250601 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4393121:4394573, ack 2260, win 16383, length 1452
09:23:38.250699 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4391669, win 24564, length 0
09:23:38.250709 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4394573:4396025, ack 2260, win 16383, length 1452
09:23:38.250722 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4396025:4397477, ack 2260, win 16383, length 1452
09:23:38.250822 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4394573, win 24564, length 0
09:23:38.250947 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4397477, win 24564, length 0
09:23:38.250963 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4397477:4398929, ack 2260, win 16383, length 1452
09:23:38.250975 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4398929:4400381, ack 2260, win 16383, length 1452
09:23:38.251085 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4400381:4401833, ack 2260, win 16383, length 1452
09:23:38.251099 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4401833:4403285, ack 2260, win 16383, length 1452
09:23:38.251196 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4400381, win 24564, length 0
09:23:38.251336 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4403285:4404737, ack 2260, win 16383, length 1452
09:23:38.251348 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4404737:4406189, ack 2260, win 16383, length 1452
09:23:38.251584 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4406189:4407641, ack 2260, win 16383, length 1452
09:23:38.251596 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4407641:4409093, ack 2260, win 16383, length 1452
09:23:38.251710 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4409093:4410545, ack 2260, win 16383, length 1452
09:23:38.251722 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4410545:4411997, ack 2260, win 16383, length 1452
09:23:38.251959 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4411997:4413449, ack 2260, win 16383, length 1452
09:23:38.251973 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4413449:4414901, ack 2260, win 16383, length 1452
09:23:38.252085 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4414901:4416353, ack 2260, win 16383, length 1452
09:23:38.252097 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4416353:4417805, ack 2260, win 16383, length 1452
09:23:38.252334 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4417805:4419257, ack 2260, win 16383, length 1452
09:23:38.252346 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [.], seq 4419257:4420709, ack 2260, win 16383, length 1452
09:23:38.252459 IP 195.121.69.170.443 > 192.168.10.41.52710: Flags [P.], seq 4420709:4421907, ack 2260, win 16383, length 1198
09:23:38.252945 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4421907, win 24491, length 0
09:23:38.292676 IP 192.168.10.41 > 239.255.3.22: igmp v2 report 239.255.3.22

[ Voor 96% gewijzigd door Remie op 28-01-2023 09:25 ]

zaterdag 28 januari 2023 09:26

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Weet je zeker dat je zonder de NET statements wilt? Dan krijg je namelijk een shitload van vanalles. Wij hebben nogal wat apparaatjes in het netwerk hangen

zaterdag 28 januari 2023 09:27

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op zaterdag 28 januari 2023 @ 09:23:
Ok ik ben klaar met mijn vorige post.
Ik zal mijn eerste capture eens met -n draaien. Komt zo onder mijn post
En het hele multicast block wat je dan wel in een net zou kunnen opnemen.

224.0.0.0/4 (het 239 block wat je nam is te hoog in de range.)

Beter is zonder net :) als het te druk is op je netwerk kan je beter de source van je STB opgeven in de capture. Om de output te reduceren. Als je een apart STB vlan hebt is dat niet nodig.

zaterdag 28 januari 2023 09:29

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

stormfly schreef op zaterdag 28 januari 2023 @ 09:27:
[...]


En het hele multicast block wat je dan wel in een net zou kunnen opnemen.

224.0.0.0/4 (het 239 block wat je nam is te hoog in de range.)

Beter is zonder net :) als het te druk is op je netwerk kan je beter de source van je STB opgeven in de capture. Om de output te reduceren. Als je een apart STB vlan hebt is dat niet nodig.
Ik had een apart vlan maar sinds er chromecast op deze apparaatjes heb heb ik het omgezet naar het drukke vlan.

Eventueel kan ik dat vanavond ofzo wel doen want de TV is nogal heilig hier in het huishouden :P

Heb jij een voorbeeld van het commando dat ik moet gebruiken?
Want het is mij niet duidelijk wat je precies bedoelt. Filteren op SRC en NET? Is dat mogelijk? Ik werk namelijk niet dagelijks met tcpdump :P

zaterdag 28 januari 2023 09:43

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

tcpdump -n -i em1.10 src host 192.168.10.41

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

09:42:14.426752 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4494768, win 24564, length 0
09:42:14.427002 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4497672, win 24564, length 0
09:42:14.427377 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4503480, win 24564, length 0
09:42:14.428006 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4512192, win 24564, length 0
09:42:14.428754 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4518000, win 24543, length 0
09:42:14.428766 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4523808, win 24564, length 0
09:42:14.429127 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4526712, win 24543, length 0
09:42:14.429877 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4538328, win 24564, length 0
09:42:14.430127 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4541232, win 24543, length 0
09:42:14.430502 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4547040, win 24564, length 0
09:42:14.430628 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4549944, win 24564, length 0
09:42:14.430753 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4552848, win 24564, length 0
09:42:14.431002 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4555752, win 24543, length 0
09:42:14.431501 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4561560, win 24564, length 0
09:42:14.431627 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4564464, win 24564, length 0
09:42:14.431877 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4567368, win 24564, length 0
09:42:14.431888 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4570272, win 24559, length 0
09:42:14.433124 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4579765, win 24564, length 0
09:42:14.475479 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.476728 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.476746 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.478122 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:15.757850 IP 192.168.10.41 > 239.255.3.22: igmp v2 report 239.255.3.22
09:42:16.314276 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [P.], seq 3568:3924, ack 4579765, win 24564, length 356
09:42:16.317146 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4580038, win 24564, length 0
09:42:16.317771 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4580118, win 24564, length 0
09:42:16.318146 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4583022, win 24543, length 0
09:42:16.318396 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4585926, win 24510, length 0
09:42:16.318521 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4587378, win 24493, length 0
09:42:16.318771 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4587381, win 24564, length 0
09:42:17.249727 IP 192.168.10.41.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR KPN-DIW7022-92f5bc344a0785f5eba980e5dc3bed7c._googlecast._tcp.local. (383)
09:42:17.251616 IP 192.168.10.41.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR KPN-DIW7022-92f5bc344a0785f5eba980e5dc3bed7c._googlecast._tcp.local. (368)

zaterdag 28 januari 2023 11:08

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op zaterdag 28 januari 2023 @ 09:29:
[...]


Ik had een apart vlan maar sinds er chromecast op deze apparaatjes heb heb ik het omgezet naar het drukke vlan.

Eventueel kan ik dat vanavond ofzo wel doen want de TV is nogal heilig hier in het huishouden :P

Heb jij een voorbeeld van het commando dat ik moet gebruiken?
Want het is mij niet duidelijk wat je precies bedoelt. Filteren op SRC en NET? Is dat mogelijk? Ik werk namelijk niet dagelijks met tcpdump :P
Goed punt dat heb ik met mijn AppleTV ook, je wilt er toch naar kunnen streamen.

Dank voor je captures, die host is inderdaad helemaal de juiste syntax. Is dit bij live TV kijken want ik zie hier 0,0 multicast stream traffic?

zaterdag 28 januari 2023 12:11

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op zaterdag 28 januari 2023 @ 09:43:
tcpdump -n -i em1.10 src host 192.168.10.41

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

09:42:14.426752 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4494768, win 24564, length 0
09:42:14.427002 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4497672, win 24564, length 0
09:42:14.427377 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4503480, win 24564, length 0
09:42:14.428006 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4512192, win 24564, length 0
09:42:14.428754 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4518000, win 24543, length 0
09:42:14.428766 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4523808, win 24564, length 0
09:42:14.429127 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4526712, win 24543, length 0
09:42:14.429877 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4538328, win 24564, length 0
09:42:14.430127 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4541232, win 24543, length 0
09:42:14.430502 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4547040, win 24564, length 0
09:42:14.430628 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4549944, win 24564, length 0
09:42:14.430753 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4552848, win 24564, length 0
09:42:14.431002 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4555752, win 24543, length 0
09:42:14.431501 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4561560, win 24564, length 0
09:42:14.431627 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4564464, win 24564, length 0
09:42:14.431877 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4567368, win 24564, length 0
09:42:14.431888 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4570272, win 24559, length 0
09:42:14.433124 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4579765, win 24564, length 0
09:42:14.475479 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.476728 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.476746 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:14.478122 IP 192.168.10.41 > 239.255.255.251: igmp v2 report 239.255.255.251
09:42:15.757850 IP 192.168.10.41 > 239.255.3.22: igmp v2 report 239.255.3.22
09:42:16.314276 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [P.], seq 3568:3924, ack 4579765, win 24564, length 356
09:42:16.317146 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4580038, win 24564, length 0
09:42:16.317771 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4580118, win 24564, length 0
09:42:16.318146 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4583022, win 24543, length 0
09:42:16.318396 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4585926, win 24510, length 0
09:42:16.318521 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4587378, win 24493, length 0
09:42:16.318771 IP 192.168.10.41.52710 > 195.121.69.170.443: Flags [.], ack 4587381, win 24564, length 0
09:42:17.249727 IP 192.168.10.41.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR KPN-DIW7022-92f5bc344a0785f5eba980e5dc3bed7c._googlecast._tcp.local. (383)
09:42:17.251616 IP 192.168.10.41.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR KPN-DIW7022-92f5bc344a0785f5eba980e5dc3bed7c._googlecast._tcp.local. (368)
toon volledige bericht
Ik las net mee op het KPN forum dat er een video bron schakelaar is, op welke stand staat deze bij jou?

https://forum.kpn.com/ken...-van-de-kpn-tv-box-574401

Helemaal onderin, unicast of multicast?

zaterdag 28 januari 2023 13:40

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Ik verwacht dat hij op unicast staat. Helaas ben ik op het moment niet thuis dus kan nu even niet kijken.

Ik laat het weten zodra ik het heb gecheckt.

zaterdag 28 januari 2023 19:08

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Hij staat op multicast.
Zou er dan toch iets zijn wat ik mis?

zondag 29 januari 2023 16:27

Acties:
  • 0 Henk 'm!
  • stormfly
  • Registratie: Juli 2001
  • Laatst online: 21:39

stormfly

Topicstarter
Remie schreef op zaterdag 28 januari 2023 @ 19:08:
Hij staat op multicast.
Zou er dan toch iets zijn wat ik mis?
Nee ik denk dat ze een vrij slim kastje hebben ontworpen om de klantenservice belasting te verlagen. Ik doe hier een aanname maar hij lijkt auto-sensing?

Laten we vooral focussen op liveTV, het terugspelen van een opname of een gepauzeerd programma komt zeker van internet laten ze zien op het KPN forum.

maandag 30 januari 2023 21:33

Acties:
  • 0 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Inmiddels lijkt het er op dat ik multicast (weer) aan de praat heb gekregen.

Vanavond zal ik de volgende tests uitvoeren:

Unicast / multicast in de app schakelen.

-Livetv multicast
-Livetv unicast

En dan nog:
-Via de gids iets van een uur geleden afspelen multicast.
-Via de gids iets van een uur geleden afspelen unicast.

En de laatste:
-Via de opnames iets afspelen wat je eerder opgenomen hebt multicast.
-Via de opnames iets afspelen wat je eerder opgenomen hebt unicast.

-Via een WiFi hotspot icm unicast (KPN abbo, hiervoor zal er een geen packettrace mogelijk zijn dus enkel de functionaliteit zal worden getest)

[ Voor 198% gewijzigd door Remie op 31-01-2023 14:42 . Reden: Post herbruikt ]

dinsdag 31 januari 2023 20:15

Acties:
  • +1 Henk 'm!
  • Remie
  • Registratie: Augustus 2012
  • Laatst online: 08-05 09:21

Remie

Hierbij de multicast metingen

IP van KPN+ kastje is 192.168.10.41

LiveTV (KPN app ingesteld op multicast)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

20:07:25.050229 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.051744 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.053244 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.054743 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.056242 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.057741 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.059351 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.060864 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.062366 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.063844 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.065364 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.066861 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.068363 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.069859 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.071465 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.072983 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.074482 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.075981 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.077480 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.078979 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.080479 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.081977 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.083477 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.085100 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.086599 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.088098 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.089598 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.091080 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.092580 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.094094 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328
20:07:25.095701 IP 217.166.226.127.49152 > 224.0.252.127.7254: UDP, length 1328


Terugkijken via gids meer dan 1 uur geleden (KPN app ingesteld op multicast)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

20:11:21.482552 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 41
20:11:21.484177 IP 192.168.10.41.36854 > 142.250.179.206.443: Flags [P.], seq 1:780, ack 1, win 1024, options [nop,nop,TS val 623037239 ecr 2479303694], length 779
20:11:21.487062 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 1350
20:11:21.487073 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 578
20:11:21.487082 IP 142.250.179.206.443 > 192.168.10.41.36854: Flags [.], ack 780, win 263, options [nop,nop,TS val 2479303703 ecr 623037239], length 0
20:11:21.489201 IP 142.250.179.206.443 > 192.168.10.41.36854: Flags [P.], seq 1:381, ack 780, win 263, options [nop,nop,TS val 2479303705 ecr 623037239], length 380
20:11:21.489547 IP 192.168.10.41.36854 > 142.250.179.206.443: Flags [.], ack 381, win 1041, options [nop,nop,TS val 623037245 ecr 2479303705], length 0
20:11:21.495435 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 165
20:11:21.496419 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 1346
20:11:21.496429 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 1350
20:11:21.496438 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 1350
20:11:21.496544 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 1350
20:11:21.496555 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 189
20:11:21.497418 IP 192.168.10.41.36854 > 142.250.179.206.443: Flags [P.], seq 780:854, ack 381, win 1041, options [nop,nop,TS val 623037253 ecr 2479303705], length 74
20:11:21.498948 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 957
20:11:21.498959 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 93
20:11:21.499918 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 33
20:11:21.500820 IP 142.250.179.206.443 > 192.168.10.41.36854: Flags [P.], seq 381:1347, ack 854, win 263, options [nop,nop,TS val 2479303717 ecr 623037253], length 966
20:11:21.501167 IP 192.168.10.41.36854 > 142.250.179.206.443: Flags [.], ack 1347, win 1086, options [nop,nop,TS val 623037256 ecr 2479303717], length 0
20:11:21.502194 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 27
20:11:21.502426 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 25
20:11:21.507691 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 190
20:11:21.507702 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 124
20:11:21.508913 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 35
20:11:21.537298 IP 142.250.179.206.443 > 192.168.10.41.33608: UDP, length 25
20:11:21.538021 IP 192.168.10.41.33608 > 142.250.179.206.443: UDP, length 33
20:11:22.751456 IP 192.168.10.1 > 224.0.0.22: igmp v2 report 224.0.0.22


Iets afspelen wat ik eerder opgenomen heb (KPN app ingesteld op multicast)

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

20:14:30.815147 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28022468:28023920, ack 7448, win 16383, length 1452
20:14:30.815157 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28023920:28025372, ack 7448, win 16383, length 1452
20:14:30.815269 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28025372:28026824, ack 7448, win 16383, length 1452
20:14:30.815280 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28026824:28028276, ack 7448, win 16383, length 1452
20:14:30.815382 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28025372, win 24564, length 0
20:14:30.815506 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28028276, win 24564, length 0
20:14:30.815523 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28028276:28029728, ack 7448, win 16383, length 1452
20:14:30.815532 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28029728:28031180, ack 7448, win 16383, length 1452
20:14:30.815644 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28031180:28032632, ack 7448, win 16383, length 1452
20:14:30.815655 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28032632:28034084, ack 7448, win 16383, length 1452
20:14:30.815881 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28031180, win 24564, length 0
20:14:30.815893 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28034084, win 24564, length 0
20:14:30.815897 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28034084:28035536, ack 7448, win 16383, length 1452
20:14:30.815908 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28035536:28036988, ack 7448, win 16383, length 1452
20:14:30.816019 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28036988:28038440, ack 7448, win 16383, length 1452
20:14:30.816030 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28038440:28039892, ack 7448, win 16383, length 1452
20:14:30.816131 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28036988, win 24564, length 0
20:14:30.816256 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28039892, win 24564, length 0
20:14:30.816271 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28039892:28041344, ack 7448, win 16383, length 1452
20:14:30.816281 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28041344:28042796, ack 7448, win 16383, length 1452
20:14:30.816506 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28042796, win 24564, length 0
20:14:30.816520 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28042796:28044248, ack 7448, win 16383, length 1452
20:14:30.816530 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28044248:28045700, ack 7448, win 16383, length 1452
20:14:30.816643 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28045700:28047152, ack 7448, win 16383, length 1452
20:14:30.816654 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28047152:28048604, ack 7448, win 16383, length 1452
20:14:30.816892 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28048604:28050056, ack 7448, win 16383, length 1452
20:14:30.816903 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28050056:28051508, ack 7448, win 16383, length 1452
20:14:30.817006 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28048604, win 24564, length 0
20:14:30.817020 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28051508:28052960, ack 7448, win 16383, length 1452
20:14:30.817031 IP 195.121.69.182.443 > 192.168.10.41.45084: Flags [.], seq 28052960:28054412, ack 7448, win 16383, length 1452
20:14:30.817131 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28051508, win 24564, length 0
20:14:30.817256 IP 192.168.10.41.45084 > 195.121.69.182.443: Flags [.], ack 28054412, win 24564, length 0


Het lijkt er dus op dat enkel live TV via multicast werkt en de rest onderwater toch unicast gebruikt. Wat het hiervoor het geval was weet ik niet misschien kan Stormfly daar uitsluitsel over geven
Pagina: 1 ... 5 ... 9 Laatste
Reageer

Apple iPhone 16e LG OLED evo G5 Google Pixel 10 Samsung Galaxy S25 Star Wars: Outlaws Nintendo Switch 2 Apple AirPods Pro (2e generatie) Sony PlayStation 5 Pro

Tweakers is onderdeel van DPG Media B.V.
Alle rechten voorbehouden - Auteursrecht © 1998 - 2025 • Hosting door TrueFullstaq