Namensauflösung hängt

(Thomas Hollenbeck) #1


Scheinbar geht da etwas verloren. Habe gerade zwei Handys getestet. Bei dir selben Probleme. Wenn die IP schon vorher aufgelöst war ist alles gut. Sobald aber neue Seiten aufgerufen werden löst er die IP nur widerwillig auf.

0 Likes

(Kai 'wusel' Siering) #2

Hmm. Kann ich gerade nicht bestätigen; Modell & Android-Version?

0 Likes

(system) geschlossen, #3

Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.

0 Likes

(Kai 'wusel' Siering) geöffnet, #4
0 Likes

(Kai 'wusel' Siering) #5

[via v2.blogdoch.net]

Hallo,

ich schreibe sie auf diesem Wege an, da ich leider im Freifunk Gütersloh Forum keine direkte Nachricht schreiben konnte.

@ronin, “leider” teilen wir im Forum auch die Probleme, insofern besteht eigentlich kein Grund für eine PN/DN :wink:

Eigentlich wollte auf diesen Forumsbeitrag antworten, leider ist er aber geschlossen worden: Namensauflösung hängt

“Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.” 10 Tage(!) sollten eigentlich reichen, das Fehlerbild zu bestätigen? Anyway, Thema wiedereröffnet.

An meinem Freifunk-Router tritt das gleiche Problem auf. Egal mit
welchem Gerät (Handy / Tablets / Laptop). Als Router wird ein TP-Link
TL-WR1043 ND mit der Firmware 1.0.1~6 verwendet.

Wollte den Router evtl. ohnehin ersetzen. Aber vielleicht hilft das ja,
falls der Fehler noch häufiger auftreten sollt.

Ich konnte das Problem – leider :wink: – dieser Tage selbst u. a. bei spiegel.de ›erleben‹, ich vermute aktuell, daß der/die Resolver “NXDOMAIN” antworten, weil die Anfrage-IP nicht “erkannt” wird. Warum, wieso, weshalb: ??? :frowning:

Aber ja, for the time being, there most likely exists an issue :frowning: Sorry for that.

0 Likes

(Kai 'wusel' Siering) #6

Es werden nun die NS 194.150.168.168 (dns.as250.net; Berlin/Frankfurt), 46.182.19.48 (digitalcourage; Leipzig?) und der lokale per DHCP vergeben, Rückmeldung über Verbesserung (oder das Gegenteil) wäre hilfreich :wink:

0 Likes

(Kai 'wusel' Siering) Thema aufgeteilt, #7

3 Beiträge wurden in ein neues Thema verschoben: Keine IP-Zuweisung in TNG

0 Likes

(René) #8

Kann es sein das die Namensauflösung im “classic” aktuell hängt?

root@33332-Buschkoettersweg-63-2dbc:/tmp# batctl gwl
Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: primary0/ca:01:73:ab:86:6b (bat0)]
=> de:ad:be:ef:67:01 (236) 02:00:25:f3:7f:25 [  mesh-vpn]: 215 - 96MBit/96MBit

root@33332-Buschkoettersweg-63-2dbc:/tmp# nslookup www.heise.de
;; connection timed out; no servers could be reached

Und noch ein Auszug aus ifconfig

bat0      Link encap:Ethernet  HWaddr F4:F2:6D:54:2D:BC
          inet6 addr: fe80::f6f2:6dff:fe54:2dbc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12579 errors:0 dropped:0 overruns:0 frame:0
          TX packets:360 errors:0 dropped:12 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:961918 (939.3 KiB)  TX bytes:35002 (34.1 KiB)

br-client Link encap:Ethernet  HWaddr F4:F2:6D:54:2D:BC
          inet6 addr: fe80::f6f2:6dff:fe54:2dbc/64 Scope:Link
          inet6 addr: 2001:bf7:1310:11:f6f2:6dff:fe54:2dbc/64 Scope:Global
          inet6 addr: fd42:ffee:ff12:aff:f6f2:6dff:fe54:2dbc/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3303 errors:0 dropped:0 overruns:0 frame:0
          TX packets:186 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:120202 (117.3 KiB)  TX bytes:20758 (20.2 KiB)

br-wan    Link encap:Ethernet  HWaddr CA:01:73:AB:86:68
          inet addr:192.168.0.222  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2003:e1:7f2a:7e00:c801:73ff:feab:8668/64 Scope:Global
          inet6 addr: fe80::c801:73ff:feab:8668/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17127 errors:0 dropped:406 overruns:0 frame:0
          TX packets:3015 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2905358 (2.7 MiB)  TX bytes:586642 (572.8 KiB)

Mit TNG bekomme ich eine Auflösung hin:

root@33332-Buschkoettersweg-63-a86c:~# ping www.heise.de
PING www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): 56 data bytes
64 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85: seq=0 ttl=57 time=32.308 ms
0 Likes

(Kai 'wusel' Siering) #9

Moin!

Kann es sein das die Namensauflösung im “classic” aktuell hängt?

Yepp:

    root@gw-gut01:~# dig A ns.uu.net. @127.0.0.1
    ^Croot@gw-gut01:~# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            476M     0  476M   0% /dev
    tmpfs           100M   11M   89M  11% /run
    /dev/vda1        19G  2.9G   15G  17% /
    tmpfs           497M     0  497M   0% /dev/shm
    tmpfs           5.0M     0  5.0M   0% /run/lock
    tmpfs           497M     0  497M   0% /sys/fs/cgroup
    tmpfs           100M     0  100M   0% /run/user/0
    root@gw-gut01:~# grep named /var/log/syslog
    root@gw-gut01:~# systemctl restart bind9
    root@gw-gut01:~# dig A ns.uu.net. @127.0.0.1
    […]
    ;; ANSWER SECTION:
    ns.uu.net.              3600    IN      A       137.39.1.3
   
    ;; AUTHORITY SECTION:
    uu.net.                 172800  IN      NS     auth200.ns.uu.net.
    uu.net.                 172800  IN      NS     auth60.ns.uu.net.
    uu.net.                 172800  IN      NS     auth210.ns.uu.net.
    uu.net.                 172800  IN      NS     auth00.ns.uu.net.
   
     ;; ADDITIONAL SECTION:
    auth00.ns.uu.net.       172800  IN      A       198.6.1.65
    auth60.ns.uu.net.       172800  IN      A       198.6.1.181
    auth200.ns.uu.net.      172800  IN      A       195.129.12.82
    auth210.ns.uu.net.      172800  IN      A       195.129.12.74
   
    ;; Query time: 125 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Jan 06 17:03:32 CET 2020
    ;; MSG SIZE  rcvd: 204

=> Should be fixed, danke für den Hinweis.

2 Likes

(Kai 'wusel' Siering) #10

Wobei:

root@gw-gut01:~# more /etc/dhcp/interface-br-ffgt.conf
subnet 10.255.0.0 netmask 255.255.240.0 {
  authoritative;
  range 10.255.0.65 10.255.7.250;
 
  option domain-name "ffgt";
  option domain-name-servers 10.255.0.61,192.251.226.23,1.1.1.1;

  option ntp-servers 10.255.0.61;
  option routers 10.255.0.61;
}

Lies: es werden 10.255.0.61, 192.251.226.23 und 1.1.1.1 als NS zugewiesen:

root@gw-gut01:~# dig -b 10.255.0.61 a heise.de @1.1.1.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -b 10.255.0.61 a heise.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30475
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;heise.de.                      IN      A

;; ANSWER SECTION:
heise.de.               2875    IN      A       193.99.144.80

;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Jan 06 17:09:39 CET 2020
;; MSG SIZE  rcvd: 53

Und:

root@gw-gut01:~# dig -b 10.255.0.61 ns freifunk.net @192.251.226.23

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -b 10.255.0.61 ns freifunk.net @192.251.226.23
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2180
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;freifunk.net.                  IN      NS

;; ANSWER SECTION:
freifunk.net.           43200   IN      NS      dyn.weimarnetz.de.
freifunk.net.           43200   IN      NS      ns.litras.de.
freifunk.net.           43200   IN      NS      ns.letras.net.

;; ADDITIONAL SECTION:
ns.letras.net.          21466   IN      A       188.68.37.114
ns.litras.de.           21466   IN      A       62.245.168.82

;; Query time: 57 msec
;; SERVER: 192.251.226.23#53(192.251.226.23)
;; WHEN: Mon Jan 06 17:11:55 CET 2020
;; MSG SIZE  rcvd: 152

==> Sollte eigentlich bei den Clients “nur” zu Verzögerungen geführt haben?

0 Likes

(René) #12

Ich flashe mal meinen 841 zurück und teste.
Bei TNG tut sich auch wieder relativ wenig. Sprich DNS tut nicht auf dem Telefon. Deshalb hatte ich den 841 auf TNG geflasht um zu testen ob es an der 4040 liegt.

0 Likes

(René) #13
root@33332-Buschkoettersweg-63-2dbc:~# nslookup www.heise.de
Server:         127.0.0.1
Address:        127.0.0.1#53

*** Can't find www.heise.de: No answer

:thinking: stable branch
Als DNS hat der Client 10.255.0.61 (ist auch das GW) und 192.251.226.23 bekommen.

0 Likes

(Christoph) #14

Die Nodes selber scheinen aber auch weiterhin Probleme mit dem DNS zu haben.

root@17258-Gutshaus:~# autoupdater -f
Retrieving manifest from http://firmware.ipv6.4830.org/rawhide/sysupgrade/rawhide.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found

root@17258-Gutshaus:~# nslookup heise.de
;; connection timed out; no servers could be reached

root@17258-Gutshaus:~# cat /var/gluon/wan-dnsmasq/resolv.conf
nameserver 1.1.1.1
root@17258-Gutshaus:~# cat /tmp/resolv.conf.auto
# Interface client
nameserver fd39:e4e3:eee1::5
nameserver 2620:0:ccc::2
# Interface wan
# Interface wan6

Im FF Müritz-Bereich scheinen die Autoupdater irgendwann ab Veröffentlichung von 1.1.2~28 stehen geblieben zu sein.

Die Status.Seiten der Nodes kann ich auch seit einiger Zeit nicht mehr von außen einsehen / bei den FFGT Nodes funktioniert es hingegen

Knoten im FF Müritz Netz:

traceroute to 2001:bf7:170:0:7a8a:20ff:fe72:74a8 (2001:bf7:170:0:7a8a:20ff:fe72:74a8), 30 hops max, 80 byte packets
 1  p200300F2CBC20D00464E6DFFFED2EFCB.dip0.t-ipconnect.de (2003:f2:cbc2:d00:464e:6dff:fed2:efcb)  2.383 ms  2.351 ms  2.323 ms
 2  2003:0:8004:b800::1 (2003:0:8004:b800::1)  10.663 ms  11.482 ms  10.608 ms
 3  dtag.l105.community-ix.de (2001:7f8:a5::3320:1)  20.533 ms  22.239 ms  22.222 ms
 4  bgp-fra01.4830.org (2a06:e881:1707:1::1)  21.332 ms  20.390 ms  20.371 ms
 5  bgp-ber01.4830.org (2a06:e881:1706:1::1)  21.230 ms  21.202 ms  22.030 ms
 6  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  27.400 ms  20.819 ms  20.806 ms
 7  bgp-ber01.4830.org (2a06:e881:1706:1::1)  20.794 ms  21.188 ms  21.176 ms
 8  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  21.162 ms  22.108 ms  22.082 ms
 9  * * *
10  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  21.994 ms * *
11  * * *
12  * * *
13  * * *
14  * * 0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  20.802 ms
15  * bgp-ber01.4830.org (2a06:e881:1706:1::1)  20.708 ms  21.507 ms
16  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  21.452 ms  21.969 ms  21.940 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * bgp-ber01.4830.org (2a06:e881:1706:1::1)  20.538 ms *
22  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  20.493 ms *  21.013 ms
23  * bgp-ber01.4830.org (2a06:e881:1706:1::1)  22.598 ms *
24  0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  24.356 ms  23.266 ms *
25  * * *
26  * * 0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  23.170 ms
27  * * *
28  * * *
29  * * bgp-ber01.4830.org (2a06:e881:1706:1::1)  22.146 ms
30  * 0400c1fffe1a7863.ber.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863)  28.180 ms *

Knoten im FFGT Netz:

traceroute to 2001:bf7:1310:11:e2d5:5eff:fe90:a19c (2001:bf7:1310:11:e2d5:5eff:fe90:a19c), 30 hops max, 80 byte packets
 1  p200300F2CBC20D00464E6DFFFED2EFCB.dip0.t-ipconnect.de (2003:f2:cbc2:d00:464e:6dff:fed2:efcb)  2.377 ms  2.362 ms  2.392 ms
 2  2003:0:8004:b800::1 (2003:0:8004:b800::1)  10.719 ms  10.772 ms  11.373 ms
 3  dtag.l105.community-ix.de (2001:7f8:a5::3320:1)  22.941 ms  22.932 ms  22.915 ms
 4  bgp-fra01.4830.org (2a06:e881:1707:1::1)  21.202 ms  22.874 ms  21.186 ms
 5  bgp-ham02.4830.org (2a06:e881:1702:1::1)  23.629 ms  23.621 ms  22.833 ms
 6  2a06:e881:1700:1::2 (2a06:e881:1700:1::2)  35.790 ms  34.290 ms  34.278 ms
 7  2a06:e881:1700:1:400:c0ff:fefb:e251 (2a06:e881:1700:1:400:c0ff:fefb:e251)  36.543 ms  36.504 ms  36.506 ms
 8  2001:bf7:1310:11:e2d5:5eff:fe90:a19c (2001:bf7:1310:11:e2d5:5eff:fe90:a19c)  55.013 ms  55.713 ms  55.667 ms
0 Likes

(Kai 'wusel' Siering) #15

Ist mir heute morgen auch aufgefallen, auch FFGT kommt nicht zum Updateserver durch. Habe Samstag und Sonntag eingeplant, die Routing-VMs in GT auf’s Blech zu ziehen, die VM kommt mit der Routenanzahl irgendwie nicht klar/der Prozeß läuft zu langsam. Leider haben wir in GUT noch Altlasten aus der vor-AS-Zeit, wird wahrscheinlich richtig rumpeln … (GUT ist unser us-east-1 :-))

0 Likes

(Christoph) #16

Ist bei dir schon Samstag/Sonntag? :crazy_face:
Namensauflösung auf den Nodes geht jetzt wieder+Aufruf der Statusseiten auch?

0 Likes

(Cord) #17

kann ich jetzt grade nicht bestätigen…

Ich habe mir einen Knoten vorgenommen, und dieser kann selber keine Namensauflösung machen.

Er möchte dafür den lokalen dnsmasq benutzen, dieser hat dann 2001:bf7:1310:11::67:1 (gw-gut01) als Resolver konfiguriert.
Auf gw-gut01 sehe ich die Request-Pakete auch ankommen, der named scheint auch zu Antworten, aber die Antworten scheinen am Client nicht anzukommen. (kein Werkzeug auf oder am Router um das zu verifizieren)

Auszug aus tcpdump auf gw-gut01:

20:05:27.573728 IP6 2001:bf7:1310:11:32b5:c2ff:feed:ffca.22619 > 2001:bf7:1310:11::67:1.domain: 33989+ A? ntp.4830.org. (30)
20:05:27.573731 IP6 2001:bf7:1310:11:32b5:c2ff:feed:ffca.22388 > 2001:bf7:1310:11::67:1.domain: 5959+ AAAA? ntp.4830.org. (30)
20:05:27.574359 IP6 2001:bf7:1310:11::67:1.domain > 2001:bf7:1310:11:32b5:c2ff:feed:ffca.22619: 33989- 0/13/0 (241)
20:05:27.574571 IP6 2001:bf7:1310:11::67:1.domain > 2001:bf7:1310:11:32b5:c2ff:feed:ffca.22388: 5959- 0/13/0 (241)

Auch das angeschlossene Endgerät bekommt keine Namensauflösung hin. Ping auf IP-Nummern geht aber,.

0 Likes

(Kai 'wusel' Siering) #18

Das ist ersteinmal OK; für mehr als den Autoupdater tut DNS auf den Knoten selbst nicht:

Why does DNS not work on the nodes?

Gluon nodes will ignore the DNS server on the WAN port for everything except the mesh VPN, which can lead to confusion.

All normal services on the nodes exclusively use the DNS server on the mesh interface. This DNS server must be announced in router advertisements (using radvd or a similar software) from one or more central servers in meshes based on batman-adv . If your mesh does not have global IPv6 connectivity, you can setup your radvd not to announce a default route by setting the default lifetime to 0; in this case, the radvd is only used to announce the DNS server.

Kurzum: außer, “autoupdater” meldet DNS-Fehler, ist das ggf. “works as designed” — Knoten nutzen für Namensauflösung der VPN-GWs andere Mechanismen als für z. B. den Autoupdater oder die NTP-Server, Debugging will man eigentlich nicht dort, sondern auf den Clients, versuchen.

0 Likes

(Cord) #19

Autoupdater fails. NTP auch.

0 Likes

(Kai 'wusel' Siering) #20

Nur zur Sicherheit: legacy oder tng?

0 Likes

(Cord) #21

Legacy

0 Likes