Dies ist eine alte Version des Dokuments!
. Wir haben mit den Integrationsarbeiten für den Gluon Babel Masterplan begonnen.
Dinge die schon gehen
ES GEHT!
Im Detail heißt das:
- Ein Client kann sich mit einem Node verbinden und es ist Kommunikation zwischen diesen beiden Geräten möglich
 - Ein Client kann sich mit einem Node verbinden und erreicht über das Mesh einen anderen Node
 - zwei Clients an unterschiedlichen Mesh-Nodes können miteinander kommunizieren
 - zwei Clients verbinden sich mit einem Node und können kommunizieren. (jeweils switch-port, beide per wifi und wechselseitig kabel/wifi)
 - Routing ins Internet für einen Client funktioniert für IPv6 und IPv4
 - Internetzugang an mesh-only-node funktioniert
 - DNS als anycast-service funktioniert (2a06:8187:fb00:53::53)
 - DNS-cache auf node funktioniert (siehe Erweiterung durch die DNS-Tabelle in der site.conf)
 - Roaming eines clients geht (nach merge von #938)
 - Babel-Nodes erscheinen gemeinsam mit Batman-Nodes auf der Map
 - Es gibt eine funktionierende Firewall
 - Der Client-Count wird vom l3roamd per socket gemeldet.
 - folgenden Pakete wurden angepasst, sodass die benötigten Komponenten in der Firmware eingebaut ist und per ifup auch gestartet werden können.
- gluon-mesh-babel
 - gluon-l3roamd
 - mmfd
 - gluon-mesh-vpn-fastd
 - babeld 1.8
 
 
Die aktuelle Entwicklungsfirmware gibt es hier
* 14.2.2017, Version 0.0.1.0 – Alle bekannten Bugs sind behoben ⇒ Bitte testet mit uns * 17.2.2017, Version 0.0.1.1 – Der Neustart aus dem Konfigurationsmoduls kam sehr zeitverzögert. Nach dem erneuten Einbau von haveged sollte das behoben sein. ⇒ Bitte testet mit uns * 24.4.2017, Version 0.0.1.3 – Statuspage fixes (keine NExtnode-IP mehr damit werden die Daten vom richtigen Node angezeigt, Ermittlung der Clientanzahl über Statussocket vom l3roamd, Firewall-Anpassung für Ports von fastd)
Bekanntes PRoblem: respondd segfault ist in Analyse
* 27.4.2017, Version 0.0.1.4 – respondd-segfault behoben, gateway_nexthop in statistiken aufgenommen. * 4.5.2017, Version 0.0.1.5 – respondd memleaks entfernt
Die Statuspage enthält nach wie vor die Graphen noch nicht, da ist noch eine Frage zum Vorgehen offen.
* 16.6.2017, Version 0.0.1.6 – erste Version des prefixd inklusive web-frontend ist enthalten, daneben babeld-config fixes, Einführung von source-specific routing, Rebase auf gluon master, Firewall fixes für forward-traffic im mesh und zum dynamischen hinzufügen von Interfaces zur mesh-zone,
Folgeaufgaben, nachdem ein Testmesh aufgebaut ist
- Refactoring und Entfernung von dupliziertem Code in den babel-Modulen und Programmen rund um respondd in gluon-status-page-api und gluon-mesh-babel (wäre für die batman-Welt auch mal nett)
 - ggf. REJECT durch DROP ersetzen in der Firewall und Logging entfernen um die Netzleistung zu verbessern.
 - Erstellung eines prefixd
 - Wie geht lokale Service Discovery in einem l3-Netz (Bittorrent Peer Exchange, ad-hoc xmpp)?
 - l3roamd: Unterstützung des Lernens von neuen Clients auch auf bridge-interfaces
 
Workarounds
Die Firmware enthält folgende Workarounds:
- l3roamd stürzt ab, wenn er ohne client interface gestartet wird, workaround: -i lo
 - l3roamd arbeitet nicht richtig, wenn ein -4 IP-MAP-Netz nicht angegeben ist. Wird der speicherbereich initialisiert, gehts. -4 wird also angegeben.
 - babeld muss mit interface gestartet werden, workaround: lo
 
Überblick - weitere Entwicklungen
- ddhcp für ipv4-Unterstützung ist in der Entwicklung https://git.toppoint.de/sargon/ddhcpd/
 - l3roamd ist in der Entwicklung https://github.com/freifunk-gluon/l3roamd
 
technische Änderungen
- Nutzung von ff05 statt ff02 für respondd, Anpassung für hopglass.
 
IPv6 Adressen
- 2a06:8187:fb00:53::53 DNS
 - 2a06:8187:fb00:123::123 ntp
 - 2a06:8187:fbab::/48
- 2a06:8187:fbab:1::/64 Node Netz
- 2a06:8187:fbab:1::9000:xxxx Infrastrukturbereich im Node Netz
 
 - 2a06:8187:fbab:2::/64 Client Netz
 - 2a06:8187:fb00:1::/96 Netz für nat64
 
 - 2a06:8187:fbab:2::1 next-node Adresse (löst auch im Netz als nextnode auf)
 
Infrastruktur
serverseitig führen wir auf dem hopglass.babel.ffm.freifunk.net für eth2 (babel-mesh-Interface) als post-up script folgendes aus:
#!/bin/bash
IFACE=eth2
exec >/tmp/ff-log 2>&1
cat >/tmp/babeld.conf<<EOF
ipv6-subtrees true
export-table 10
import-table 11
import-table 12
interface eth2
default enable-timestamps true
default max-rtt-penalty 96
#redistribute ip 2a06:8187:fbab:2::/64 eq 128  allow
#redistribute ip 2a06:8187:fbab:1::/64 eq 128  allow
#redistribute ip 2a06:8187:fb00::/40 eq 128 allow
#redistribute local  deny
#redistribute ip ::/0  metric 256 
redistribute src-prefix 2a06:8187:fbab:2::/64 if eth1 metric 256
EOF
localnode=$(ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6addr 2a06:8187:fbab:1:: $( ip a s dev eth0|grep link/ether|awk '{print $2}'))
/sbin/ip -6 a add $localnode dev lo
# infrastruktur und client-netz über babel-table routen.
/sbin/ip -6 ru add prio 10 to 2a06:8187:fbab:2::/64 lookup 10
/sbin/ip -6 ru add prio 10 to 2a06:8187:fbab:1::/64 lookup 10
/usr/local/bin/babeld -D -s -I /var/run/babeld.pid  -G 33123 -c /tmp/babeld.conf
#TODO: there is no client interface but l3roamd crashes when started without -i
#TODO: once l3roamd supports sockets it should be started from init-script, in here only mesh-interface should be added
sleep 1
/usr/local/bin/l3roamd -p 2a06:8187:fbab:2::/64 -i lo  -m $IFACE -t 11 -a 2a06:8187:fbff:2::2 &
disown
/usr/local/bin/mmfd -v &
disown
sleep 2
/sbin/ip a add fe80::ff:3fff:fe10:7d02/64 dev mmfd0
#/sbin/ip a add 2a06:8187:fb00:2::4/128 dev mmfd0
/sbin/ip a add 2a06:8187:fbab:1:383b:9ff:fed5:9f53/128 dev mmfd0
/sbin/ip r add ff05::2:1001/128 dev mmfd0 table local
/sbin/ip link set dev mmfd0 up
/sbin/ip -6 r a 2a06:8187:fbab:2::/64 dev l3roam0 t 10
#add route to icvpn - all other freifunk networks
/sbin/ip route flush cache
Auf dem Gateway läuft fastd udn bringt die mmfd/l3roamd mit dem gleichen script (einzige AUsnahme: ff05-route wird nicht gesetzt) hoch. bird6 schreibt auf dem gateway seine default-route in Routing Tabelle 10.