Autsch. Ich habe testweise in einer VM mit mal ein weiteres »Freifunk-Gateway« aufgesetzt. Jetzt bin ich ratloser als zuvor ;)
Zum Setup: gw01.ffgt.0xdecafbad.net läuft seit ein paar Tagen als »Gluon- und VPN-Gateway«; ich habe ein wenig Probleme, das richtig zu beschreiben, denn die sog. »Gluon«-Firmware aus Lübeck nutzt tap-Interfaces vom WLAN des FF-Knotens zu mehreren sog. Gateways. In diese tap-Tunnel ist batman-advanced reingebridged und sorgt wohl für das Routing … auf Layer 2.
Anyway. Ich have nun ein gw04.ffgt, zu diesem haben zwei Testknoten von Freifunk Güterlsloh Verbindung: testing1.freifunk.tobias.tim.pe (ea:94:f6:ac:65:46) und freifunk-e894f6524b54 (ea:94:f6:53:4b:54). Den Knoten freifunk-e894f6524b54 habe ich von gw01 abgeschnitten, ebenso die direkte fastd-Verbindung zwischen gw01 und gw04 (benötigt man diese eigentlich?).
Ergo: testing1.freifunk.tobias.tim.pe ist mit gw01 (de:ad:be:ef:00:00) und gw04 (de:ca:fb:ad:04:01) verbunden, freifunk-e894f6524b54 nur mit gw04 — eigentlich wollte ich ja ausprobieren, ob gw04 korrekt eingerichtet ist. Doch verbindet sich nun mein Tablet über freifunk-e894f6524b54 mit der Freifunk-Gütersloh-Wolke, passiert … interessantes: anstatt aus dem IP-Bereich von gw04, 10.255.4.0/24, bedient zu werden, bekomme ich erneut eine 10.255.1.0/24-IP von gw01. Die Laufzeiten sind zwar suboptimal, aber … der olle kabellose Maschendrahtzaun tut ;) Offensichtlich geht der Datenverkehr nun Tablet -> freifunk-e894f6524b54 -> gw04 -> testing1.freifunk.tobias.tim.pe -> gw01 -> Internet (per Tunnel nach Holland).
Daß dem nicht so ist, kann man auf dem lokalen Knoten sehen:
root@freifunk-e894f6524b54:~# batctl tr de:ad:be:ef:00:00 traceroute to de:ad:be:ef:00:00 (de:ad:be:ef:00:00), 50 hops max, 20 byte packets 1: de:ca:fb:ad:04:01 35.175 ms 29.222 ms 29.623 ms 2: ea:94:f6:ab:65:46 61.144 ms 58.881 ms 59.094 ms 3: de:ad:be:ef:00:00 91.786 ms 90.589 ms 91.505 ms
Ergo: mein Freifunk-Knoten geht zu gw04, von dort zu testing1.freifunk.tobias.tim.pe, von dort zu gw01. Auf Layer 3 sieht man davon nix (da das eine Layer-2-Wolke ist):
$ traceroute ns.uu.net traceroute to ns.uu.net (137.39.1.3), 30 hops max, 60 byte packets 1 10.255.1.1 (10.255.1.1) 96.118 ms 96.876 ms 97.474 ms 2 10.9.0.1 (10.9.0.1) 112.565 ms 112.681 ms 113.357 ms 3 81.4.106.1 (81.4.106.1) 119.742 ms 120.448 ms 121.192 ms 4 weservit.nikhef.jointtransit.nl (217.170.23.233) 123.310 ms 123.886 ms 124.189 ms 5 ix-2-1-2-0.tcore1.AD1-Amsterdam.as6453.net (195.219.150.13) 118.692 ms ae54-339.edge6.Amsterdam1.Level3.net (212.72.47.249) 124.434 ms asd-s4-rou-1041.NL.eurorings.net (134.222.128.201) 122.856 ms 6 vl-3613-ve-237.csw2.Amsterdam1.Level3.net (4.69.162.241) 200.020 ms if-11-2.tcore2.AV2-Amsterdam.as6453.net (80.231.152.25) 213.515 ms asd2-rou-1044.NL.eurorings.net (134.222.199.144) 113.213 ms [...]
Eigentlich wollte ich gw04 ja statt gw01 für die Kartendienste nutzen — aber irgendwie greifen beide ins Klo, und bei gw04 kam bislang nie die Sicht von gw01 an …
gw01:~# batadv-vis -f jsondoc
{
"source_version" : "2014.2.0-15-g71b36fa",
"algorithm" : 4,
"vis" : [
{ "primary" : "de:ad:be:ef:00:00",
"neighbors" : [
{ "router" : "de:ad:be:ef:00:00",
"neighbor" : "ea:94:f6:ac:65:46",
"metric" : "1.000" }
],
"clients" : [
"6a:be:f5:69:40:f6"
]
}
]
}
root@gw04:~# batadv-vis -f jsondoc
{
"source_version" : "2014.2.0-15-g71b36fa",
"algorithm" : 4,
"vis" : [
{ "primary" : "de:ca:fb:ad:04:01",
"neighbors" : [
{ "router" : "de:ca:fb:ad:04:01",
"neighbor" : "ea:94:f6:53:4b:54",
"metric" : "1.000" },
{ "router" : "de:ca:fb:ad:04:01",
"neighbor" : "ea:94:f6:ac:65:46",
"metric" : "1.000" }
],
"clients" : [
"26:ce:54:da:55:ec"
]
}
]
}
Der Onkel Alfred – übrigens ein super Name zum Suchen, insbesondere zusammen mit »batman« … – läuft auf beiden gw’s als Master:
gw01:~# ps -Aelf | grep -v grep | grep bat0 0 S root 2871 1 0 80 0 - 504 - Jul06 ? 00:00:01 /usr/local/sbin/alfred -m -i bat0 0 S root 2895 1 0 80 0 - 530 - Jul06 ? 00:00:02 /usr/local/sbin/batadv-vis -si bat0 root@gw04:~# ps -Aelf | grep -v grep | grep bat0 4 S root 2108 1 0 80 0 - 2086 - 00:09 ? 00:00:00 /usr/local/sbin/alfred -m -i bat0 0 S root 2113 1 0 80 0 - 2113 - 00:09 ? 00:00:00 /usr/local/sbin/batadv-vis -si bat0
Seitdem dies so ist, ist die generelle Funkionalität aber nicht besser geworden …
Ausgangspunkt war eigentlich ›nur‹ dieser Fehler:
gw01:~# alfred-json -r 158 -f json
Warning: invalid JSON object from f8:d1:11:bd:5e:24: '[' or '{' expected near ''
Warning: invalid JSON object from f8:d1:11:cf:29:90: '[' or '{' expected near ''
{}gw01:~#
Auf dem neuen Gateway ist alles gaaaanz anders:
root@gw04:~# alfred-json -r 158 -f json
{}root@gw04:~#
Sprich: gw04 bekommt offensichtlich nicht alle Daten, und die Daten, die er/sie/es bekommt, sind einfach parsbar? gw01 jedenfalls hat die Daten – und kann sie wegen des JSON-Problems, dessen Quelle unbekannt ist, nicht nutzen. Letztendlich jedenfalls weder hilfreich noch vertrauensweckend: zwei Debian-Wheezy-Installationen verhalten sich komplett unterschiedlich :(
Nachtrag: gw01 läuft auf Kernel 3.2.0-4-686-pae 3.2.54-2, gw04 auf 3.2.0-4-amd64 3.2.60-1+deb7u1; evtl. kommen die ›invalid JSON‹-Probleme ja daher. Daß gw04 nicht für’s Routing genommen wurde, lag höchstwahrscheinlich an fehlender Aktivierung als Gateway; das hatte ich im up-Script von OpenVPN noch nicht drin. Aber die Visualisierung mittels A.L.F.R.E.D. bzw. »badadv-vis« tut, seitdem gw04 mit in der Wolke ist, nicht mehr :-( Klingt nach einer weiteren Browser-Session mit vielen offenen Tabs … Aber cool ist diese Layer-2-Vermaschung schon.
Nachtest mit gw04 und von gw01 ausgesprerrtem Knoten führte dann auch zum gewünschten Ergebnis: die Clients bekommen von gw04 IP-Adressen (10.255.4.0/24) und gehen dementsprechend auch über gw04 ins Internet. 
Und auch das letzte Rätsel konnte ich lüften; wenn auf >1 Gateway »/usr/local/sbin/alfred -m -i bat0« läuft, ist es leider nicht so, daß mehrere Alfreds – wie imho eigentlich dokumentiert – als Master funktionieren, vielmehr löschen sie dem Anschein nach wechselseitig die Daten im Mesh aus.
Bei Gelegenheit schreibe ich dann meine Erfahrungen, die Knotenkarte und Gateways aufzusetzen, noch mal zusammen, aber für den Moment freue ich mich, daß es – endlich – tut ;)