Das braucht so lange, weil es bei jedem Hop wartet um die Namensauflösung zu machen, die offensichtlich nicht funktioniert.
PingTools wartet da imho beim Traceroute nicht so lange…
Sowohl die IP Adresse wie auch DNS Server scheinen falsch zu sein, das müsste so aussehen wie auf dem Galaxy Tab.
Ja.
DNS und DHCP laufen jeweils auf den Gateway Servern.
Je nachdem mit welchem Gateway der Router gerade Verbunden ist wird auch entsprechend eine IP und ein DNS verteilt.
An den IPv4 Adressen lässt sich erkennen mit welchem Server die Verbindung besteht.
Gateway FanLin; Client-IP: 10.43.8.1 - 10.43.15.254, DNS Server: 10.43.0.2
Gateway Fusselkater: Client-IP: 10.43.24.1 - 10.43.31.254, DNS Server: 10.43.0.4
Gateway Commander: Client-IP:10.43.32.1 - 10.43.39.254 , DNS Server: 10.43.0.5
Die Frage ist eben wo er diese Einstellungen herbekommt…
Ja, definitiv … hast du das Gerät auf Statische IP Konfiguration umgestellt ??
Die IP muss im Bereich 10.43.x.x liegen sonnst geht auf jeden Fall nichts.
Zum Testen (um DHCP Probleme auszuschließen) kannst du dir auch eine IP zwischen
10.43.3.0 und 10.43.0.255 geben und einmal. (Netzmaske 255.255.0.0).
Die Folgenden IPs müssten dann per Ping erreichbar sein:
10.43.0.1
10.43.0.2
10.43.0.4
10.43.0.5
Ne, es stand schon auf DHCP. Beim Eingeben der Werte ist mir aber was neues aufgefallen. Ab Android 5.0 scheinen diese Werte nur Platzhalter zu sein, bis man selber was eingibt, und geben nicht die tatsächlichen Einstellungen wieder. Das wird auch deutlich, wenn ich in die erweiterten Einstellungen des WLANs meines Unitymedia Routers reinschaue, da stehen nämlich genau dieselben Werte. Diese können aber nicht zutreffen, da der Untitymedia Router dem Nexus 4 eine IP nach dem Schema 192.168.0.x zuweist.
So, dann mal anders. Das sind die IP Adressen, die laut den Angaben in den Einstellungen dem Nexus 4 zugewiesen sind, wenn es mit dem Freifunk Netz verbunden ist:
fe80::9ad6:f7ff:fe64:5c0a
10.43.27.117
2a03:2260:115:0:9ad6:f7ff:fe64:5c0a
fd68:e2ea:a53:0:ac64:7fe8:aa93:f039
2a03:2260:115:0:ac64:7fe8:aa93:f039
fd68:e2ea:a53:0:9ad6:f7ff:fe64:5c0aHat evtl jemand sein Lan an den Freifunk Node verbunden?
Sieht für mich so aus 
Habe ebenfalls ein Problem mit Freifunk auf einem Moto X (Android 5.0)
Mit einem Moto G (Android 4.4.4) geht alles.
Ping zu 8.8.8.8 geht, DNS-auflösung von google.de allerdings nicht.
Gruß
Oh man, wenn ich das hier richtig verstehe, hat Google es einfach in Android 5.0 verkackt.
https://code.google.com/p/android/issues/detail?id=79504
Vielleicht ist es ja das Problem, dass in Münster das DNS einfach nur kaputt ist, zwei von drei Resolvern antworten nicht (sind auch nicht pingbar):
18:55:19.825259 IP6 2a03:2260:115:0:517b:212c:857:94b.57451 > 2a03:2260:115::4.53: 40091+ A? www.msftncsi.com. (34)
18:55:22.507100 IP6 2a03:2260:115:0:517b:212c:857:94b.59978 > 2a03:2260:115::4.53: 29468+ A? e10.whatsapp.net. (34)
18:55:30.613868 IP6 2a03:2260:115:0:517b:212c:857:94b.59978 > 2a03:2260:115::4.53: 29468+ A? e10.whatsapp.net. (34)
18:55:33.786990 IP6 2a03:2260:115:0:517b:212c:857:94b.54957 > 2a03:2260:115::4.53: 63144+ A? www.msftncsi.com. (34)
18:55:38.589387 IP6 2a03:2260:115:0:517b:212c:857:94b.54959 > 2a03:2260:115::4.53: 8400+ A? e10.whatsapp.net. (34)
19:38:01.260401 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.57117 > 2a03:2260:115::4.53: 50154+ AAAA? firmware.ffms. (31)
19:38:01.260780 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.57117 > 2a03:2260:115::5.53: 50154+ AAAA? firmware.ffms. (31)
Beide Hosts: 2a03:2260:115::4 und 2a03:2260:115::5 werden als DNS Server announced, funktionieren aber nicht.
Ich sehe gerade, jetzt gibt es einen 2a03:2260:115::2 der auch nicht funktioniert:
15:12:19.247551 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.54787 > 2a03:2260:115::2.53: 39628+ A? firmware.ffms. (31)
Die durch die DNS Dysfunktionalität eintretende Entschleunigung dürfte die „User Experience“ nicht sehr gut ausfallen lassen.
Andere Dineste (System Upgrade) stehen nun ohnen DNS da und funktionieren gar nicht mehr:
# autoupdater
wget: bad address 'firmware.ffms'
There seems to have gone something wrong downloading the manifest from http://firmware.ffms/firmware/experimental/sysupgrade
No usable mirror found.Kann ich bestätigen. Gestern habe ich mich noch geärgert, dass die das Update auf 5.0 noch nicht veröffentlicht haben. Jetzt bin ich ganz froh.
Version 5 macht jetzt wohl IPv6. Alle nichtantwortenden Resolver werden per IPv6 ICMP Router Advertisement (Type 134) announced:
15:52:23.868806 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 88) fe80::9085:a3ff:fe6c:730 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 88
hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): 2a03:2260:115::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
rdnss option (25), length 24 (3): lifetime 600s, addr: 2a03:2260:115::2
mtu option (5), length 8 (1): 1280
source link-address option (1), length 8 (1): de:cd:41:45:f9:9d
15:52:23.918032 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::94c2:e1ff:fe61:9974 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): fd68:e2ea:a53::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
prefix info option (3), length 32 (4): 2a03:2260:115::5/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
rdnss option (25), length 24 (3): lifetime 600s, addr: 2a03:2260:115::5
mtu option (5), length 8 (1): 1280
source link-address option (1), length 8 (1): 0a:4f:0b:db:d6:fc
15:52:24.041943 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::942a:a5ff:fed5:aa4a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): fd68:e2ea:a53::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
prefix info option (3), length 32 (4): 2a03:2260:115::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
rdnss option (25), length 24 (3): lifetime 600s, addr: 2a03:2260:115::4
mtu option (5), length 8 (1): 1280
source link-address option (1), length 8 (1): 6e:43:81:b5:c2:a1Schlussendlich war das ganze ein IPv6 Routing Problem.
Das Routing ist jetzt gefixt und von unseren Testgeräten aus war funktioniere jetzt alles.
@labmaster @heerde könnt Ihr das von Eurer Seite bestätigen ?
Was genau ist der fix und auf welcher Ebene? Sitze in Stuttgart und habe vermutlich das gleiche Problem mit meinen 5.0 Geräten…eine Beschreibung der Lösung wäre toll.
Gruß
T
Ja, klappt alles soweit lokal und global. Eine einzigste Sache geht noch nicht:
# ping -c 3 ntp.ffms
PING ntp.ffms (fd68:e2ea:a53::11): 56 data bytes
--- ntp.ffms ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Wie sieht der Fix denn konkret aus? Tabelle 42 korrekt befüllt?
Kann auch bestätigen, dass es auf meinem Nexus 4 mit Android 5 nun wieder funktioniert.
Die IPv6 Routen auf den Gateways wurden von bird nicht richtig befüllt.
Wir haben die bird6.conf entsprechend überarbeitet und die Routen werden jetzt passend gesetzt.
Die Dokumentation kannst du hier in unserem Wiki finden.
Die Routing Tabelle auf den Gateways ist jetzt vollständig:
2a01:4f8:150:8ff8::/64 dev eth0 proto bird metric 1024
2a03:2260:0:3e::/64 dev tun-ffrl-fra proto bird metric 1024
2a03:2260:0:3f::/64 dev tun-ffrl-dus proto bird metric 1024
2a03:2260:115::/48 dev br0 metric 1024
default via fe80::200:5efe:b942:c201 dev tun-ffrl-fra proto bird metric 1024
Super. Habe ich mir mal angeschaut. Dabei ist mir folgendes aufgefallen. Ihr bindet das gesamte /48 Subnet an br0. (Ein /48 ist sehr groß, nämlich 2^16 = 65 536 /64-Subnetze.) Das ist so nicht empfohlen. (IPv6 ist an diversen Stellen subtil anders als IPv4.) Laut RFC5375 „3.1. Considerations for /64 Prefixes“:
Based on RFC 3177, 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes. … Note that RFC 3177 strongly prescribes 64-bit subnets for general usage, and that stateless autoconfiguration on most link layers (including Ethernet) is only defined for 64-bit subnets. While in theory it might be possible that some future autoconfiguration mechanisms would allow longer than 64-bit prefix lengths to be used, the use of such prefixes is not recommended at this time.
Best Practice ist soweit wie ich mich erinnere folgendendes Vorgehen:
Anlegen einer Blackhole Route für sein eigenes /48-Subnet. Am besten gleich, wenn das lo-Interface konfiguriert wird:
iface lo inet loopback
up ip route add blackhole 2a03:2260:115::/48 dev ${IFACE}
Dann einfach das br0 Interface als /64 konfigurieren:
iface br0 inet6 static
address 2a03:2260:115::z
netmask 64
Die anderen übrigen Netzte 2a03:2260:115:1::/64 - 2a03:2260:115:ffff/64 können dann per Routing woanders hin geroutet werden und dort genutzt. Da diese Routen more specific sind, übersteueren sie die blackhole-Route.
Ja das klingt durchaus sinnvoll.
Ich werde das mal abstimmen ob wir das so übernehmen können.
Jap, oder halt unmittelbar im Bird / Quagga…