Skip to main content

Mijn ExperiaBox V10 is vervangen door een KPN box 12b.

Ik kreeg problemen met samba onder Linux, oorzaak zit in de DNS suffix die is gewijzigd naar .KPN ipv .HOME

Ik heb al gevonden dat het een bekend issue is, en dat het is verholpen met nieuwe Firmware (V12.etc), je krijgt dan weer een .HOME suffix.

Mijn KPN box 12b heeft nog een oude SGEJ1000060E.

Hoe krijg ik nieuwere Firmware?

 

Daarvoor zult u gewoon af moeten wachten. Dat gebeurt automatisch een keer. Niemand kan dat op dit moment versnellen. 

Heeft u witte SuperWiFi's? Of Experia WiFi's? Dan gaat het nog een heel poosje duren.

Waarom is uw Experiabox vervangen? Was die kapot? 


Niet het leukste antwoord, maar wel duidelijk. Bedankt Nick83.

Ik heb geen geen SuperWifi of ExperiaWifi, dus hopelijk is het modem  snel aan de beurt.

 


Hi @RB401,

Ik zie dat Nick je al heeft bijgepraat over de uitrol van de software, we zijn daar momenteel druk mee bezig dus ik hoop dat het bij jou niet lang meer zal gaan duren 🙂


Uit belangstelling: heb je een link naar wat je gevonden hebt over de problemen met .kpn domein?

Voor zover ik weet is zou alleen het .local domein vervelend kunnen doen omdat dat voor mdns/zeroconf gereserveerd is. Er zijn mij wat betreft samba geen beperkingen bekend. 

Echter: ik heb sinds kort een (omzeilbaar ) probleem met Linux op een V10 met het .home domein.

Ik ben dus benieuwd wat de v12 teruggeeft met “dig AAAA @192.168.2.254 xxxxx.kpn”

waarbij xxxxx een hostnaam is die met “dig A @192.168.2.254 xxxxx.kpn” een IPv4 adres teruggeeft.

In het bijzonder het “STATUS” veld in de header.


Even verder gezocht: De .kpn suffix is zowel top-level domein als het domein dat de experia box gebruikt. Even getest met de onvolprezen “dnsmasq” DNS cache, deze is in staat tegelijkertijd .kpn namen uit /etc/hosts te verwerken als “overons.kpn”. Maar dat zegt niets over de DNS server in de KPN box, die kan anders werken. Met de  “dig” of “host” commando’s kan de DNS server op 192.168.2.254 direct aangesproken worden om te testen of de lokale systemen zichtbaar zijn.

Met Linux-Linux samba is de .kpn suffix voor zover ik gezien heb geen probleem.

Het probleem dat ik heb met de V10 en de .home suffix blijkt op dit forum al eerder besproken te zijn voor Windows. Als een IPv6 adres van een .home niet gevonden wordt, wordt NXDOMAIN teruggegeven. Dat betekent dat het systeem niet bestaat. Windows en Linux zetten dit in een cache, en vervolgens is het IPv4 adres ook verdwenen want het hele systeem bestaat dus niet. De nameserver moet een “NOERROR” plus blanco IPv6 adres terug geven. Ik weet niet of de V12a dit correct doet, vandaar mijn vraag over de uitvoer van “dig” . Maar dan zou dit probleem zowel bij .kpn als .home kunnen optreden. 

Overigens lijkt .home ook al weer uit de gratie en schijnt “.home.arpa” te moeten worden.  Ik moet nog eens rustig doorlezen wat daarvoor nu de reden is.


Op een v14 met nieuwe software en de DNS proxy functie aan op de router. Ieder apparaat wat een DHCP adres actief heeft vanuit de router is lokaal te resolven op de .home

Onderstaand dus een android tablet op de wifi:

 

; <<>> DiG 9.10.6 <<>> AAAA @192.168.2.254 Galaxy-Tab-S7.home

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50010

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;Galaxy-Tab-S7.home. IN AAAA

 

;; Query time: 11 msec

;; SERVER: 192.168.2.254#53(192.168.2.254)

;; WHEN: Fri Jun 07 13:06:13 CEST 2024

;; MSG SIZE  rcvd: 47

 

En nogmaals maar nu op het .kpn 

; <<>> DiG 9.10.6 <<>> AAAA @192.168.2.254 Galaxy-Tab-S7.kpn

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41212

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;Galaxy-Tab-S7.kpn. IN AAAA

 

;; AUTHORITY SECTION:

kpn. 900 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 132697 900 1800 6048000 3600

 

;; Query time: 15 msec

;; SERVER: 192.168.2.254#53(192.168.2.254)

;; WHEN: Fri Jun 07 13:06:08 CEST 2024

;; MSG SIZE  rcvd: 111

 

Met als uitzondering het mijnmodem.kpn welke aan het modem vasthangt en lokaal te resolven valt.


OK. Dit toont aan dat de V14 met .home suffix laat zien dat het tablet bestaat maar geen IPv6 adres heeft, terwijl .kpn naar de KPN nameserver gaat en daar terecht tot de conclusie komt dat het systeem niet bestaat en NXDOMAIN als status geeft.

Als de firmware .kpn suffix voor lokaal gebruikt, maar IPv6 gaat opzoeken op de KPN server, dan gaat het fout als een cache aanwezig is, dan mag de afwezigheid max. 900 seconden in de cache gezet worden volgens het SOA record. Waarmee ook het IPv4 adres verdwijnt.

Inderdaad wachten op een nieuwe firmware, de v14 heeft dus niet de bug die de v10 heeft.

Op een Fedora 40 systeem met systemd-resolved actief is workaround:

File: /etc/systemd/resolved.conf:

cache=”no-negative”.

Ik heb niet de indruk dat samba enig probleem heeft met .kpn suffix, ik neem aan dat het DNS betreft.


Het galaxy tablet stond om 1 of andere reden zonder valide ipv6 adres. Hieronder nogmaals met een lokaal station die wel een publiek ipv6 adres heeft (Wel even ge x-tje om de echte adressen te verbergen.).

 

; <<>> DiG 9.10.6 <<>> AAAA @192.168.2.254 LivingRoom-iMac.home

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17454

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;LivingRoom-iMac.home. IN AAAA

 

;; ANSWER SECTION:

LivingRoom-iMac.home. 0 IN AAAA 2a02:a441:b800:0:x❌x:x

LivingRoom-iMac.home. 0 IN AAAA 2a02:a441:b800:0:x❌x:x

LivingRoom-iMac.home. 0 IN AAAA 2a02:a441:b800:0:x❌x:x

 

;; Query time: 9 msec

;; SERVER: 192.168.2.254#53(192.168.2.254)

;; WHEN: Fri Jun 07 15:13:29 CEST 2024

;; MSG SIZE  rcvd: 133

 

 

 

 

 

 

 

; <<>> DiG 9.10.6 <<>> AAAA @192.168.2.254 LivingRoom-iMac.kpn

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55609

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;LivingRoom-iMac.kpn. IN AAAA

 

;; AUTHORITY SECTION:

kpn. 900 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 132702 900 1800 6048000 3600

 

;; Query time: 13 msec

;; SERVER: 192.168.2.254#53(192.168.2.254)

;; WHEN: Fri Jun 07 15:14:13 CEST 2024

;; MSG SIZE  rcvd: 113

 

Dit apparaat is zowel op ipv4 als ipv6 lokaal te resolven op de in de router bekend zijnde naam.


Dat is heel mooi. Als de iMac zijn IPv6 via DHCPv6 krijgt, dan werkt het vergeljkbaar met IPv4, maar als als SLAAC autoconfiguratie gebruikt wordt, kan de router alleen de DAD, dubbel adres detectie, packets gebruiken. Dus DAD IPv6 adres +MAC adres--→ geregistreerd IPv4 MAC adres --→ hostnaam. Ik zou niet weten hoe ik dat in Linux draaiend zou moeten krijgen.  

De V10 krijgt het voor elkaar om  zo IPv6 port forwarding op basis van MAC adres te doen, maar registreert niet in DNS.

Als ook Prefix delegatie goed werkt zou dit dus, als ik de discussies hier een beetje volg, de tweede KPN router met goede IPv6 implementatie zijn.

 


Het geheel rondom ipv6 prefix delegation is nog niet helemaal af volgens opmerking in de release notes. 

  • IPv6 prefix delgation staat op een vaste configuratie. In een komende update wordt dit aangepast zodat je dit kunt inzien en wijzigen.

Inzien en wijzigingen impliceert richting DHCPipv6 statefull mogelijkheden voor individuele ipv6 leases en prefixes.


Dat ziet er goed uit allemaal. In ieder geval, als de problemen van de auteur daadwerkelijk hierdoor veroorzaakt worden is het opgelost als weer .home gebruikt wordt. Tot dan maar even geen cache,

Er is overigens een pakket in OpenWRT dat IPv6 DNS registratie verzorgt, ip6neigh. Eens kijken of dat ook in Linux draaiende te krijgen is.


Reageer