De Netweters
annuleren
Resultaten voor 
Zoek in plaats daarvan naar 
Bedoelde u: 

IPv6 op de CV8560E (E-router)

Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

@VinzzB  schreef:

 

EDIT: PD verdwijnt idd na instellen van Mac Pass Through. 😞


Heb je na de wijziging van het mac pass-through address een reconnect gedaan, of je router ge-reboot? Dit zou dan kunnen betekenen dat niet de wijziging zelf een probleem is, maar net als in mijn geval er op wijst dat de DHCPv6 packets van je router niet meer beantwoord worden.

 

Waarschijnlijk heb je een prefix ontvangen, waarna de router op authentication overschakeld. Je eigen router behoud die prefix, maar de timer loopt af.

Wanneer je tijdens deze periode je router reboot, of de kabel voor een iets langere periode loskoppeld, dan gaat de prefix verloren, en wordt opnieuw aangevraagd. Dit faalt.

Dit is in ieder geval mijn vermoeden na het zien van de packet-traces tussen mijn eigen router en de CV8560E.

Mijn leraar zei vroeger altijd al "meten is weten". Dat is hier eigenlijk ook van toepassing. Het is belangrijk om te kijken welke packets over en weer gaan.

 

 



Meten is weten. Gissen is missen.
Beantwoorden
Highlighted
Professional Weetjesweter
Berichten: 34
Tien op tien! Jij bent af! Say what?! Nice talking to you!

@Arnie  schreef:


Heb je na de wijziging van het mac pass-through address een reconnect gedaan, of je router ge-reboot? Dit zou dan kunnen betekenen dat niet de wijziging zelf een probleem is, maar net als in mijn geval er op wijst dat de DHCPv6 packets van je router niet meer beantwoord worden.

 


ik had idd een reconnect uitgevoerd.

A.d.h.v. de debug gegevens kon ik uitmaken dat er wsl ook een uithentication packet komt zoals jij had gemeld.

 

Dit is de debug log:

 

 

00:09:31 	dhcp6c 	22356 	received an unexpected message (reconfigure) from fe80::342c:c4ff:fecb:771%igb2
00:09:31 	dhcp6c 	22356 	unknown or unexpected DHCP6 option reconfigure message, len 1
00:09:31 	dhcp6c 	22356 	get DHCP option reconfigure message, len 1
00:09:31 	dhcp6c 	22356 	DUID: 
00:09:31 	dhcp6c 	22356 	get DHCP option client ID, len 10
00:09:31 	dhcp6c 	22356 	DUID: 
00:09:31 	dhcp6c 	22356 	get DHCP option server ID, len 14
00:09:31 	dhcp6c 	22356 	receive reconfigure from fe80::342c:c4ff:fecb:771%igb2 on igb2
00:09:28 	dhcp6c 	22356 	received an unexpected message (reconfigure) from fe80::342c:c4ff:fecb:771%igb2
00:09:28 	dhcp6c 	22356 	unknown or unexpected DHCP6 option reconfigure message, len 1
00:09:28 	dhcp6c 	22356 	get DHCP option reconfigure message, len 1
00:09:28 	dhcp6c 	22356 	DUID: 
00:09:28 	dhcp6c 	22356 	get DHCP option client ID, len 10
00:09:28 	dhcp6c 	22356 	DUID: 
00:09:28 	dhcp6c 	22356 	get DHCP option server ID, len 14
00:09:28 	dhcp6c 	22356 	receive reconfigure from fe80::342c:c4ff:fecb:771%igb2 on igb2
00:09:15 	dhcp6c 	22356 	got an expected reply, sleeping.
00:09:15 	dhcp6c 	22356 	removing server (ID: 00:01:00:01:25:c3:27:33:36:2c:c4:cb:07:71)
00:09:15 	dhcp6c 	22356 	removing an event on igb2, state=REQUEST
00:09:15 	dhcp6c 	22356 	script "/var/etc/dhcp6c_wan_script.sh" terminated
00:09:15 	dhcp6c 		dhcp6c renew, no change - bypassing update on igb2
00:09:15 	dhcp6c 	22356 	executes /var/etc/dhcp6c_wan_script.sh
00:09:15 	dhcp6c 	22356 	status code for NA-0: success
00:09:15 	dhcp6c 	22356 	add an address 2a02:1811:::8e34/128 on igb2
00:09:15 	dhcp6c 	22356 	create an address 2a02:1811:::8e34 pltime=83672, vltime=6110436683390642645
00:09:15 	dhcp6c 	22356 	make an IA: NA-0
00:09:15 	dhcp6c 	22356 	status code for PD-0: success
00:09:15 	dhcp6c 	22356 	add an address 2a02:1811::::fe08:6158/64 on igb1.10
00:09:15 	dhcp6c 	22356 	create a prefix 2a02:1811:::/60 pltime=83672, vltime=256472
00:09:15 	dhcp6c 	22356 	make an IA: PD-0
00:09:15 	dhcp6c 	22356 	Domain search list[0] telenet.be.
00:09:15 	dhcp6c 	22356 	nameserver[1] 2a02:1800:100::41:2
00:09:15 	dhcp6c 	22356 	nameserver[0] 2a02:1800:100::41:1
00:09:15 	dhcp6c 	22356 	dhcp6c Received REQUEST
00:09:15 	dhcp6c 	22356 	get DHCP option domain search list, len 12
00:09:15 	dhcp6c 	22356 	get DHCP option DNS, len 32
00:09:15 	dhcp6c 	22356 	preference: 255
00:09:15 	dhcp6c 	22356 	get DHCP option preference, len 1
00:09:15 	dhcp6c 	22356 	get DHCP option client ID, len 10
00:09:15 	dhcp6c 	22356 	DUID: 00:01:00:01:25:c3:27:33:36:2c:c4:cb:07:71
00:09:15 	dhcp6c 	22356 	get DHCP option server ID, len 14
00:09:15 	dhcp6c 	22356 	status code: success
00:09:15 	dhcp6c 	22356 	get DHCP option status code, len 24
00:09:15 	dhcp6c 	22356 	IA_PD prefix: 2a02:1811:::/60 pltime=83672 vltime=256472
00:09:15 	dhcp6c 	22356 	get DHCP option IA_PD prefix, len 25
00:09:15 	dhcp6c 	22356 	IA_PD: ID=0, T1=41836, T2=66937
00:09:15 	dhcp6c 	22356 	get DHCP option IA_PD, len 69
00:09:15 	dhcp6c 	22356 	status code: success
00:09:15 	dhcp6c 	22356 	get DHCP option status code, len 22
00:09:15 	dhcp6c 	22356 	IA_NA address: 2a02:1811:::8e34 pltime=83672 vltime=256469
00:09:15 	dhcp6c 	22356 	get DHCP option IA address, len 24
00:09:15 	dhcp6c 	22356 	IA_NA: ID=0, T1=41836, T2=66937
00:09:15 	dhcp6c 	22356 	get DHCP option identity association, len 66
00:09:15 	dhcp6c 	22356 	receive reply from fe80::342c:c4ff:fecb:771%igb2 on igb2
00:09:15 	dhcp6c 	22356 	reset a timer on igb2, state=REQUEST, timeo=0, retrans=1024
00:09:15 	dhcp6c 	22356 	send request to ff02::1:2%igb2
00:09:15 	dhcp6c 	22356 	set IA_PD
00:09:15 	dhcp6c 	22356 	set status code
00:09:15 	dhcp6c 	22356 	set IA_PD prefix
00:09:15 	dhcp6c 	22356 	set option request (len 4)
00:09:15 	dhcp6c 	22356 	set elapsed time (len 2)
00:09:15 	dhcp6c 	22356 	set identity association
00:09:15 	dhcp6c 	22356 	set status code
00:09:15 	dhcp6c 	22356 	set IA address
00:09:15 	dhcp6c 	22356 	set server ID (len 14)
00:09:15 	dhcp6c 	22356 	set client ID (len 10)
00:09:15 	dhcp6c 	22356 	a new XID (9241bb) is generated
00:09:15 	dhcp6c 	22356 	Sending Request
00:09:15 	dhcp6c 	22356 	server ID: 00:01:00:01:25:c3:27:33:36:2c:c4:cb:07:71, pref=255
00:09:15 	dhcp6c 	22356 	get DHCP option domain search list, len 12
00:09:15 	dhcp6c 	22356 	get DHCP option DNS, len 32
00:09:15 	dhcp6c 	22356 	preference: 255
00:09:15 	dhcp6c 	22356 	get DHCP option preference, len 1
00:09:15 	dhcp6c 	22356 	get DHCP option client ID, len 10
00:09:15 	dhcp6c 	22356 	get DHCP option server ID, len 14
00:09:15 	dhcp6c 	22356 	status code: success
00:09:15 	dhcp6c 	22356 	get DHCP option status code, len 24
00:09:15 	dhcp6c 	22356 	IA_PD prefix: 2a02:1811:::/60 pltime=83672 vltime=256472
00:09:15 	dhcp6c 	22356 	get DHCP option IA_PD prefix, len 25
00:09:15 	dhcp6c 	22356 	IA_PD: ID=0, T1=41836, T2=66937
00:09:15 	dhcp6c 	22356 	get DHCP option IA_PD, len 69
00:09:15 	dhcp6c 	22356 	status code: success
00:09:15 	dhcp6c 	22356 	get DHCP option status code, len 22
00:09:15 	dhcp6c 	22356 	IA_NA address: 2a02:1811:::8e34 pltime=83672 vltime=256469
00:09:15 	dhcp6c 	22356 	get DHCP option IA address, len 24
00:09:15 	dhcp6c 	22356 	IA_NA: ID=0, T1=41836, T2=66937
00:09:15 	dhcp6c 	22356 	get DHCP option identity association, len 66
00:09:15 	dhcp6c 	22356 	receive advertise from fe80::342c:c4ff:fecb:771%igb2 on igb2
00:09:15 	dhcp6c 	22356 	reset a timer on igb2, state=SOLICIT, timeo=3, retrans=8065
00:09:15 	dhcp6c 	22356 	send solicit to ff02::1:2%igb2 

 

 

0 Likes
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

@GlennR was zo vriendelijk mij een pcap te sturen van zijn werkende IPv6 setup, gebruikmakende van een Mikrotik router. In deze trace zie ik geen authentication option in de uitwisseling van DHCPv6. Vermoedelijk is er toch sprake van een verschil in de config van onze CV8560E routers.

 

Ik zal straks anders eens een opnieuw een factory reset doorvoeren, en mijn eigen Mikrotik ipv Fritzbox proberen. Ik vermoed echter dat dit ook dan hetzelfde probleem gaat opleveren met authentication.



Meten is weten. Gissen is missen.
Beantwoorden
Highlighted
Experienced Meerweter
Berichten: 96
Topicvreter! Opgeruimd staat netjes! Topicwurm! Goed bezig!

RGC 3315 (July 2003) en RFC 8415 (November 2018) verschillen qua authenticatie specificatie.

3315 sectie 21.4.4 legt initiatief bij de client

8415 sectie 20.4 legt initiatief bij de server

misschien is er een soms een misverstand client en/of server config en/of implementatie?

 

 

{*niet* 'like'-en aub}
0 Likes
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

Ik heb mijn Fritzbox nu even vervangen door de Mikrotik. Na een factory reset van de CV8560E ontving deze keurig een prefix, en de clients achter de router scoren 10/10 op de ipv6 test.

In de trace zie ik nu geen authentication options in de packets van de CV8560E.

Het probleem wat ik met de Fritzbox heb is echter ook hier aanwezig. Na enige tijd (enkele minuten) wordt er niet op de renew packets geantwoord. Bijgevolg zal ook nu de prefix zijn houdbaarheids datum bereiken, en zal IPv6 stoppen te werken.

Zeer merkwaardig waarom de CV8560E na verloop van tijd niet meer op DHCPv6 reageert.



Meten is weten. Gissen is missen.
Beantwoorden
Highlighted
Experienced Meerweter
Berichten: 96
Topicvreter! Opgeruimd staat netjes! Topicwurm! Goed bezig!

@Arnie Als ik het goed voor heb is er nu een pcap (hopelijk van enkele minuten) van een werkende Mikrotik (van @GlennR) en heb jij misschien ook een pcap (hopelijk van enkele minuten) van een niet werkende Mikrotik. Is nergens een noemenswaardig verschil in de dhcpv6 paketten te bespeuren? Is het mogelijk (uiteraard met beider toestemming) deze binaire pcaps te sharen?

{*niet* 'like'-en aub}
0 Likes
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

Juist, van GlennR hebben we een pcap van een werkende Mirkotik. Ik heb zelf ook een pcap kunnen maken met een Mikrotik (zelfde hw en sw) waarbij de prefix wel aangeboden wordt, maar daarna verdwijnt.

Datzelfde verschijnsel zie ik ook bij de fritzbox, waarvan ook een pcap.

 

Ik heb deze pcaps al met Telenet gedeeld, waar dit maandag bekeken zal worden. De pcaps bevatten te veel mac en ip adres informatie om hier te kunnen delen.

 

De pcap van GlennR toont zover ik kan beoordelen geen initiele dhcpv6 exchange, maar de ongoing uitwisseling. Mijn pcap toont de startup, en dhcpv6 exchange. Het laatst onvangen packet van de CV8560E is een reconfigure, daarna komt er geen dhcpv6 packet meer uit de router, ondankt verschillende sollicit en renew request die mijn Mikrotik stuurt.

 

arnie.png



Meten is weten. Gissen is missen.
Beantwoorden
Highlighted
Professional Veelweter
Berichten: 376
Lees je nog iets anders? ;-) Waar zijn die handjes? WOW! Klasse!

@Arnie  schreef:

Juist, van GlennR hebben we een pcap van een werkende Mirkotik. Ik heb zelf ook een pcap kunnen maken met een Mikrotik (zelfde hw en sw) waarbij de prefix wel aangeboden wordt, maar daarna verdwijnt.

Datzelfde verschijnsel zie ik ook bij de fritzbox, waarvan ook een pcap.

 

Ik heb deze pcaps al met Telenet gedeeld, waar dit maandag bekeken zal worden. 


Ik hoop dat Telenet dit probleem met de nodige urgentie aanpakt.

Eigenlijk onbegrijpelijk dat klanten hier de troubleshooting moeten doen, terwijl ze bij Telenet ganse verdiepingen goed betaalde engineers tewerkstellen.

Blijkbaar is een goed werkende modem (die tenminste werkt "als designed") geen hoge prioriteit 🤔.

 

Voor mij nog altijd een mysterie waarom de implementatie "as designed" wel werkt met een CH8586LG, maar niet met de CV8560E ☹️.

Hoe zit dat met de CH7465LG (de witte HGW)? Werkt hier de IPv6 wel op een achterliggende router?

 

Kudos @Arnie @GlennR @NofanTasi @VinzzB @igvfer en alle anderen om er hun tijd in te steken en Telenet een handje helpen 😌...

Beantwoorden
Highlighted
Experienced Meerweter
Berichten: 96
Topicvreter! Opgeruimd staat netjes! Topicwurm! Goed bezig!

De bal ligt stilaan nagenoeg volledig in het kamp van Telenet (server CV8560E). Want de client kan uiteraard niets besluiten uit paketten die de server niet stuurt. Hopelijk heeft Telenet de debug logs (corresponderend met client pcap messages) die meerpebaald aangeven waarom de server de client negeert. Er zijn dan nogal wat mogelijkheden, per RFC, in dat de server moet, mag of niet mag de client negeren. En, in alle geval is er 'zwart op wit' de pcap van de client messages (ik onderstel van boot tot 'doodlopend' einde) welke kunnen bevestigen of ontkennen dat zulks, per RFC, relevante server activiteit (of beter gezegd: inactiviteit), al dan niet, rechtvaardigt. De grijze zone is veelal waar, in RFC, SHOULD of MAY wordt vermeld (niet MUST (NOT)). Maar dikwijls kan de implementatie (server hier) zich tolerant opstellen volgens het wel aanvaarde Postel netwerk robustness principe. In alle geval moet Telenet nu, stilaan, liefst hun standpunt en bewijs materiaal laten geworden. Zelf raakt dit verhaal me vandaag niet (meer), maar, wat als mijn (goed werkende, weliswaar 'maar' DOCSIS 3.0) CV7160E het morgen begeeft? Ik hou mijn hart vast. Verder is het zo dat CBN in Taiwan, en evenzeer Telenet, (indien ze de CBN code wijzigen) gebonden zijn aan strikte opensource wetgeving en ze de opensource code moeten vrijgeven die ze gebruiken (en eventueel wijzigen). Daarin kan, indien relevant voor dit probleem, men dan de logica van het negeren van de client vinden moest beweerd worden dat de client moet genegeerd worden, terwijl de client zeker van zijn stuk is dat zulks niet het geval is. De open sourcecode opvragen kan gebeuren met hulp van daarin gespecialiseerde legale organisaties. Ik heb zulks in het verleden regelmatig met success gedaan.

 

{*niet* 'like'-en aub}
Tags (3)
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

We zijn weer een stapje verder. Samen met Telenet deze morgen de DHCPv6 server in mijn CV8560E terug op de default mode Stateful gezet. Gelijk vond er een goede DHCPv6 exchange plaats en ontving mijn Fritzbox terug een prefix. Alles werkt weer.

 

Bij wijze van test de Fritzbox afgekoppeld en de Mikrotik aangesloten. Ook die ontving gelijk een prefix.

 

Ik heb nu terug de Fritzbox aangesloten en in gebruik genomen. Alles lijkt goed te werken. Ik zal de timer in de gaten houden, om te zien of de prefix behouden blijft, maar het lijkt erop dat een renew nu goed werkt, en de timer zou moeten resetten wanneer nodig.

 

De default mode voor de DHCPv6 server is stateful, maar Telenet wijzigt die naar Stateless, omdat anders Android clients problemen ervaren. Wat goed voor Android is lijkt precies een probleem voor PD voor verschillende routers te zijn.

 

We bekijken de situatie eerst voor enige tijd, om te zien of dit stateful echt goed blijft werken, dan zal Telenet een keuze moeten maken hoe dit op te lossen.



Meten is weten. Gissen is missen.
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 17
Handje vol! Nog geen reader's digest? :-) Je eerste full page! Twee handen vol!

Dan vraag ik me wel af welke mode ze gebruiken op de modem-only waar het wel werkt voor alle toestellen?

0 Likes
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 24
Tien op tien! Follow the reader, reader! Leesbeest! Twee handen vol!

@Arnie 
Good work!
Op zich zou Telenet dit toch moeten kunnen koppelen aan het MAC adres die je definiëert voor passthrough in Mijn Telenet?

 

Althans voor de HGW. Voor de modem only zal het dan wss als een toggle in Mijn Telenet moeten zijn.

Alhoewel... stateful/stateless is natuurlijk via de Router Advertisements... en die worden gebroadcast. On/off toggle zou makkelijkst zijn, om enkel voor de passthrough MAC een andere RA te zenden, die dan niet terecht komt bij de andere... da's complex...

 

Of ze moeten het gebruik van de WAN poort op de HGW toelaten, zodat je eigen router daarop moet gekoppeld worden en dan op die poort impliciet MAC passthrough en Statefull IPv6 heeft.

0 Likes
Beantwoorden
Highlighted
Community Manager
Berichten: 3067
It's your fifth party! De gouden postveer is voor jou Netweters’ orakel! It's your fourth party!

@Arnie  schreef:

We zijn weer een stapje verder. Samen met Telenet deze morgen de DHCPv6 server in mijn CV8560E terug op de default mode Stateful gezet. Gelijk vond er een goede DHCPv6 exchange plaats en ontving mijn Fritzbox terug een prefix. Alles werkt weer.

 

Bij wijze van test de Fritzbox afgekoppeld en de Mikrotik aangesloten. Ook die ontving gelijk een prefix.

 

Ik heb nu terug de Fritzbox aangesloten en in gebruik genomen. Alles lijkt goed te werken. Ik zal de timer in de gaten houden, om te zien of de prefix behouden blijft, maar het lijkt erop dat een renew nu goed werkt, en de timer zou moeten resetten wanneer nodig.

 

De default mode voor de DHCPv6 server is stateful, maar Telenet wijzigt die naar Stateless, omdat anders Android clients problemen ervaren. Wat goed voor Android is lijkt precies een probleem voor PD voor verschillende routers te zijn.

 

We bekijken de situatie eerst voor enige tijd, om te zien of dit stateful echt goed blijft werken, dan zal Telenet een keuze moeten maken hoe dit op te lossen.


@Arnie bedankt om het te delen! Ik heb deze informatie deze ochtend ook door gekregen.

 

Telenet is er zeker mee bezig en jullie hulp en het delen van jullie vaststellingen wordt zeker en vast geapprecieerd! Wat @Arnie hierboven aangeeft lijkt een tijdelijke workaround te zijn dat Telenet nu aan het testen is. Men hoopt natuurlijk een permanente fix in de software te kunnen implementeren, maar hier heb ik nog geen richtdatum voor. 


https://www.netweters.be/html/assets/Telenet%20logo%20signatures.png?version=previewSuzy | Community Manager

Without music, life would be a mistake. - Nietzsche

Vergeet niet om likes te geven en/of als oplossing te markeren.

Beantwoorden
Highlighted
Experienced Meerweter
Berichten: 96
Topicvreter! Opgeruimd staat netjes! Topicwurm! Goed bezig!

@Arnie 

Heb jij toevallig een (niet al te oud) Android device en heeft dat device nu inderdaad 'problemen' met stateful mode? Ik ken de (vast IP + CV7160E) implementatie van Telenet niet (stateful of stateless) maar mijn up to date Android 10 lijkt, op eerste zicht, probleemloos ...

root@localhost:~# ping -6 www.google.com
PING www.google.com (2a00:1450:400e:800::2004): 56 data bytes
64 bytes from 2a00:1450:400e:800::2004: seq=0 ttl=118 time=21.829 ms
64 bytes from 2a00:1450:400e:800::2004: seq=1 ttl=118 time=38.413 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 21.829/30.121/38.413 ms

{*niet* 'like'-en aub}
0 Likes
Beantwoorden
Highlighted
Experienced Weetjesweter
Berichten: 70
Een bus vol! En we zijn vertrokken! Dat begint te tellen! Goed bezig!

Ik heb een recente GSM (Samsung S10e, Android versie 10). Die connecteert nu via wifi met mijn private netwerk (achter de frtizbox). Die werkt perfect: ipv4 & ipv6.

 

Wellicht zou dit problemen kunnen geven wanneer je de gsm direkt aan het Telenet netwerk koppelt (het 192.168.0.0/24 net, direct aan de CV8560E), bijvoorbeeld als je hier een access-point aan hangt en als gast netwerk gebruikt.

Ik kan dat wel eens proberen. Normaal gebruik ik dat netwerkje niet als mijn gastnet, maar heb ik mijn gastnet aan eth port 4 van de Fritzbox.



Meten is weten. Gissen is missen.
Beantwoorden