Experiabox V10 start op met 1970 jaartallen, heeft geen verbinding binnen eigen netwerk

Dat jaartal bij opstarten is normaal. Het modem haalt tijd en datum op via een NTP server, zo lang er geen verbinding is staat de datum en tijd dus verkeerd.

Je hebt via de V10 wel internet? Wat werkt er dan niet? De devices er op aangesloten krijgen geen adres of zoiets?

Mijn TV kastjes krijgen geen IP adres meer, mijn NAS wel maar is niet te benaderen en mijn privé PC krijgt een IP adres uit een totaal verkeerde range (zelf 192.168.2.x gekozen, maar krijgt nu 169.x.x.x). Onwerkbaar 😔 … Als dan alles is verbonden vallen de geconnecte apparaten 1 voor 1 weer uit de router. Ik heb via een USG van Ubiquity nog een netwerk draaien op 192.168.1.x voor mijn werkzaamheden. Daar zijn geen problemen mee. Lijkt met name het bedrade netwerk direct aan de KPN router gekoppeld te zijn. 

1 januari 1970 00:00 is de starttijd van de Unix Epoch. Vrijwel ieder apparaat dat op basis van Unix werkt zal hierop terugvallen indien de tijd niet opgevraagd kan worden bij een NTP-server.

Dat is een APIPA-adres welke apparaten krijgen als ze geen communicatie kunnen verkrijgen met de toegewezen DHCP-server in het netwerk. Zou je voor de zekerheid eens je USG volledig los kunnen koppelen? Ik zeg niet dat het probleem hier in zit maar het is altijd handig om zaken uit te sluiten. Zou je ook eens een screenshot van de DHCP-instellingen van de Experiabox V10 kunnen plaatsen? Mogelijk is hier per ongeluk iets foutief in ingesteld.

Ik ben ook even aan het denken, het is namelijk best bijzonder dat het apparaat opeens minder werkt maar op een eigen router achter de Experiabox dan weer wel. De verbindingen naar je USG lopen namelijk ook allemaal via de router in de Experiabox. Als de hele Experiabox overleden is dan zou de USG ook niet meer moeten werken.

Ik haak af. Twee keer gevraagd of er wel internet is. Geen antwoord. Succes verder.

@Clifford Wissink Nee hoor, @Ernst-Jan heeft helemaal geen kort lontje, hij stelt jou twee keer dezelfde vraag en er komt twee keer een lang betoog zonder die simpele vraag te beantwoorden of er op in te gaan.

Misschien heb je het niet door, maar hier helpen klanten elkaar en indien nodig springt er een KPN moderator bij als dat nodig is, tot nu toe ben je te woord gestaan door mede klanten en een KPN monteur die in zijn vrije tijd het leuk vind om problemen op te lossen, dus een beetje respect is wel op zijn plaats in deze.

De nood voor 192.168.2 is er ook niet , zou mooi zijn dan zou de standaard 192.168.178 range van de Fritzbox nooit werken.. 

Ofwel met Fritzbox nooit TV tenzij je hem aanpast. 

Nee deze noodzaak is er echt niet..

Wel is de noodzaak dat ze IP uit de ExperiaBox krijgen, Dit kan eventueel wel via eigen router maar dan moet deze wel de PPP sessie opbouwen en de VLAN geconfigureerd hebben staan (bij glasvezel gaat dit wel bij DSL moet je uiteraard een router met DSL hebben)

Maargoed even terug naar de basis kan je de bij de V10 eens alle lan kabel eruit trekken, Deze resetten en dan eens met laptop op LAN kijken wat er gebeurt, Doet deze het dan e dan is de V10 in orde en kan je verder kijken

• TVs erop..  Werken deze dan nu ? 
• USG er weer aan.. werkt het dan nog ?

Unmanaged switches.. hebben deze ondersteuning voor IGMP, want dit zie je vaak alleen bij managed switches terug.

Dit is wel een vande vereiste voor de STBs anders krijg je te maken met flooding van het TV signaal naar alle clients achter de switches, met mogelijk alle gevolgen van dien.

Goed om te horen dat je nu wat meer duidelijkheid hebt, Zal beginnen met switches weer even aansluiten en dan alleen ITV op de switches, en dan gewoon rustig verder doorbouwen en kijken waneer het zich weer voordoet.

Staat de NAS op een statisch of gewoon op DHCP ? En als je deze met LAN direct op ExperiaBox koppel krijgt deze dan wel een IP toegewezen ?

EDIT; Als het gaat om de Zyxel gs-108b dan zal ik deze niet gebruiken om TV op aan te sluiten. Gezien deze geen IGMP snooping ondersteunen.

IGMP snooping houdt in dat de switch actief het verkeer controleert op zogenaamde multicast data. Deze data wordt alleen doorgestuurd naar de juiste apparaten en niet naar elk apparaat in het netwerk.

“Mijn zoon heeft dit weekend een Chromecast bedraad in het 192.168.2.x netwerk gehangen en toen zijn de problemen begonnen.”

En daar kom je dan nu pas mee… heel betoog dat het altijd gewerkt heeft. Zeg dat dan meteen.

De V10 is dus ok. Mooi, dat scheelt. Hangt die Chromecast nog steeds in het netwerk (boven)?

Ik schat de kans op 95% dat 1 van de switches of de Chromecast flooding veroorzaakt. Wat moest er gebeuren om die Chromecast werkend te krijgen? Wat cast ernaar die Chronecast? Wat heeft zoonlief nog meer gedaan?

Bij een bedrijf konden ooit 800 medewerkers niets meer doen door 1 netwerk kaart die defect geraakt was.

En nee, geen kort lontje. Maar wel 40 jaar netwerk ervaring. En als je oplossingen wil moet de diagnose goed zijn. Mijn vraag of internet werkt was gebaseerd op het feit dat als die kant van de V10 defect zou zijn er natuurlijk van alles kan gebeuren.

Enfin; het opnieuw “opbouwen” stap voor stap lijkt een goed idee.

Het hele tracé vanaf Experia Box tot the ITV boxen moet IGMP snooping ondersteunen..

overigens een chromecast op bedraad ?? Zover ik weet zijn er geen met een RJ45 aansluiting. Dit klinkt voor diagnose interesant want als deze een WiFi koppeling heeft en via een adapter oid via LAN een netwerklus creert dan is het opeens allemaal heel verklaarbaar.. want dan klapt alles eruit door deze loop…

Edit; lees nu pas hey nieuwe bericht maar ook de Chromecast werkt met Multicast verkeer ofwel geeft ook zonder IGMP snooping flooding op je netwerk.

Bedraad en WiFi? Tegelijkertijd? Suggestie van LaurensZalm lijkt me een goede; ergens ontstaat wellicht een ongewenste brug tussen je twee segmenten… met een enorme flood van broadcast packets.

Door het gebrek aan IGMP snooping want zowel de ITV streams als de cast naar de chromecast zijn Multicast verkeer en dit gaat overal heen ( Flooding ) tenzij alles in het tracé IGMP snooping ondersteund want dan gaat het alleen naar de bron waar het hoort.

Goeie stap zal zijn te investeren in switches die dit protocol wel ondersteunen, en kijk er specifiek naar want ook niet iedere managed heeft dit standaard in huis

Binnen mijn netwerk IP 192.168.2.x alle unmanaged switches vervangen voor TP-LINK managed switches (5 en 8 poorts). Alles weer up and running. In router netjes alles DHCP fixed IP adressen gegeven aan belangrijkste apparaten. NAS werkt weer als een zonnetje.

Voor zover ik nu kan achterhalen was 1 van mijn switches kaduuk. Toen ik die switch vervangen had voor een nieuwe begon alles weer te ratelen en kwamen de juiste IP adressen weer terug, ook op mijn PC. Vreemd en nog steeds beetje onverklaarbaar omdat het een super simpele switch was, puur doorgifte van verkeer zonder management. Positieve bijkomstigheid, weer alles netjes in de meterkast en digitaal ook weer mooi opgeschoond en gedocumenteerd. Op naar de volgende crash en dan weer opnieuw op zoek … in ieder geval eenieder hier bedankt voor de support 👍🏻👍🏻