Voll verma(t)scht und visualisiert

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.frei­funk.to­bias.tim.pe ist mit gw01 (de:ad:be:ef:00:00) und gw04 (de:ca:fb:ad:04:01) ver­bunden, frei­funk-e894f65­24b54 nur mit gw04 — ei­gent­lich wollte ich ja aus­pro­bieren, ob gw04 korrekt ein­ge­rich­tet ist. Doch ver­bindet sich nun mein Tablet über frei­funk-e894f6­524b54 mit der Frei­funk-Güters­loh-Wolke, passiert … in­ter­es­san­tes: anstatt aus dem IP-Be­reich von gw04, 10.255.4.0/24, bedient zu werden, bekomme ich erneut eine 10.255.1.0/24-IP von gw01. Die Lauf­zeiten sind zwar sub­op­timal, aber … der olle kabel­lose Maschen­draht­zaun tut ;) Offen­sicht­lich geht der Daten­ver­kehr nun Tablet -> freifunk-e894f6­524b54 -> gw04 -> testing1.frei­funk.to­bias.tim.pe -> gw01 -> Inter­net (per Tun­nel nach Hol­land).

Screenshot

Einsamkeit …

Was ich allerdings nicht begreifen – und das war eigentlich Sinn der Übung –: in der B.A.T.M.A.N.-Wolke scheint das so nicht stattzufinden, wenngleich ich auf IPv4-Ebene nach wie vor Surfen kann. Lt Knotenliste, Knotengraph usw. ist gw01.ffgt mittlerweile isoliert, alleine im Kosmos.

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.frei­funk.to­bias.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.

Screenshot

gw04 tut nun …

Nachtrag 2: Weitere Untersuchung der Firmware hat ergeben, daß die Daten als gezipptes JSON in Alfred hochgeschoben werden; mit der Änderung des Aufrufs auf »alfred-json -z -r 158 -f json« werden nicht nur die Daten ausgespuckt, sondern auch gibt es keine Fehler mehr: Hurra! (Was ich von Software, die komprimierte Daten nicht automatisch erkennt, halte, darf ich nicht sagen; das wäre justiziabel. Narf!)

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.

Screenshot

… der Tunnel geht derzeit von Nürn­berg aus über meinen hol­län­di­schen Rasp­berry Pi.

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.

Screenshot

Schwere Geburt, aber nun läuft auch die Knotenkarte …

Fakt ist jedenfalls, daß, sobald ich auf gw04 »alfred« als Master starte, in der Knotenliste nach und nach die Knoten verlustig gehen. Stoppe ich auf gw04 dann wieder »alfred«, füllt sich auf gw01 wieder die Datenbasis … Nicht ganz, was ich mir erhoffte, aber okay erstmal.

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 ;)