Regelmatige onderbrekingen in glasvezelverbinding

Hoi,

Voordat we de oorzaak bij de glasvezelverbinding zelf leggen, zou ik eerst een paar dingen over de netwerkconfiguratie willen uitsluiten. Dat je interne LAN tijdens een storing bereikbaar blijft, zegt namelijk alleen dat je LAN zelf blijft functioneren. Daarmee is nog niet vastgesteld waar het probleem tussen de eigen router en het KPN-netwerk precies zit.

Je geeft aan dat je een eigen router achter de KPN Box 12 gebruikt en dat deze als DMZ-host is ingesteld. Kun je aangeven:

• Welk merk en type eigen router gebruik je?

• Is de kabel vanaf een LAN-poort van de Box 12 aangesloten op de WAN/Internet-poort van de eigen router?

• Welk IP-adres krijgt de WAN-kant van je eigen router?

• Welk LAN-IP-adres gebruikt de eigen router?

• Welke DHCP-server is op beide apparaten ingeschakeld?

• Gebruiken de Box 12 en de eigen router verschillende IP-subnetten? Bijvoorbeeld Box 12: 192.168.2.x en eigen router: 192.168.1.x.

• Staat de DMZ van de Box 12 daadwerkelijk ingesteld op het WAN-IP-adres van de eigen router?

Dat laatste is belangrijk, want met twee routers is het prima mogelijk om twee DHCP-servers te hebben, maar niet op hetzelfde LAN-segment. De Box 12 verzorgt dan DHCP voor zijn eigen netwerk en de eigen router voor het netwerk daarachter.

Daarnaast ben ik vooral benieuwd naar het glasvezelkastje zelf. Op het moment dat de internetverbinding wegvalt: wat doen de lampjes op de ONT/NT? Een foto van de lampjes tijdens een storing zou zelfs ideaal zijn.

Afhankelijk van het type ONT zie je bijvoorbeeld Power, PON/Glas, LAN of bij nieuwere XGS-PON-apparatuur Power, Connection en Alarm. Bij een normale werkende verbinding hoort de glasvezelverbinding daar stabiel aangegeven te worden. Een knipperende PON/Connection-indicatie of een brandend Alarm kan juist belangrijke informatie geven over de verbinding tussen de ONT en het KPN-netwerk.

Als je tijdens een storing kunt aangeven:
1. welke lampjes branden, 2. welke knipperen en 3. welke uit zijn, dan kunnen we al veel gerichter bepalen of het probleem vóór de Box 12 zit, tussen de Box 12 en de eigen router, of verderop in het eigen netwerk.

Je geeft aan dat KPN bij een lijnmeting ook onderbrekingen heeft gezien. Dat is uiteraard relevante informatie, maar ik zou eerst graag weten wat de ONT zelf aangeeft op het moment dat zo'n onderbreking daadwerkelijk optreedt.

Interne router is een Netgear R7000, en de KPN Box 12 blijft online en zichtbaar vanaf het LAN netwerk (reageert op pings) tijdens zulke outages. Een van de LAN Poorten van de KPN Box 12 staat verbonden met de WAN poort van de R7000. 

De subnets zijn zo opgezet:

192.168.2.x = KPN Box 12’s subnet, naast DMZ en statische IP configuratie staat deze op fabrieksinstellingen
192.168.0.x = Netgear R7000’s subnet, en deze router heeft 192.168.2.3 als IP op het KPN subnet (statisch IP)

Er is nog een 192.168.1.x subnet, maar dat is voor het WiFi netwerk, en dat wordt beheerd door een Netgear Orbi router, die als 192.168.0.3 geregistreerd staat op het subnet van de R7000. En heeft daardoor hetzelfde probleem tijdens zo’n storing als mijn desktop en NAS die direct op het R7000 subnet staan.

DHCP staat nog aan op de KPN Box 12 voor de KPN TV Box (IPTV), want dat is het enige wat niet via het 192.168.0.x LAN loopt.
Daarnaast heeft de R7000 ook een DHCP server lopende voor zijn LAN-zijde, maar bijna alles wat daarmee verbonden staat (WiFi Router, PCs, NAS), hebben statische IPs.
In alle gevallen zijn statische IPs zo opgezet dat ze gereserveerd worden op MAC address door de DHCP server.

De DMZ staat correct ingevuld in de KPN Box 12 (volgensmij via de drop-down van beschikbare clients).

Maar als er in al deze configuraties iets fout zou staan, zou dat permanent problemen geven voor al het verkeer, niet enkele minuten per dag. En, dan zou er een verbinding tussen netwerkapparaten niet functioneren tijdens een storing, en via pings en traceroutes heb ik al kunnen vaststellen dat alles intern online blijft en verbinding met elkaar heeft. Het is echt de verbinding tussen de KPN Box 12 en het internet (via het ONT kastje) wat problemen heeft. En de kabel die de KPN Box 12 met het ONT verbindt heb ik ook al vervangen met een CAT 7 die ik nog had liggen, maar dat verbeterde ook niks.

ONT model is een Nokia met LEDs voor Power, Connection, Alarm, en Data
Power en Connection zijn momenteel groen
Alarm is uit
Data knippert groen

Ik heb jammer genoeg nog niet gezien wat de lampjes doen tijdens een storing.

Ik weet niet of het ONT wellicht zelf logboeken bijhoudt, of dat wellicht de andere kant van de lijn (KPN verdeelbox) logboeken heeft hiervoor? Klantenservice heeft in het verleden telefonisch benoemd dat ze na een lijnmeting wat extra logging kunnen aanzetten indien de verbinding op korte termijn weer onderbroken wordt. Maar daar heb ik destijds niks meer over teruggehoord (probleem loopt al enkele maanden).

Dank voor je uitgebreide antwoord. Je netwerkconfiguratie lijkt op basis hiervan niet direct de oorzaak te zijn.

Je geeft aan dat de Box 12 tijdens een storing vanaf je LAN blijft reageren. Dat zegt echter alleen dat het LAN-gedeelte van de Box 12 actief blijft. Interessanter is wat er op dat moment met de WAN- en PPP-verbinding gebeurt.

Ik heb hieronder een screenshot van mijn eigen Experia Box als voorbeeld toegevoegd. Het gaat dus nadrukkelijk niet om jouw verbinding. Op deze pagina zie je onder andere de WAN-status, de bitrate, de PPP-status en de tijd dat de PPP-sessie actief is.

Zou je bij de volgende storing rechtstreeks kunnen inloggen op jouw Box 12 en bij Internetverbinding → Informatie willen kijken wat daar op dat moment staat? Een screenshot van die pagina tijdens de storing zou erg nuttig zijn.

Met name de PPP-status en Tijd actief zijn interessant. Als je tijdens een storing bijvoorbeeld nog steeds PPP-status: Verbonden ziet en de tijd actief niet opnieuw is begonnen, dan weten we dat de PPP-sessie niet is weggevallen.

Daarnaast zou ik graag willen weten wat de LED's op het ONT/glasvezelkastje op datzelfde moment doen. Als je daar een foto van kunt maken tijdens de storing, hebben we twee belangrijke meetpunten:

1. Box 12: WAN/PPP-status
2. ONT: status van de glasvezelverbinding

Daarmee kunnen we een stuk beter bepalen waar de onderbreking daadwerkelijk plaatsvindt, in plaats van direct aan te nemen dat de glasvezelverbinding zelf defect is.

Ik ben momenteel jammer genoeg niet thuis, dus heb ik de ONT LEDs niet kunnen waarnemen, en heb ik niet kunnen inloggen op het modem tijdens de storing (volgensmij een tamelijk korte ditmaal, watchdogs checken eenmaal per 5 minuten en hebben deze niet geregistreerd). Ik was verbonden via mijn VPN die wegviel. Wel heb ik het volgende kunnen waarnemen via een RDP sessie nadat de storing weer voorbij was:
 

(Belangrijkste gedeeltes van MAC & WAN IP zijn natuurlijk weggehaald i.v.m. privacy)

Maar dit geeft aan dat bijna 7 dagen geleden de PPP sessie inderdaad opnieuw is begonnen. Verrassend genoeg komt dit niet overeen met een van de bij mij bekende storingen. Maar ik weet wel dat de laatste reset ongeveer twee weken geleden is geweest, dus de PPP sessie is op z’n minst eenmaal opnieuw begonnen. Dit kan niet door stroomverlies zijn gekomen, mijn NAS staat namelijk op dezelfde stroomgroep, en die heeft nu een uptime van 4 maanden.

Wat wellicht mogelijk is, en waar ik in mijn vorige bericht even niet aan heb gedacht, ik heb in mijn modem IPv6 uitgezet, omdat intern alles IPv4 gebruikt, ook op de R7000 staat IPv6 uit. Ik weet niet zeker of dit een nieuwe PPP sessie opstart of niet. Maar deze instelling heeft niks veranderd in de storingen/symptomen, of de frequentie daarvan.

Zodra het me lukt om de LEDs tijdens een storing te zien zal ik dat laten weten, maar nu de vakantie voorbij is kan dat wellicht wat langer duren. Stel dat daar een paar weken voor nodig zijn (zeker met de regelmaat waarop de problemen zich voordoen), is dat een probleem? of kan deze forumkwestie / ticket zonder problemen meerdere weken open blijven?

Je opmerking over het uitschakelen van IPv6 is interessant, maar aangezien je dit niet kunt koppelen aan de daadwerkelijke storingen, lijkt me dat niet direct de oorzaak.

We kunnen het ondertussen wel vrij eenvoudig nog verder isoleren zonder je bestaande netwerk aan te passen. Je zou op de Box 12 tijdelijk Extra wifi kunnen inschakelen en daar bijvoorbeeld een herkenbare SSID zoals TEST-KPN aan kunnen geven.

Bij de eerstvolgende storing kun je dan met bijvoorbeeld je telefoon of laptop rechtstreeks met die wifi verbinden en testen of internet op dat moment werkt.

Als internet via de Box 12-wifi tijdens de storing gewoon werkt, terwijl je eigen netwerk achter de R7000 geen internet heeft, dan weten we dat we het probleem moeten zoeken in de R7000 of in de verbinding tussen de Box 12 en de R7000.

Als ook de Box 12-wifi tijdens de storing geen internet heeft, dan is het probleem duidelijk niet beperkt tot je eigen router en wordt het juist interessant om op datzelfde moment naar de PPP-status en de leds van de Nokia-ONT te kijken.

Daarmee kunnen we eigenlijk met één eenvoudige test het probleem een stuk verder isoleren, zonder dat je je huidige configuratie hoeft te wijzigen.

Wat mij betreft is dit een betere eerste test dan meteen allerlei instellingen aan de R7000 te veranderen.

Maar, we hebben al vast kunnen stellen dat het probleem niet aan de R7000 ligt. Stel dat de verbinding tussen de R7000 en KPN Box 12 weg zou vallen, dan zou ik tijdens een storing niet de KPN Box 12 kunnen pingen, omdat dat netwerk in dat moment niet routable zou zijn. Daarintegen zie ik dat de KPN Box 12 nog verbonden staat en op pings reageert vanaf mijn mainnet (192.168.0.x), maar alles wat naar het internet gaat faalt op die laatste stap van de KPN Box 12 naar buiten.

Dit extra “TEST-KPN” Wifi netwerk zou iets isoleren wat al geisoleerd is. Zelfde met de harde reset van het modem, heb ik nu al drie maal moeten uitvoeren omdat dat de “procedure” is van de telefonische klantenservice. Ondanks dat ik weet dat het niks gaat helpen, want als dat het probleem zou zijn geweest zou het de vorige keer al opgelost zijn. Gezien dat ik daar al aan het einde van alle bekende diagnosestappen ben gekomen, was mij aanbevolen om hier te posten.

Hoi ​@Erebus, welkom op onze community! Deze community is bedoeld als een plek waar klanten elkaar kunnen helpen. Ik zie dat ​@Sacratus1977 al goed meedenkt. Als er een issue met de glasvezelkabel of het glasvezelkastje is zouden mijn telefonische collega's dat eigenlijk wel vast moeten kunnen stellen.

Inhoudelijk heb ik verder niet veel verstand van een netwerkopstelling als de jouwe, er zijn hier wel een paar handige topics over geschreven:

Ja, ik ben eigenlijk wel benieuwd wat voor problemen de lijnmeting die de telefonische medewerkers hebben uitgevoerd heeft gevonden. Ik had telefonisch al gevraagd of zulke logboeken beschikbaar waren om wellicht meer informatie te krijgen betreffende het probleem, ik heb destijds even in de wacht gestaan omdat de medewerker niet helemaal bekend was of dat mogelijk was (zal waarschijnlijk ook niet echt een vraag zijn die dagelijks voorkomt). Maar daar is destijds jammer genoeg niks uitgekomen omdat de medewerker daar niks over kon zien, ik weet niet of jullie back-office wellicht meer details kan inzien, maar als eindgebruiker kon ik daar niet mee doorverbonden worden.

Daarnaast realizeer ik me nu dus ook, als er een lijnmeting is uitgevoerd waar regelmatig onderbrekingen of andere problemen zijn gezien, wijst dat er alleen meer op dat mijn interne infrastructuur geen probleem vormt. Hoe het netwerk acther mijn KPN Box 12 ook geconfigureerd staat, kan geen verschil maken voor de verbinding tussen de KPN Box 12 en KPN, en dat is het netwerksegment wat met een lijnmeting doorgemeten wordt.

Oke, gisteren nog een storing meegemaakt, tenzij dat we te laat zijn geweest om de lampjes op het ONT te zien, veranderen de lampjes niet van wat we gewoonlijk zien. Tijdens de storing waren de lampjes als volgt:
Power en Connection zijn  groen
Alarm is uit
Data knippert groen

Ik kan niet uitsluiten dat het ONT kort iets anders heeft aangegeven en daarna weer teruggegaan is naar normale operatie. Ook heb ik opgemerkt dat de PPP sessie opnieuw is begonnen, die heeft momenteel een ‘Time Active’ van 17 uur:
 

De volgende logboeken zijn te zien op de KPN Box rond de tijd van die storing:

Sep 11 23:19:44 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [b0:***] and friendly name [DIW7022-CED298]
Sep 11 23:19:43 | SYSTEM | dhcp | 4041 | device name [DIW7022-CED298]
Sep 11 22:58:20 | HOME_LAN | firewall | 3494 | PortForwarding rule was deleted successfully
Sep 11 22:00:55 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [e4:***] and friendly name []
Sep 11 21:19:43 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [b0:***] and friendly name [DIW7022-CED298]
Sep 11 21:19:43 | SYSTEM | dhcp | 4041 | device name [DIW7022-CED298]
Sep 11 20:00:55 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [e4:***] and friendly name []
Sep 11 19:19:43 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [b0:***] and friendly name [DIW7022-CED298]
Sep 11 19:19:43 | SYSTEM | dhcp | 4041 | device name [DIW7022-CED298]
Sep 11 18:58:18 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [a6:***] and friendly name [iPhone]
Sep 11 18:58:18 | SYSTEM | dhcp | 4041 | device name [iPhone]
Sep 11 18:19:55 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [a6:***] and friendly name [iPhone]
Sep 11 18:19:55 | SYSTEM | dhcp | 4041 | device name [iPhone]
Sep 11 18:00:55 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [e4:***] and friendly name []
Sep 11 17:55:10 | INTERNET | nemo-core | 2727 | DHCP client UP: Connection Established - IP: [10.46.49.***], Lease Time: [86400], DHCP Server: [10.46.48.1]
Sep 11 17:55:10 | INTERNET | nemo-core | 2727 | DHCP client UP: Connection Established - IP: [10.46.49.***], Lease Time: [3600], DHCP Server: [10.46.48.1]
Sep 11 17:51:22 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [a6:***] and friendly name [iPhone]
Sep 11 17:51:22 | SYSTEM | dhcp | 1647 | '[USER][SYSTEM] - [i]' repeated 1 times, suppressed by syslog-ng on mijnmodem.kpn
Sep 11 17:51:21 | SYSTEM | dhcp | 4041 | device name [iPhone]
Sep 11 17:20:04 | SYSTEM | nmc_core | 3305 | Stb B0:*** is connected.
Sep 11 17:20:03 | HOME_LAN | gmap_eth | 4645 | Ethernet device LLADDR = E4:*** is connected on port(ETH0) at 1000 mbps Full duplex
Sep 11 17:20:03 | SYSTEM | usbhosts | 1647 | '[USER][SYSTEM] - [i]' repeated 5 times, suppressed by syslog-ng on mijnmodem.kpn
Sep 11 17:20:02 | SYSTEM | usbhosts | 6731 | Dongle successfully initialized
Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Energy set to Auto configuration
Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Duplex set to Auto configuration
Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Speed set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Energy set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Duplex set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Speed set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Energy set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Duplex set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Speed set to Auto configuration

Hieruit vallen mij het volgende op:
- “Dongle successfully initialized” - Wij hebben geen USB / Dongle / Ander apparaat verbonden met de KPN Box 12 anders dan de standaard stroom, WAN (ONT), en LAN verbindingen.
- “DHCP client UP: Connection Established - IP: [10.46.49.***]”  - bij dit IP heb ik minder gecensureerd omdat deze IP range mij niet bekend voorkomt. Intern heb ik alles via 192.168.x.x ingesteld, ik heb het nog steeds niet volledig laten zien indien dit via KPNs servers toch een identifier van mijn modem is voor interne communicatie, maar het viel mij wel op. Zeker omdat dit twee aparte leases zijn met verschillende duraties voor hetzelfde IP adres, en het matcht mijn externe IP adres niet, die is namelijk statisch. Daarintegen weet ik niet of dit wellicht een resultaat kan zijn van double NAT.
- “PortForwarding rule was deleted succesfully” - Ik heb gisteren zeker geen aanpassingen gemaakt aan PortForwarding instellingen. Dit kan wellicht een UPnP poort is geweest die tijdelijk open was, maar het is zeker geen handmatige configuratie geweest.

Maar ik ben bang dat niks hiervan echt impact heeft op het probleem, zeker omdat de PPP sessie niet in de logs voorkomt. Wel komt deze ruw overeen met de LAN port logs waar de Energy, Duplex en Speed naar Auto configuration worden gezet. Hiervoor zijn de enige zichtbare logs van 24 Juli:

Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Energy set to Auto configuration
Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Duplex set to Auto configuration
Sep 11 17:19:58 | HOME_LAN | gmap_self | 4634 | LAN port (ETH3) - LAN Speed set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Energy set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Duplex set to Auto configuration
Sep 11 17:19:57 | HOME_LAN | gmap_self | 4634 | LAN port (ETH2) - LAN Speed set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Energy set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Duplex set to Auto configuration
Sep 11 17:19:56 | HOME_LAN | gmap_self | 4634 | LAN port (ETH1) - LAN Speed set to Auto configuration
Jul 24 15:49:53 | HOME_LAN | gmap_self | 4634 | LAN port (ETH0) - LAN Energy set to Auto configuration
Jul 24 15:49:53 | HOME_LAN | gmap_self | 4634 | LAN port (ETH0) - LAN Duplex set to Auto configuration
Jul 24 15:49:53 | HOME_LAN | gmap_self | 4634 | LAN port (ETH0) - LAN Speed set to Auto configuration

Ondanks dat het wel lijkt op dezelfde procedure.
Ik weet niet of de firmware wellicht 24 Juli als standaarddatum heeft, en pas na de ETH0 configuratie verbinding heeft kunnen krijgen met een NTP server om de tijd en datum te corrigeren. Zeker omdat de timestamps een heel aparte volgorde hebben:

De verdere logs van “24 Juli” hebben namelijk wel nog info over een PPP sessie, daarom begin ik nu te twijfelen aan de juistheid van deze timestamps, en wellicht ook aan de firmware/hardware. Want de eerste paar logs die op die datum te zien zijn, lijken enorm op een opstartprocedure, waarbij Ethernet Links omhooggetrokken worden, en IPv6 aan en weer uitgezet wordt (de NVRAM configuratie die ingelezen wordt):

Jul 24 15:49:51 | INTERNET | gmap_wan | 4687 |  - DNSServers : 195.121.1.34,195.121.1.66
Jul 24 15:49:51 | INTERNET | gmap_wan | 4687 |  - IPv6DelegatedPrefix :
Jul 24 15:49:51 | INTERNET | gmap_wan | 4687 |  - ConnectionIPv6Address :
Jul 24 15:49:51 | INTERNET | gmap_wan | 4687 |  - ConnectionIPv4Address : 77.***
Jul 24 15:49:51 | INTERNET | gmap_wan | 4687 |  IP stack negotiated info parameters:
Jul 24 15:49:49 | SYSTEM | tr181-mqtt | 4121 | Connection to broker established
Jul 24 15:49:45 | INTERNET | pppd_plugin | 3675 | PPP interface UP: Connection established
Jul 24 15:49:43 | INTERNET | nemo-core | 2727 | DHCP client UP: Connection Established - IP: [10.46.49.***], Lease Time: [3600], DHCP Server: [10.46.48.1]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | DomainName set to [home]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | DNS Server set to [192.168.3.254]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | LeaseTime set to [14400]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | SubnetMask set to [255.255.255.0]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | MaxAddress set to [192.168.3.32]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | MinAddress set to [192.168.3.1]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | HGW IP set to [192.168.3.254]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | DomainName set to [home]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | DNS Server set to [192.168.2.254]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | LeaseTime set to [14400]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | SubnetMask set to [255.255.255.0]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | MaxAddress set to [192.168.2.200]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | MinAddress set to [192.168.2.1]
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | HGW IP set to [192.168.2.254]
Jul 24 15:49:42 | HOME_LAN | dhcp | 4041 | Synchronization/handshake occurred: Device with MAC [b0:***] and friendly name [DIW7022-CED298]
Jul 24 15:49:42 | SYSTEM | dhcp | 1647 | '[USER][SYSTEM] - [i]' repeated 1 times, suppressed by syslog-ng on mijnmodem.kpn
Jul 24 15:49:42 | SYSTEM | dhcp | 4041 | device name [DIW7022-CED298]
Jul 24 15:49:37 | INTERNET | nemo-core | 2727 | Ethernet Link is UP on port(eth4)
Jul 24 15:49:37 | INTERNET | nemo-core | 2727 | Ethernet Link is UP on port(eth0)
Jul 24 15:49:36 | SYSTEM | firewall | 3452 | UPnP IGD disabled
Jul 24 15:49:35 | INTERNET | nemo-core | 2727 | Ethernet Link is UP on port(eth1)
Jul 24 15:49:34 | SYSTEM | netmaster | 3235 |  IPv6 status disable
Jul 24 15:49:33 | SYSTEM | netmaster | 3235 | IPv6 prefix mode was changed to DHCPv6
Jul 24 15:49:33 | SYSTEM | netmaster | 3235 |  IPv6 status enable

Ongeacht dat deze KPN Box 12 het lang zonder problemen heeft gedaan, en plotseling problemen is gaan vertonen, ben ik nu wel benieuwd, worden firmware updates automatisch geinstalleerd door KPN, en is het mogelijk dat er iets tijdens een firmware update fout is gegaan waardoor het dit soort gedrag vertoont? Eerst dacht ik namelijk dat het onwaarschijnlijk was dat het modem de oorzaak was, maar nu dat ik deze timestamps van de logboeken zie, begin ik daar enigzins aan te twijfelen.
 

Een wegvallende verbinding kan heel goed een oorzaak in het thuisnetwerk hebben maar dat is altijd wat lastig vast te stellen. Het makkelijkste daarvoor is alles eens te ontkoppelen behalve 1 pc en de experiabox zelf. DIt is natuurlijk niet werkbaar als de problemen zich pas na langere tijd voordoen.

De box12 installeert zelf updates inderdaad, op onze product updates pagina daarover kun je alles vinden over de laatste updates van je box12 Product Updates Box 12 | KPN Community

Ja, het vervelende is dat dit dus heel erg lijkt op een beschadigde glasvezel. Maar gezien de logs van de KPN Box, lijkt het alsof die op willekeurige momenten een reboot uitvoert en z’n datum vergeet (vandaar de logs die 24 juli aangeven), en dus bijna hetzelfde storingspatroon heeft. De tijd van de storingen ligt daar ook ongeveer in (enkele minuten in lengte). Wat ik eerder dus zo apart vondt is dat dit probleem plotseling is begonnen. Maar als firmware updates inderdaad automatisch uitgevoerd worden en mis kunnen gaan, kan dat een zekere verklaring geven voor het probleem.

De enige vraag die ik dan nog zou hebben is hoe de KPN Box nog steeds te pingen was tijdens zo’n storing. Maar de ping functionaliteit zal waarschijnlijk sneller weer werkzaam zijn dan de volledige internetverbinding naar KPN, en wellicht dan ook een minuut ofzo voordat de rest van het netwerk weer realizeert dat het internet terug is. (zodra de KPN box wegvalt zal mijn eigen router natuurlijk een non-routable error terugsturen, wat wellicht voor een korte tijd onthouden wordt door de downstream clienten, waardoor ze de verbinding net iets langer kwijt zijn dan hij echt fysiek weg is geweest).

Dus dan de vraag, is het mogelijk om een nieuwe KPN Box aan te vragen om de (vermoedelijk deels-defecte) te vervangen.

Ik denk dat dat opzich geen slecht idee is, kun je nog eens met ons bellen of een belafspraak maken?