Skip to main content

Hallo! Toen ik vandaag wakker werd, was het niet meer mogelijk om nieuwe TCP verbindingen te leggen, maar oude TCP verbindingen bleven in stand. Wat bleek nou, de modem was aan het updaten. Even later lag het netwerk er helemaal uit.

Ik ging in de modem kijken en de user interface zag er helemaal anders uit.

Ik heb geprobeerd het netwerk te krijgen zoals ik het eerst had. Ik heb een eigen router met OpenWrt achter de kpn Box 12 zitten die dient als DHCP server en firewall en meer, en ik zou graag willen dat de kpn Box 12 daar niet mee in de weg zit. Voorheen was het enige probleem dat IPv6 Prefix Delegation er niet was, en dat IPv6 na een aantal weken gewoon zomaar stopt met werken waardoor ik de kpn Box 12 moet herstarten, en dan doet ie het weer.

 

Ik heb de hele tijd geëxperimenteerd met de nieuwe firmware versie op de kpn Box 12, en daarmee heb ik de volgende instellingen bereikt:

Thuisnetwerk → IPv6 → IPv6 Prefix Delegation: Aan met DHCPv6

Thuisnetwerk → IP-adres reserveren ↓

  • Apparaat: OpenWrt
  • IP-adres: 192.168.2.1

Beveiliging → Firewall → Modem reageert op pings: Aan

Beveiliging → Firewall → Beveiligingsniveau: Aangepast

Beveiliging → Firewall → Aangepaste regels → Mode: Alles toelaten

Beveiliging → Firewall → Aangepaste regels → IPv4 → (zet alle blokkerende regels uit met de slider links)

Beveiliging → Firewall → Aangepaste regels → IPv6 → (zet alle blokkerende regels uit met de slider links)

Beveiliging → Port forwarding → IPv6 ↓

  • Service: Nieuw…
  • Protocol: Both
  • IPv6-adres: 0::0/0
  • Port: 1-65535

Beveiliging → DMZ ↓

  • IP-adres: 192.168.2.1

 

Met deze configuratie zou elk apparaat op IPv6 niet worden gehinderd door port blokkering op IPv6, en zou de firewall niets moeten doen. Ik heb al een firewall op mijn OpenWrt en heb die van de modem niet nodig.

 

Nu op mijn OpenWrt router heb ik hetvolgende ingesteld in /etc/config/network:

config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
list ports 'eth4'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config interface 'wan'
option proto 'dhcp'
option device 'eth0'
option hostname '*'
option peerdns '0'
list dns '8.8.8.8'
list dns '8.8.4.4'

config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'

en vervolgens in /etc/config/dhcp:

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
option dhcpv6 'relay'
option ndp 'relay'
list dns '2620:fe::fe'
list dns '2620:fe::9'

 

Deze configuratie zorgt ervoor dat apparaten aangesloten op mijn OpenWrt router een prefix krijgen van xxxx:xxxx:xxxx:ff71::/64 (eigen /48 prefix gecensureerd). Die ff71 irriteerd mij enorm, en de hele bedoeling van prefix delegation is zodat je een /48 prefix krijgt, en niet een /64, dus het is wel heel raar dat dit gebeurd. Als ik in OpenWrt instel dat inplaats van ‘try’ hij ‘force’ doet maar dan met een ‘48’ prefix inplaats van ‘automatic’, dan krijgt de OpenWrt router helemaal geen prefix delegation meer van de kpn Box 12.

 

Bovendien is belangrijke IPv6 functionaliteit onbeschikbaar, zoals ICMPv6. Alle ICMPv6 pakketten van buiten het netwerk kunnen niet naar binnen, waardoor het onmogelijk is om ping en traceroute te gebruiken op IPv6. Zelfs niet als je vanaf binnen het netwerk een ICMPv6 pakket naar buiten het netwerk stuurt. Apparaten die dan ICMPv6 replies terugsturen komen ook niet binnen! Heel erg frustrerend dit.

 

En elke keer als de kpn Box 12 herstart, dan worden een aantal instellingen terug gezet naar de standaardwaarden, waaronder deze:

  • Thuisnetwerk → IPv6 → IPv6 prefix delegation: Uit
  • Beveiliging → Firewall → Aangepaste regels → Mode: Alles blokkeren
  • Beveiliging → Firewall → Aangepaste regels → (alle regels die verwijderd zijn komen weer terug!)

 

Dit is best ernstig en zo kan ik mijn internet niet normaal gebruiken. Deze bugs moeten gefixt worden. Ik zou graag het volgende willen zien in een firmware update:

  • Onthoud instellingen voor prefix delegation en firewall
  • Prefix delegation geeft een prefix van /48 door en niet alleen /64
  • Geef mogelijkheid voor DMZv6 of om firewall compleet uit te schakelen.
  • ICMPv6 moet werken, zodat je kan pingen en traceroute kan doen van binnen naar buiten, en buiten naar binnen.

Op de oude firmware werkte dit allemaal, behalve prefix delegation. Prefix delegation is een nieuwe feature die in deze firmware is toegevoegd, maar is niet functioneel zoals ik al had beschreven.

Ik werd helaas weer slecht wakker vandaag. De kpn box heeft weer de TCP bug gekregen waardoor alle nieuwe TCP verbindingen worden “geblackholed” zoals ik het nu wil noemen. Heel triest. Ik heb weer mijn eigen router aangesloten op de media converter en ik denk dat ik KPN ga bellen hierover. Ik hoop dat ze niet weer gaan zeggen dat ik service plus moet gaan nemen zodat ze mij kunnen helpen. TCP is essentieel en zou ik geen service plus voor moeten hebben willen ze er iets aan doen, zou ik denken, maar dit zou waarschijnlijk niet in hun script staan. Vandaag heb ik niet de tijd om te bellen dus dan moet ik dat maar morgen proberen.


Wat versta je nu toch onder die "TCP bug".

Beschrijf eens in detail wat je ervaart of ziet gebeuren.


Wat versta je nu toch onder die "TCP bug".

Beschrijf eens in detail wat je ervaart of ziet gebeuren.

Je weet denk ik wel dat een TCP verbinding stateful is doordat je een TCP verbinding kan openen en behouden met andere computers op het internet. HTTP verbreekt de TCP verbinding een korte tijd nadat de request is voldaan. Maar bijvoorbeeld Minecraft, Mumble, XMPP, en IRC houden de TCP verbinding lang open. Het probleem dat ik ervaar is dat ongeveer 4 uur nadat ik de kpn box aanzet of herstart heb, dat nieuwe TCP verbindingen niet meer geopend kunnen worden met de fout “Connection timed out”. Maar bestaande TCP verbindingen die nog open staan (Mumble, XMPP, IRC, etc.) blijven nog werken, totdat deze gesloten worden, waarna een nieuwe verbinding niet meer mogelijk is.

Dit geeft me het gevoel dat de kpn box TCP verbindingen (onnodig) bijhoudt en dat er misschien uiteindelijk een limiet wordt bereikt waardoor de kpn box nieuwe TCP verbindingen gewoon dropt. Dit is maar een hypothese en ik weet niet wat de daadwerkelijke oorzaak is. Een reset lost het probleem niet op, en dit probleem begon op deze firmware versie.


Is het op het netwerk achter jouw eigen router dat je tegen deze problematiek aanloopt?


Is het op het netwerk achter jouw eigen router dat je tegen deze problematiek aanloopt?

Juist niet. Alles op mijn eigen apparatuur werkt gewoon. Als ik de web UI van de kpn box probeer te bereiken lukt dat dus ook niet wanneer dit probleem zich voordoet. En alle verbindingen die door de kpn box moeten hebben dit probleem, maar alles dat alleen door mijn eigen router gaat werkt prima.


Waar is het apparaat waarop je die problemen constateert dan op aangesloten?


Waar is het apparaat waarop je die problemen constateert dan op aangesloten?

De kpn box is aangesloten op de media converter. Mijn eigen router is aangesloten op de eerste LAN port van de kpn box. Mijn computer is aangesloten op de tweede port (eerste LAN port) van mijn eigen router terwijl de kpn box op de eerste port (WAN port) zit.


En het issue constateer je op jouw computer die op jouw eigen router aangesloten is?


En het issue constateer je op jouw computer die op jouw eigen router aangesloten is?

Ja, maar het is ook zo op apparaten die op de WiFi van de kpn box zitten, dus het is niet alleen mijn computer.


Ik weet nu wat de kpn box 12 TCP bug veroorzaakt. Als ik BitTorrent DHT aan heb staan, dan stopt TCP binnen 1 of 2 uur met werken. Als ik BitTorrent DHT uit heb staan, dan stopt TCP binnen een aantal dagen tot een week met werken.

Dit is dus nogsteeds een algemeen probleem. Misschien heeft het te maken met hoeveel inkomende connecties je krijgt op je netwerk, en dat als je veel connecties krijgt (zoals met DHT) dat dan de modem sneller een of ander limiet bereikt waardoor TCP stopt met werken. Dit limiet was er niet op de oude firmware. Ik denk dat het een of andere software bug is waardoor verbindingen stateful worden geprocessed door de modem terwijl daar geen reden voor is (omdat ik de firewall op Low heb staan). Het rare is ook nog dat BitTorrent DHT gebaseerd is op UDP, dus dan is het wel raar dat dat invloed heeft op het veroorzaken van de TCP bug.


En het blijkt dat TCP niet het enige probleem is. IPv6 ping is schommelend, en het blijkt dat er ook een bug is waardoor bellen niet meer mogelijk wordt met de huistelefoon.

Screenshot van ping diagnostieken, waaruit blijkt dat IPv6 eventueel packet loss ervaart.

Deze schommelingen zie ik alleen wanneer ik met de kpn box op internet zit aangesloten met OpenWrt erachter. Zonder de kpn box werkt het goed. Ook merk ik tijdens gamen dat als ik op een IPv6 server speel wordt ik soms gedisconnect, mogelijk gedurende zo een packet loss momentje.


Mijn vader heeft de kpn box herstart omdat de TV het niet deed. Toen kreeg de kpn box een IPv6 unique local adres toegewezen, dus ik denk dat op een of andere manier de PPPoE handshake of wat dan ook heeft gefaalt.

Ik had toen de kpn box weer herstart, maar toen werkte alleen IPv6 maar niet IPv4. Hoe bijzonder is dat?

Ik heb nu weer mijn eigen router direct op de media converter want de kpn box wil geen IPv4 meer ook als ik hem herstart.

Mijn eigen router werkt zoals altijd weer helemaal prima.