Hmm. Kann ich gerade nicht bestätigen; Modell & Android-Version?
Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.
[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 
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 – 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: ??? 
Aber ja, for the time being, there most likely exists an issue Sorry for that.
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
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 msMoin!
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 „Gefällt mir“
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?
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.
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
stable branch
Als DNS hat der Client 10.255.0.61 (ist auch das GW) und 192.251.226.23 bekommen.
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
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 :-))
Ist bei dir schon Samstag/Sonntag? 
Namensauflösung auf den Nodes geht jetzt wieder+Aufruf der Statusseiten auch?
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,.
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.
Autoupdater fails. NTP auch.
Nur zur Sicherheit: legacy oder tng?
Legacy
FTR, wir hatten eben beim Treffen im Syrtaki das Problem bei auch, zumindest bei einigen; ich könnte es am 9er Androiden nicht feststellen, andere sporadisch schon
Da Legacy z. Zt. jeweils auf 1 VM stattfindet (GT auf gw-gut01, fastd läuft auf Host; Müritz auf gw05, lokaler fastd), ist Routing eigentlich außen vor …
(Just in case, in diesem Thread bitte nur Legacy-Netz-Probleme melden.)