Ziggo Go App en Ziggogo.tv



Toon eerste bericht

190 Reacties

Ok duidelijk allemaal.

Mark wil tot het gaatje gaan om te weten te komen wat er kennelijk toch wel mis
is met je ConnectBox.
Ben benieuwd naar hoe dit afloopt.
Gr Han
@Mark Ziggo
Omdat in een pm geen plaatjes zijn te plakken, hier dus de plaatjes van de IPv6 connectivity-testen:

Beste IPv6 connectivity



Slechtste IPv6 connectivity



Om de zaak wat te nuanceren de opmerking dat het gemiddelde resultaat een stuk dichter bij het beste plaatje lag dan bij het slechtste plaatje (klinkt je vast en zeker heel wetenschappelijk onderbouwd in de oren 😉 )

** Aangepast door moderator (Mark) **
Publieke IP adressen in screenshots afgeschermd
Reputatie 7
Thx, en volgens mij zien we hier ook de oorzaak van het symptoom. De IPv6 connectie is aan het haperen, maar hoe we dat gaan verhelpen is een tweede.

Een nieuw modem is al onderweg, om defecten in je huidige modem uit te sluiten. Als het probleem met het nieuwe modem nog steeds speelt gaan we verder kijken.
Ik heb hier nog geen andere soortgelijke meldingen van gezien en ook bij de ontwikkelaars van dit modem is dit geen bekend issue.
@Mark Ziggo
Oke, zodra de nieuwe connectbox arriveert zal ik 'm installeren.
Je hoort de resultaten...
Reputatie 5
Badge +3
Thx, en volgens mij zien we hier ook de oorzaak van het symptoom. De IPv6 connectie is aan het haperen

Kleine duit in het zaakje. De Ziggo go app's (in ieder geval die op Android en IOS) geven de voorkeur aan IPv6 boven IPv4, als beide aanwezig zijn. Ik zag dat bij de browser van TS de voorkeur juist op IPV4 staat. Dat verklaart waarom zijn browser het wel doet en zijn apps (allemaal) niet.

Dat samen is volgens mij een bevestiging dat het idd aan IPv6 ligt Marc! Nu nog de vraag waarom die IPv6 verbinding instabiel is....

Wat hierbij nog wat kan helpen is een kleine test. Open de cmd-prompt op windows7 en geef het volgende commando:
ping -6 -t www.facebook.com
en kijken of de output hiervan erg fluctueert.....

Helaas is het niet mogelijk (voor zover ik weet) om selectief op IOS (of Android) IPv6 uit te zetten. Bij Windows (7/8/10) kan dit wel (en vast ook bij Mac OS X )

Groet,
Jbr67
Reputatie 5
Badge +3
@Rob en @hanh
En aangezien een leasetijd van 0 seconden beredeneerbaar fout moet gaan, denk ik dat het daar ergens moet zitten.
Maar wie o wie kan de IPv6-leasetijd instellen in mijn connectbox?


Dan hoeft met IPv6 an sich niet. Het KAN ook betekenen dat er helemaal geen gebruikt wordt gemaakt van DHCPv6. Met IPv6 is DHCP helemaal niet meer nodig (das het mooie van IPv6, geen gedoe met DHCP meer). Het device kan zelf een uniek en correct IPv6-adres uitrekenen. En het verklaart ook waarom je chromecast een lease-tijd van 0.0.0.0 aangeeft (0.0.0.0 -> geen dhcp gebruikt)
@jbr
" Ik zag dat bij de browser van TS de voorkeur juist op IPV4 staat. Dat verklaart waarom zijn browser het wel doet en zijn apps (allemaal) niet. "

Hoe zag je dat? Zover ik weet wordt onder de motorkap ook voor de Browser
eerst gekeken of er een IPv6 adress is voor de host in de Url. Als dat er is wordt de zaak
via IPv6 afgwikkeld. De host voor Ziggo Go via het Web is Dual Stack.

"Dan hoeft met IPv6 an sich niet. Het KAN ook betekenen dat er helemaal geen gebruikt wordt gemaakt van DHCPv6. Met IPv6 is DHCP helemaal niet meer nodig (das het mooie van IPv6, geen gedoe met DHCP meer)"
Je zult nog raar opkijken hoeveel hosts een DHCPv6 provided adress oppakken.
Je hebt gelijk dat de Chromecast zijn address niet hoeft te hebben gekregen via DHCP, maar
via SLAAC. Daar hoort dan nog wel Stateless DHCPv6 bij voor DNS Server assignment.
Dat het geheel nogal ingewikkeld in elkaar zit bewijst dit 'verhelderende' artikel.
http://www.ciscopress.com/articles/article.asp?p=2154680
Wat raar blijft is dat de ConnectBox een read only lease time field heeft
dat 0 laat zien als DHCPv6 op Statefull staat. Kan altijd nog een schoonheidsfoutje zijn,
want je ziet op apparaten normale lease tijden.

Gr Han
Reputatie 5
Badge +3
@jbr
" Ik zag dat bij de browser van TS de voorkeur juist op IPV4 staat. Dat verklaart waarom zijn browser het wel doet en zijn apps (allemaal) niet. "

Hoe zag je dat? Zover ik weet wordt onder de motorkap ook voor de Browser
eerst gekeken of er een IPv6 adress is voor de host in de Url. Als dat er is wordt de zaak
via IPv6 afgwikkeld. De host voor Ziggo Go via het Web is Dual Stack.

Zie bijgevoegd plaatje in rood omcirkeld .




Je zult nog raar opkijken hoeveel hosts een DHCPv6 provided adress oppakken.
Je hebt gelijk dat de Chromecast zijn address niet hoeft te hebben gekregen via DHCP, maar
via SLAAC. Daar hoort dan nog wel Stateless DHCPv6 bij voor DNS Server assignment.
Gr Han

Het vertrekpunt is (afgezien van handmatig) altijd GEEN DCHPv6. Dan kun je in de router-config aangeven of aanvullend
a) ALLES alsnog via DHCPv6 moet worden verkregen(statefull dhcpv6),
b) of dat alleen zaken als DNS etc via DHCPv6 worden verkregen maar het IPv6-adres zelf dus niet (stateless DHCP)
c) als de router geen a of b aangeeft dan niks (SLAAC).

De netwerkengineers van ziggo hebben deze keuze in instellingen (grotendeels) voor ons gemaakt. Ik heb zelf geen connectbox dus weet niet wat er allemaal mogelijk is om aan te passen.

OOK DNS-server info kan ZONDER DHCPv6 uitgedeeld worden (via de router dus). Maar nogmaals, dit is grotendeels ingesteld voor ons door de ziggo engineers.

Persoonlijk zie ik NUL toegevoegde waarde in DHCPv6 voor de gemiddelde thuissituatie.

Groet,
JBR67
@Jbr67
De tekst achter het vraagtekentje is:

Fallback. Whether or not your Browser falls back
to the other protocol if its default above does not work.

Dat werd getest.

Gr Han
Reputatie 5
Badge +3
@Jbr67
De tekst achter het vraagtekentje is:

Fallback. Whether or not your Browser falls back
to the other protocol if its default above does not work.

Dat werd getest.

Gr Han


Correct , beiden werken dus. Als ipv4 binnen seconde geen response geeft dan over naar IPv6. V4 default, V6 achtervang. Dit geldt voor de browser die gebruikt werd voor deze test.
@jbr63
Nee, nee zo werkt het niet vlgs mij.

Onder de motorkap wordt via een DNS request bekeken of er een IPv6 address is.
Zo ja dan verloopt het geheel over IPv6.
Mocht er iets mis gaan met deze connection dan is er binnen 1 sec fall back op IPv4.

Whether or not your Browser falls back
to the other protocol if its default above does not work.

IPv6 (=above) is kennelijk de al vastgestelde default van de Browser.

Gr Han
Reputatie 7
Badge +35
Inderdaad fenomeen fallback naar IPv6.

Hier precies andersom:

Reputatie 7
Badge +35
Als iemand last heeft van dit fenomeen, dan aan de helpdesk vragen of ze je naar IPv4 zetten.
@Be rt
Sorry, ik begrijp je niet.
Gr Han
@Jbr67

Het vertrekpunt is (afgezien van handmatig) altijd GEEN DCHPv6. Dan kun je in de router-config aangeven of aanvullend
a) ALLES alsnog via DHCPv6 moet worden verkregen(statefull dhcpv6),
b) of dat alleen zaken als DNS etc via DHCPv6 worden verkregen maar het IPv6-adres zelf dus niet (stateless DHCP)
c) als de router geen a of b aangeeft dan niks (SLAAC).

De netwerkengineers van ziggo hebben deze keuze in instellingen (grotendeels) voor ons gemaakt. Ik heb zelf geen connectbox dus weet niet wat er allemaal mogelijk is om aan te passen.

OOK DNS-server info kan ZONDER DHCPv6 uitgedeeld worden (via de router dus). Maar nogmaals, dit is grotendeels ingesteld voor ons door de ziggo engineers.

Persoonlijk zie ik NUL toegevoegde waarde in DHCPv6 voor de gemiddelde thuissituatie.


Hi,

Eigenlijk vind ik dit behoorlijk lastige stuff.
Vind het dus moeilijk om hierover met je in diskussie te gaan, laat staan hier.
Vind het wel interessant wat je schrijft.
Het is ook nogal technisch allemaal.

Ik benader je hierover wel via PM.
Iets van elkaar leren is nooit weg.

Gr Han
Reputatie 5
Badge +3
@jbr63
Nee, nee zo werkt het niet vlgs mij.

Onder de motorkap wordt via een DNS request bekeken of er een IPv6 address is.
Zo ja dan verloopt het geheel over IPv6.
Mocht er iets mis gaan met deze connection dan is er binnen 1 sec fall back op IPv4.

Whether or not your Browser falls back
to the other protocol if its default above does not work.

IPv6 (=above) is kennelijk de al vastgestelde default van de Browser.

Gr Han


Hallo Han,

dank voor je reactie/vraag. Volgens mij wordt met "default above" het veld daarboven bedoeld. Daar staat dat voor deze browser IPv4 de default is.

Reputatie 5
Badge +3

Hi,

Eigenlijk vind ik dit behoorlijk lastige stuff.
Vind het dus moeilijk om hierover met je in diskussie te gaan, laat staan hier.
Vind het wel interessant wat je schrijft.
Het is ook nogal technisch allemaal.

Ik benader je hierover wel via PM.
Iets van elkaar leren is nooit weg.

Gr Han

Is ook best veel... en inderdaad technisch. Ik zal even op je PM reageren...en idd: leren is nooit weg! Sterker nog, ook n beetje de bedoeling hier volgens mij! 😉
@jbr63
Shit. Je hebt helemaal gelijk over die default.
Shame on me. Niet goed genoeg gekeken!
Zag dit soort plaatjes teveel met IPv6 als default. Is geen excuus.

Uitstekende bijdrage!
En ook: Hm, wat betekent dit eigenlijk precies voor het probleem?
En waarom kiest de Browser default voor IPv4? Is niet de standaard,
zoals ik die ken.
Denken, denken.

Gr Han
Reputatie 5
Badge +3
@jbr63
Shit. Je hebt helemaal gelijk over die default.
Shame on me. Niet goed genoeg gekeken!
Zag dit soort plaatjes teveel met IPv6 als default. Is geen excuus.

Uitstekende bijdrage!
En ook: Hm, wat betekent dit eigenlijk precies voor het probleem?
En waarom kiest de Browser default voor IPv4? Is niet de standaard,
zoals ik die ken.
Denken, denken.

Gr Han

Geen probleem Han!

Waarom DIE browser de voorkeur geeft aan IPv4, ligt denk ik de instellingen onder de motorkap van die browser (ik meen Edge icm Windows7?). Hoe dan ook, het past perfect bij het geschetste probleem. De browser probeert v4 eerst, de app(s) v6 eerst.

Ik heb het net op mijn windows10-bak even getest met een setje browsers:
- Chrome, Edge, Firefox: default IPv6
- Internet Explorer : default IPv4

Groet,
Jbr67
PS. Wat leesmateriaal over Windows en v6 voor v4 of juist andersom. Pffff.... wat een gedoe:
https://support.microsoft.com/en-us/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users
Ja & duidelijk.
Ik zit nog met iets anders.
Ok, de Browser kiest voor Ipv4,
Dat zegt dat Web App goed werkt over Ipv4.

Maar de Web App is niet exact de App, die vermoedelijk over IPv6 werkt en mis gaat.

Wat zou ik willen?
De Web App laten werken over IPv6 en de App over Ipv4.

Ik ben web ontwikkelaar genoeg om te weten dat App en Web App technisch (onder de motorkap)
en qua look and feel nauwelijks van elkaar hoeven te verschillen. 1 opzet voor beiden.
Maar ik wil iets zeker weten via tests.
Hoe krijgen we dit voor elkaar?

Nou voor de Web App Chrome gebruiken ipv IE bv.
Maar TS heeft een klapperende IPv6 sowieso! Vervelende complicatie.

Het is me net iets te makkelijk om nu al te denken:
App en Web App werken over Ipv4.
App en Web App werken niet over IPv6.
Ik verwacht wel dat dit zo zal zijn, maar weet nog niks zeker.

Het is hier lastig.
Ben ik nog wel te volgen?

Gr Han
Reputatie 7
Het vertrekpunt is (afgezien van handmatig) altijd GEEN DCHPv6.Ah, nu valt bij mij ook het kwartje. Met een stateless IPv6 configuratie verstrekt het modem natuurlijk geen lease dus is de leasetime niet van toepassing. Zet je dit om naar stateful dan zal het wel aan te passen zijn.

Wat hierbij nog wat kan helpen is een kleine test. Open de cmd-prompt op windows7 en geef het volgende commando:
ping -6 -t www.facebook.com
en kijken of de output hiervan erg fluctueert.....
Hier ben ik ook erg benieuwd naar, zou je dit kunnen testen @DenSpike?
@Mark Ziggo
De Lease Time van Statefull DHCPv6 was 0 en readonly.
Zie het plaatje dat TS in een eerder stadium aanleverde.

Hij vond dat vreemd. Ik ook, maar opperde dat dit ee bugje van de ConnectBox was.
Apparatuur die een lease kreeg, vertoonde op dat moment ook een normale leasetijd.
Op de Chromecast na. Had die nog een SLAAC address?

Eigenlijk snap ik die instelling op de ConnectBox niet helemaal.
Mijn Dual Stack heeft een Statefull DHCPv6 Server waar je niks aan kunt instellen.
Mijn hosts krijgen een DHCPv6 Address, maar pakken ook 1 of meer SLAAC adressen erbij.
Dwz Statefull DHCPv6 leeft samen met SLAAC.
Bij de ConnectBox lijkt dit het een of het ander te zijn.
Ik vraag me dus af: wat zijn de IPv6 address assigments op een host?

Gr Han
@Mark Ziggo en @ alle andere geïnteresseerde topic-schrijvers/lezers....
Zoals afgesproken heb ik de "nieuwe" Connectbox aangesloten en getest.
Allereerst de mededeling dat de "nieuwe" Connectbox dezelfde Hardware en software versies heeft als de oud (respectievelijk 10 en 9.1.116.605).
Ook zijn de configuratiebestanden identiek (internet200_20_nowifi_v6-sip.bin).

Het spijt me te moeten constateren dat de "nieuwe" Connectbox (op ALLE fronten ) exact hetzelfde functioneert als de oude.
De Ziggo Go app (van mij, m'n dochter en m'n zoon) werkt niet via wifi van mijn thuisnetwerk.
De test-ipv6.com geeft eveneens volkomen onstabiele en niet-reproduceerbare resultaten.
Tot slot nog de opmerking dat bij de Geavanceerde instellingen/DHCP de diverse configuratievelden grijs zijn gearceerd en dus niet muteerbaar zijn.

De conclusie moet dus zijn dat er (zeer waarschijnlijk) geen exemplarische (hardware- en software- ) fout zit in de 2 connectboxen.
Steeds meer wordt duidelijk dat de fout zit in een onjuiste IPv6 configuratie (hardware, software of een combinatie hardware/software).

Vermeldenswaardig is nog dat ik dit weekend de connectbox-instellingen van mijn dochter eens heb bekeken (zij heeft overigens een 40/4 abonnement en ik een 200/20).
Allereerst valt op dat de DHCP-configuratievelden daar wel muteerbaar zijn.
De ingestelde waardes lijken me volkomen logisch (DHCP leasetijd 1 week, en ook de router advertisement lifetime waarde is met 86.400 logischer dan de 3 seconden uit "mijn" connectboxen).
Helaas zijn er echter wel verschillen tussen "haar" en "mijn" connectboxen:
- haar hardwareversie is 5.01
- haar softwareversie is CH7465LG-NCIP-4.50.18-4ml-GA-NOSH
- haar configuratiebestand is internet40_4_nowifi_v6.bin

Het lijkt mij dat door uitsluiting het mogelijk moet zijn om de bron van de foutoorzaak duidelijker te krijgen.
Is het in dat kader mogelijk om "haar" configuratiebestand in één van mijn connectboxen te pushen?
Als dat probleemloos werkt weten we dat "mijn" configuratiebestand de boosdoener is.
Als het echter niet probleemloos werkt (en bv de DHCP velden vreemde waardes bevatten en niet muteerbaar blijken) dan zit het het probleem in de hardware/software van "mijn" connectboxen.
Graag je reactie op dit voorstel.

Dan nog even antwoord op de twee issues uit jouw laatste topic-reactie:
1-
De DHCP configuratie velden blijven gearceerd en dus niet-muteerbaar onafhankelijk of er Stateful of Stateless staat ingesteld.
2-
Hieronder de screenshots voor pingen op IPv6-basis, op IPV4-basis en zonder verdere switch op IP-basis.

IPv6



IPv4

"kale"ping (geen switch)



Zal me nu gaan buigen over de reakties van de diverse community-members (kan niet alles inhoudelijk volgen, maar ik doe m'n best en zal naar vermogen antwoorden geven)
Reputatie 5
Badge +3
Ja & duidelijk.
Ik zit nog met iets anders.
Ok, de Browser kiest voor Ipv4,
Dat zegt dat Web App goed werkt over Ipv4.

Maar de Web App is niet exact de App, die vermoedelijk over IPv6 werkt en mis gaat.

Wat zou ik willen?
De Web App laten werken over IPv6 en de App over Ipv4.

..

Nou voor de Web App Chrome gebruiken ipv IE bv.
Maar TS heeft een klapperende IPv6 sowieso! Vervelende complicatie.

Het is me net iets te makkelijk om nu al te denken:
App en Web App werken over Ipv4.
App en Web App werken niet over IPv6.
Ik verwacht wel dat dit zo zal zijn, maar weet nog niks zeker.

Het is hier lastig.
Ben ik nog wel te volgen?

Gr Han

He Han, de browser over v6 dat wil nog wel lukken (chrome proberen bijv.) maar de app is niet te wijzigen volgens mij. Een test met een v6 browser zou dan moeten falen, om te passen bij het probleem tot nu toe.

Reageer