Das Problem der Nichterreichbarkeit der Hamburger NS habe ich auch, allerdings scheint das daran zu liegen, daß mein BIND mit der ICVPN-Adresse fragt, und Hamburg da keine Rückroute zu zu haben scheint:
root@mueritzbgp1:~# traceroute -s 10.169.1.1 10.112.1.1
traceroute to 10.112.1.1 (10.112.1.1), 30 hops max, 60 byte packets
1 hamburg03.icvpn (10.207.0.63) 16.172 ms 16.709 ms 16.732 ms
2 10.112.1.1 (10.112.1.1) 18.685 ms 18.773 ms 18.818 ms
root@mueritzbgp1:~# traceroute -s 10.207.0.138 10.112.1.1
traceroute to 10.112.1.1 (10.112.1.1), 30 hops max, 60 byte packets
1 * * *
2 * * ^C
Ich sehe die Pakete via icvpn rausgehen (IP 10.207.0.138.53235 > 10.112.1.1.33465: UDP, length 32), es kommt nur nix zurück; von 10.255.255.1 oder 10.169.1.1 (s. o.) aus tut’s … Dürfte bei Uelzen aber nicht das Problem sein, da von innerhalb des Uelzener /16 initiiert.
Bei Uelzen versacken bei mir die Traces mit FF-Adressen hinter Eurem ICVPN-GW:
root@mueritzbgp1:~# traceroute -m 5 -s 10.169.1.1 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
root@mueritzbgp1:~# traceroute -m 5 -s 10.207.0.138 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
1 uegw1.icvpn (10.207.0.18) 16.265 ms 17.646 ms 17.660 ms
2 * * *
3 * * *
4 * * *
5 * * *
Ich würde daher erwarten, daß entweder ip route show table 42 | grep 10.169 bei Euch leer ist oder aber eine Regel dafür sorgt, daß Tabelle 42 (oder welche Ihr verwendet) nicht gezogen wird (bzw. keine, daß ;)); dafür spricht imho auch, daß der Trace bei Dir hinter uegw1.ffue versackt. ip route add iif icvpn lookup 42 könnte helfen (was über ICVPN reinkommt, über die Freifunk-Routingtabelle routen).
Bzgl. ULG-Screenshot: Derzeit listet es mit Hamburg03 als Next-Hop, was funktionieren kann, aber imho kaum wird; ich finde auch kein direktes Announcment von Uelzen, nur indirekte.
Mueritz BGP1 & Guetersloh BGP1 haben einen direkten Eintrag, gw04.guetersloh (handgeklöppelte BIRD-Config) wieder den via Hamburg03:
root@mueritzbgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16 via 10.207.0.18 on icvpn [uegw1 14:37:54] * (100) [AS64525i]
root@bgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16 via 10.207.0.18 on icvpn [uegw1 12:38:02] * (100) [AS64525i]
root@gw04:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16 via 10.207.0.63 on icvpn [pipe_icvpn 14:37:05] * (70)
Aber irgendwie scheint da generell noch was im Argen zu liegen bei Euch, uegw1.icvpn sollte nicht auf dem ICVPN nach internen Adresse per ARP fragen:
root@mueritzbgp1:~# tcpdump -n -i icvpn net 10.134.0.0/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on icvpn, link-type EN10MB (Ethernet), capture size 65535 bytes
16:30:41.336840 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28
16:30:42.337211 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28
16:30:43.330115 ARP, Request who-has 10.134.20.1 tell 10.207.0.18, length 28
Aber im Grunde ist das ziemlich off-topic 
Zum eigentlichen Thema: @kantorkel: sehe ich das richtig, daß ifconfig.ffhh ein „what is my IP“-Service ist? Ganz doof gefragt, welchen Nutzen hat es, die (v4) IP zeigt zumindest Android doch in den WLAN-Einstellungen an? Oder nutzt Ihr das für Problemeingrenzungen?
