Ziggo Go App en Ziggogo.tv

[brant]

1. De ziggo Go app werkt niet op mijn nieuwe nokia 5 met wifi. Zodra ik de wifi uitschakel en dus op 4 G overschakel direct wel. Maar dit kost dan veel MB's en geld. Bovendien heb ik wel wifi op mijn laptop, dat heb ik verschillende malen gecheckecd door eerst bekabeld te kijken en daarna de wifi in te schakelen en de kabel naar de connectbox eruit.
Alles gechecked, mijn andere apps op de Nokia 5 (zoals bijv. Youtube, Facebook) werken wel en ik heb mijn wifi overgezet van 2.4 naar 5 Ghz, wifi ook via de kabel van mijn humax naar de connectbox aangesloten. Ook wifi analyzer geeft aan dat het signaal uitstekend is en dat is bevestigd door de helpdesk van Ziggo. Merkwaardig, enig idee hoe dit kan?
2. Als alternatief voor de ziggo go app www.ziggogo.tv geprobeerd op mijn Nokia 5. ziggogo.tv doet het niet in de Firefox browser, wel in Chrome. Hoe kan dit?
Doel van dit bericht: Ik streef ernaar om mijn Ziggo Go app op mijn Nokia werkend te krijgen. MvG brant

[DenSpike]

robbo hanh Jbr67
Nou, ik heb de Wifi-kaart-excercitie uitgevoerd en tegelijk wat Pingplotter-plaatjes gemaakt.
Als target IPv6-adres heb ik die genomen van de 1e DNS-server (2001:730:3E42::53)

Voor uitschakelen wifi kaart:


Toen de Wifi kaart uitgeschakeld
Daarna de Wifi kaart weer ingeschakeld


Om te kunnen vergelijken of de wifi kaart problemen geeft, heb ik de laptop bedraad aangesloten.
Dit geeft het volgende plaatje


Conclusie die voor de hand ligt is om op basis van deze plaatjes te trekken is dat er inderdaad een probleem met de wifi kaart is (alleen wel vreemd dat hij eerst goed werkte en toen na uit/in-schakelen dit resultaat gaf.

Ik heb dus nog een aantal malen de wifi-kaart aan/uit-geschakeld en telkens met Pingplotter het effekt bekeken.
Nou, ik kan je zeggen dat je er geen enkel peil op kunt trekken.
Geloof me het is echt toevallig wat er uit komt rollen...
Soms wel/ soms niet bereikbaar, en dat geldt voor wifi (voor aan/uit, maar ook na aan/uit) en ook voor bedraad.
Er zit absoluut geen logica achter, en is dus absoluut onreproduceerbaar.

Conclusie (mede op basis van andere testjes) is dat de wifi kaart prima werkt en op zich geen oorzaak is van deze vreemde Pingplotter resultaten.

Na gelezen te hebben wat Jbr67 constateert ben i er nu 100% van overtuigd dat de problemen veroorzaakt worden door de vreemde niet muteerbare DHCP-settings (en dan met name de Router Advertisement lifetime setting).

Ik ga dus geen verdere energie meer steken in het testen, verklaren en beredeneren van de IPv6 gedragingen van mijn wifi-thuisnetwerk (en naar nu blijkt tegelijk ook van mijn bedrade-thuisnetwerk).

De oplossing ligt in het duidelijk krijgen waarom de DHCP-velden in "mijn" connectieboxen niet muteerbaar zijn en van die vreemde waardes bevatten.
Als oorzaken zie ik:
- fout(en) in de hardware (ik heb 2x de hardwareversie 10 mogen ontvangen, dus dan zou het een systematische fout in hardwareversie 10 moeten zijn)
- fout(en) in de software van de connectbox (ik heb 2x de softwareversie 9.1.116.605) mogen ontvangen, dus dan zou het een systematische fout in deze softwareverise moeten zijn)
- fout(en) in de configuratiefile (ik heb ondertussen meerdere verschillende configuratiefiles mogen ontvangen, ze vertonen alle dezelfde vreemde DHCP-velden)

Naar mijn mening moeten we door uitsluiting (door omwisselen van connectboxen) proberen uit te dokteren wanneer het probleem van de vreemde DHCP-velden zich niet meer voordoet.
Dan kunnen de Ziggo-specialisten vervolgens gericht aan de slag om het probleem structureel te verhelpen.

Graag jullie reakties (commentaar, verbeteringen, andere voorstellen/suggesties en desnoods ....instemming)

[Jbr67]

DenSpike wrote:

Er zit absoluut geen logica achter, en is dus absoluut onreproduceerbaar.

Conclusie (mede op basis van andere testjes) is dat de wifi kaart prima werkt en op zich geen oorzaak is van deze vreemde Pingplotter resultaten.

Na gelezen te hebben wat Jbr67 constateert ben i er nu 100% van overtuigd dat de problemen veroorzaakt worden door de vreemde niet muteerbare DHCP-settings (en dan met name de Router Advertisement lifetime setting).

Ik ga dus geen verdere energie meer steken in het testen, verklaren en beredeneren van de IPv6 gedragingen van mijn wifi-thuisnetwerk (en naar nu blijkt tegelijk ook van mijn bedrade-thuisnetwerk).

De oplossing ligt in het duidelijk krijgen waarom de DHCP-velden in "mijn" connectieboxen niet muteerbaar zijn en van die vreemde waardes bevatten.
Als oorzaken zie ik:
- fout(en) in de hardware (ik heb 2x de hardwareversie 10 mogen ontvangen, dus dan zou het een systematische fout in hardwareversie 10 moeten zijn)
- fout(en) in de software van de connectbox (ik heb 2x de softwareversie 9.1.116.605) mogen ontvangen, dus dan zou het een systematische fout in deze softwareverise moeten zijn)
- fout(en) in de configuratiefile (ik heb ondertussen meerdere verschillende configuratiefiles mogen ontvangen, ze vertonen alle dezelfde vreemde DHCP-velden)

Naar mijn mening moeten we door uitsluiting (door omwisselen van connectboxen) proberen uit te dokteren wanneer het probleem van de vreemde DHCP-velden zich niet meer voordoet.
Dan kunnen de Ziggo-specialisten vervolgens gericht aan de slag om het probleem structureel te verhelpen.

Graag jullie reakties (commentaar, verbeteringen, andere voorstellen/suggesties en desnoods ....instemming)

DenSpike
Eens. Nix aan toe te voegen... nou een ding: ziggo heeft het ondertussen op een presenteerblaadje gekregen. ZIJ zijn nu echt aan zet.

[hanh]

DenSpike

robbo verdient een pluim.
Hij bracht mijn denken 'back to the basics'. Even weg van al dat ingewikkelde gedoe.
Er is toch wel iets met die adaptor als soort van zij- of bij-probleem.
Hoe verzin je het? Goed om te weten in elk geval voor wat nog volgt.

Verder: helemaal met je eens en met Jbr67.

Gr Han

[robbo]

hanhDank voor het compliment, maar we doen het met z'n allen! Dus iedereen verdient een pluim in mijn ogen . De feedback is precies waar een community voor bedoeld is!

[DenSpike]

Naar mijn idee verdient iedereen die zich tegen dit probleem heeft aanbemoeit een pluim!!
Grandioos hoe we met elkaar al redenerend en deducerend zover gekomen zijn (en nu maar hopen dat onze voorlopige eindconclusies juist blijken....)

Ik heb trouwens een verzoek aan ALLE lezers van dit topic:
zoals hierboven aangegeven lijkt het mij door "uitsluiting" mogelijk de foutbron te vinden.
Maar er is mogelijk een simpeler, sneller en goedkopere oplossing.
Als nu IEDEREEN eens de moeite neemt om in zijn connectbox te kijken en het volgende hier even te posten:
- hardware versie
- software versie
(beide zijn te vinden bij Beheer/Informatie)
- configuratie file
(te vinden bij Geavanceerde instellingen/Hulpmiddelen/Netwerk status/Router status/Configuratie)
- en dan te kijken hoe de DHCP IPv6 velden er uitzien
(te vinden bij Geavanceerde instellingen/DHCP/DHCPv6server
Graag bij dit item aangeven of de velden gearceerd zijn (dus of je de waardes kunt wijzigen).

Voor een idee hoe het er bij mij uitziet:


Graag allemaal meteen even doen (waarvoor op voorhand mijn dank), zal ik proberen er conclusies uit te trekken en jullie uiteraard informeren daarover....

[hanh]

robbo wrote:
hanhDank voor het compliment, maar we doen het met z'n allen! Dus iedereen verdient een pluim in mijn ogen . De feedback is precies waar een community voor bedoeld is!

Ik druk me wel eens onbeholpen uit:wink: Het was bedoeld als een persoonlijke pluim.
Iedereen natuurlijk in dit topic. Den had het er ook meteen over.
Pfff ik moet zien hier goed weg te komen.:blush:
Gr Han

[Jbr67]

DenSpike wrote:
Naar mijn idee verdient iedereen die zich tegen dit probleem heeft aanbemoeit een pluim!!
Grandioos hoe we met elkaar al redenerend en deducerend zover gekomen zijn (en nu maar hopen dat onze voorlopige eindconclusies juist blijken....)

Ik heb trouwens een verzoek aan ALLE lezers van dit topic:
zoals hierboven aangegeven lijkt het mij door "uitsluiting" mogelijk de foutbron te vinden.
Maar er is mogelijk een simpeler, sneller en goedkopere oplossing.
Als nu IEDEREEN eens de moeite neemt om in zijn connectbox te kijken en het volgende hier even te posten:
- hardware versie
- software versie
(beide zijn te vinden bij Beheer/Informatie)
- configuratie file
(te vinden bij Geavanceerde instellingen/Hulpmiddelen/Netwerk status/Router status/Configuratie)
- en dan te kijken hoe de DHCP IPv6 velden er uitzien
(te vinden bij Geavanceerde instellingen/DHCP/DHCPv6server
Graag bij dit item aangeven of de velden gearceerd zijn (dus of je de waardes kunt wijzigen).

Voor een idee hoe het er bij mij uitziet:


Graag allemaal meteen even doen (waarvoor op voorhand mijn dank), zal ik proberen er conclusies uit te trekken en jullie uiteraard informeren daarover....

Ik heb geen connectbox dus kan geen info geven. Maar.. ik vond nog wel een screenshot uit de HANDLEIDING.

Deze settings zijn tenminste logisch. De ra lifetime staat 10x zo groot als de ra-periode. Elke 3 minuten adverteert de router de route, en een ingeleerde route is 1800 seconden geldig op een device. Nu afwachten wat anderen hebben....

[DenSpike]

Jbr67
Dank voor je reaktie; jammer dat je geen connectbox hebt...

Inderdaad de waardes die in jouw router zitten zijn logisch.
Een lifetime van 3 secondes bij een interval van 1800 secondes zoals bij mij, slaan helemaal nergens op...

Ben benieuwd of er nog andere reakties komen...... (hopelijk van Ziggo-klanten met wel een connectbox)

[Mark]

Hoi allemaal,

Ik zit vandaag op een andere locatie en de Connectbox hier laat precies dezelfde DHCPv6 instellingen zien als het modem van DenSpike.

Alles is greyed-out, ongeacht of ik hem op stateful of stateless zet en de DHCPv6 leasetime = 0; Router advertisement lifetime = 3. Nu dacht ik "Yes ik kan hier het probleem reproduceren!"
Dus pakte mijn Android telefoon en startte Ziggo GO op (waar ik voorheen geen problemen mee had). Alleen ervaar ik nog steeds geen problemen... echter zag ik dat mijn toestel geen IPv6 verbinding maakte, gewoon niet, ook niet een beetje.
Dan een iPhone van een collega die wel een IPv6 verbinding heeft: ipv6 test stabiel en ook geen problemen met Ziggo GO.

Kortom: ik denk niet dat die instellingen de boosdoener zijn, maar het feit dat ze er zo bij staan lijkt me nog altijd niet goed en daar ga ik alsnog achteraan.

Vraag blijft waar dit probleem nu wél door veroorzaakt wordt. Alleen gaat dit mijn kennis te boven en ben ik afhankelijk van een collega die hierbij helpt (die heeft eerder ook telefonisch contact gehad met DenSpike), hij heeft het erg druk maar ik heb hem nogmaals verzocht om hiernaar te kijken.

Als dat op korte termijn niet lukt lijkt het me tijd om de handdoek in de ring te gooien en het modem om te zetten naar IPv4 only. 😞

[hanh]

Mark Ziggo
Fraaie update, Mark. Ik bleef benieuwd. Het is een breinbreker.
Overstap naar IPv4 is onbevredigend. Wat moet, dat moet dan maar.
Gr Han

[DenSpike]

Mark Ziggo
Mooi dat de fout nu bij jullie reproduceerbaar is.
Dat de Ziggo Go app op iphone en via wifi dan werkt kan ik bijna niet geloven.
Alle testen die wij hebben gedaan wijzen op een bagger IPv6 verbinding. (kan ook domweg niet anders met deze vreemde IPv6 DHCP-instellingen)
Durf het bijna niet te vragen, maar gingen jullie testen per ongeluk niet via het mobiele net...??
En hebben jullie ping-testen gedaan naar bijvoorbeeld de IPv6 facebooksite of de Ziggo IPv6 DNS-servers?

Kan het niet geloven...

Wat mij betreft gaan we door met testen/zoeken, tenzij de betreffende Ziggo-expert pas met Kerst enige tijd aan dit probleem kan schenken.
En dan nog zouden we in de tussentijd kunnen proberen "mijn nieuwe" connectbox met hardwareversie 10 te vervangen door een hardwareversie 5 (met uiteraard de bijbehorende software).
Kunnen we in ieder geval testen of het probleem in een bepaalde de connectbox hardware/software combinatie zit....

[Mark]

DenSpike wrote:
Durf het bijna niet te vragen, maar gingen jullie testen per ongeluk niet via het mobiele net...??
En hebben jullie ping-testen gedaan naar bijvoorbeeld de IPv6 facebooksite of de Ziggo IPv6 DNS-servers?

- Zeker weten via wifi
- Is er een app waarmee ik dat makkelijk kan doen? Ik ben niet zo bekend met Apple (had gisteren een iPhone van een collega geleend).

En dan nog zouden we in de tussentijd kunnen proberen "mijn nieuwe" connectbox met hardwareversie 10 te vervangen door een hardwareversie 5 (met uiteraard de bijbehorende software).

Wat bedoel je hiermee? Dit klinkt mij niet bekend.

[DenSpike]

Mark Ziggo
Ik bedoel het testen (door te pingen) van het IPv6-netwerk via de wifi van de connectbox of direct bekabeld met een ethernet/utp-kabel op de connectbox.
Dat heb ik gedaan met behulp van Pingplotter (goede tip van hanh ) en een (Windows 7) laptop.

Mijn dochter heeft ook een Ziggo-aansluiting (40/4) en zij gebruikt een Compal connectbox hardwareversie 5 (5.01 dacht ik om precies te zijn).
Daar werkt mijn Ziggo Go app op mijn iphone prima via haar wifi thuisnetwerk.
Als we nu mijn Arris connectbox met hardware versie 10 vervangen door een Compal connectbox met hardware versie 5, kunnen we testen of het wellicht een probleem betreft die specifiek is voor de Arris connectbox.

[Mark]

Ook hardwareversie 10 (welke ik hier op kantoor heb staan) heb ik geen problemen mee.

Pingtest (pingplotter is niet te installeren, beperkingen op bedrijfslaptop)
C:\Users\...>ping www.facebook.com -t

Pinging star-z-mini.c10r.facebook.com [2a03:2880:f106:86:face:b00c:0:50fb] with 32 bytes of data:
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=16ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=18ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=21ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=10ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=21ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=26ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=20ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=30ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=19ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=74ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=16ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=128ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=87ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=35ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=85ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=84ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=105ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=114ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=78ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=76ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=10ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=37ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=25ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=47ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=15ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=15ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=18ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=25ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=20ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=34ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=16ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=31ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=15ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=13ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=18ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=30ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=16ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=12ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=23ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=32ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=23ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=36ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=33ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=11ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=14ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=28ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=32ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=16ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=19ms
Reply from 2a03:2880:f106:86:face:b00c:0:50fb: time=21ms

Ping statistics for 2a03:2880:f106:86:face:b00c:0:50fb:
Packets: Sent = 75, Received = 75, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 128ms, Average = 27ms
Control-C
^C
C:\Users\...>

IPv6-test.com geeft stabiel dit resultaat:


Mijn laptop is via wifi verbonden en krijgt netjes een IPv4 en IPv6 adres van de Connectbox:


Informatie van onze Connectbox:


DHCPv6 settings:


En kan met die setup ook prima TV kijken via Ziggo GO (in browser en in win10 app)

[hanh]

Hi Mark,

Die 3 sec RA lifetime, blijft toch wel een beetje verdacht.

Instellen op Statefull betekent toch iets anders dan DHCPv6 only!
Er is ook hier sprake van SLAAC ernaast met die 3 sec RA.
Ik vraag me ook af wat Stateless eigenlijk precies doet. Officieel is dit SLAAC met evt DHCPv6 support voor parameters. Kan worden gecontroleerd door bij beide instellingen naar uitgedeelde IPv6 adressen te gaan kijken.
Maar dit voert nu te ver.

Dit werkt & dat is ook belangrijk.

Wat vind jij Jbr67.

Gr Han

[Jbr67]

hanh wrote:
Hi Mark,

Die 3 sec RA lifetime, blijft toch wel een beetje verdacht.

Instellen op Statefull betekent toch iets anders dan DHCPv6 only!
Er is ook hier sprake van SLAAC ernaast met die 3 sec RA.
Ik vraag me ook af wat Stateless eigenlijk precies doet. Officieel is dit SLAAC met evt DHCPv6 support voor parameters. Kan worden gecontroleerd door bij beide instellingen naar uitgedeelde IPv6 adressen te gaan kijken.
Maar dit voert nu te ver.

Dit werkt & dat is ook belangrijk.

Wat vind jij Jbr67.

Gr Han

Hallo hanh en Mark

Goed dat deze test is uitgevoerd. Wellicht brengt het ons weer wat dichter bij een oplossing.

Over die adresseringsoptie. De tekst van die optie geeft aan hoe het ADRES wordt toegekend. Dat is dus of SLAAC, of DHCPv6.

Voor de goede orde. Het verkrijgen van een adres begint ALTIJD (muv handmatig) bij een routeradvertisement (RA). Op basis daarvan leert n device een aantal zaken; de prefix (ALTIJD), de default gateway route (ALTIJD), de houdbaarheid van die route (ALTIJD) en een aantal aanvullende settings. Bij die aanvullende settings KUNNEN opties zitten als de DNS die het device moet gebruiken. Ook kan de RA aangeven of het device bij een DHCPv6 server moet aankloppen voor:
a) het te gebruiken adres. Indien dit is aangegeven heet het statefull adrestoekenning en wordt er via een aanvullende request naar de DHCP-server gevraagd om een IPv6-adres. Indien dit NIET is aangegeven dat moet het device zelf een IP-adres genereren aan de hand van prefix + MAC adres van de interface. Dit heet SLAAC: stateless address autoconfiguration.
b) andere opties zoals DNS/WINS/NTP server etc etc

A en b zijn LOS van elkaar te kiezen. Of en hoe het ziggo modem b doet weet ik niet.

Die router lifetime van 3 seconden zorgt ervoor dat het device steeds maar weer zijn route-tabel moet wijzigen (entry eerst eruit, dan even later er weer in). De aangeraden instelling voor routerlifetime is 3* RA-interval. Dus als de RA-interval op 10 minuten staat, dan wordt 30 minuten voor routerlifetime geadviseerd. Dus los van of het werkt..het is zeker NIET aanbevolen om het zo te doen (en ook echt helemaal nergens voor nodig).

Theorietje: de programmeur van connectbox heeft ipv 3*RA-interval de toekenning 3 gedaan in zijn code.....??

Er zijn nog twee opties over voor TS:
a) onder de motorkap gaan kijken wat er echt gebeurt (met een tool ala wireshark)
b) zijn ipv6 settings op zijn win7 pc handmatig zetten en kijken wat er dan gebeurt (dit om zowel SLAAC als DHCPv6 en routerinterval/routerlifetimes uit te schakelen)

Ciao,
Jbr67

[DenSpike]

Mark Ziggo hanh Jbr67

Mark, dank voor de aanvullende en verhelderende testen!

Op basis van alle thans gevonden resultaten kunnen we veilig concluderen dat het probleem niet in de connectbox zit (noch in het modemgedeelte, noch in het routergedeelte, noch in het wifigedeelte).
Ook ligt het niet aan mijn apparatuur (iphone en/of laptop).

Resteert derhalve het Ziggo netwerk upstream vanaf de connectbox.
Concreet hebben we het dan over:
1 - coaxkabel tussen connectbox en splitter; niet waarschijnlijk, want is splinternieuw
2 - splitter; niet waarschijnlijk, want is splinternieuw en testen met en zonder maken onderling geen verschil
3 - AOP; niet waarschijnlijk, want is compleet vernieuwd en gemonteerd door de Ziggo-monteur in het kader van de powerpromise
4 - resteert het Ziggo netwerk: dit bestaat uit:
4.1 - de groene Ziggo kabel: deze kabel is tenminste 40 jaar oud, maar de Ziggo monteur heeft het signaalniveau/kwaliteit gemeten en in orde bevonden
4.2 - het interne Ziggo-IPv6-netwerk, te onderscheiden in:
4.2.1 - de hardware
4.2.2 - de software
4.2.3 - de netwerkinstellingen

Alles overziend schat ik in dat er ergens iets in het interne Ziggo IPv6-netwerk fout zit.
En dan niet iets algemeens, maar geografisch gebonden aan mijn lokatie (bij Mark was IPv6 immers stabiel en vlekkeloos werkend), of wellicht is er een afhankelijkheid in termen van voormalig Ziggo- of UPC-gebied.

Ik ben het met Jbr67 eens dat er nu eigenlijk niets anders resteert, dan diepgaande metingen uit te voeren met een tool a la Wireshark.
Dit is echter niet iets wat ik kan (noch wil) uitvoeren; maar een Ziggo specialist is van harte welkom op mijn thuisadres (de koffie staat klaar....).

Wat mij betreft moeten we voor mijn probleem”oplossing” dus maar (noodgedwongen) overgaan op de IPv4 mode.
Mark zou jij dat svp willen (laten) regelen?
Uiteraard horen jullie wat de resultaten zijn.

[hanh]

Hi Den,
Duidelijke analyse.
Het is nu verder tussen Ziggo en jou.
Succes met vervolg en eindoplossing.
Blijf geinteresseerd in hoe het afloopt.
Han

[DenSpike]

Mark Ziggo hanh Jbr67

Ter overdenking:
- in de connectbox (hardwareversie 10)zijn de huidige IPv6 DHCP-instellingen zodanig dat een goed werkende IPv6 verbinding (in ieder geval theoretisch) niet mogelijk is
- in de connectbox (hardwareversie 10) zijn de IPv6 DHCP-instellingen niet muteerbaar
- toch heeft Mark aangetoond dat de connectbox (hardwareversie 10) wel degelijk goed werkt op/met IPv6

How can?

Uitgangspunten bij onderstaande redenatie is:
- dat Ziggo zijn modem/routers op specificatie laat maken door derden en daarvoor fabrikanten selecteert op kwaliteit, maar natuurlijk ook op prijs
- dat fabrikanten (onder andere om prijstechnische redenen) bij voorkeur een modem/router zullen aanbieden die een getunede versie is van een modem/router uit hun bestaande productrange

Redenatie:
Stel dat Arris (de leverancier van de connectbox hardwareversie 10) destijds de Ziggo-aanbesteding voor een “nieuwe” connectbox won door het aanbieden van een gemodificeerde versie van een reeds eerder door hen ontwikkelde modem/router.
Stel dat Arris het om één of andere reden onwenselijk vond (of dat het domweg een Ziggo-specificatie was) dat “klanten” de IPv6 DHCP-instellingen zelf kunnen muteren en daarom deze instellingen hardcoded/niet-muteerbaar heeft gemaakt. Het “bestaande” IPv6 DHCP-instellingen menu moest daarvoor natuurlijk worden verwijderd, maar misschien is voor de “quick-and-dirty” oplossing gekozen door het simpelweg “onmuteerbaar” (greyed out) te maken.

Dat zou kunnen verklaren:
- waarom de IPv6 DHCP-instellingen niet muteerbaar zijn gemaakt
- waarom de vreemde (theoretisch niet mogelijke) IPv6 DHCP-instellingen toch goed blijken te werken (dat wil zeggen: niet de vreemde zichtbare waardes, maar de thans voor ons onzichtbare hardcoded waardes)

Snijdt deze redenatie hout?
Indien ja, hoe kunnen we er dan achter komen of Arris inderdaad bewust de IPv6 DHCP-instellingen in de connectbox (hardwareversie 10) onmuteerbaar heeft gemaakt en welke (items en ingestelde waarden) IPv6 DHCP-instellingen er hardcoded in het apparaat zijn aangebracht?

[Jbr67]

DenSpike wrote:
[
Snijdt deze redenatie hout?
Indien ja, hoe kunnen we er dan achter komen of Arris inderdaad bewust de IPv6 DHCP-instellingen in de connectbox (hardwareversie 10) onmuteerbaar heeft gemaakt en welke (items en ingestelde waarden) IPv6 DHCP-instellingen er hardcoded in het apparaat zijn aangebracht?

Zekers!! De enige oplossing die ik zie voor deze black box is meekijken op je w7 machine met wireshark. Dan kun je exact het verloop van zowel RA als Dhcp en hun waardes zien....