[ffdus] Stand Dinge 2016-16

Eigene Server

  • als Supernodes laufen nun ausschließlich die von @Trickster und Sabine bei Nadeshda.org gespendeten Servern, die bei OVH gehostet sind.
  • Die fastd-Supernodes aus der Wupper-Community werden nicht mehr genutzt. (Erneut ein großes Dankeschön an @phip und @DSchmidtberg für die Kooperation)
  • Der Vollständigkeit halber: Als Exit wird nach wie vor der Backbone des Freifunk-Rheinland genutzt.

BTW: Jede Vereinsmitgliedschaft hilft, den Backbone zu finanzieren, dessen Auf- und forgesetzter Ausbau man als erfolgreichstes Vereinsprojekt bezeichnen darf. Spenden geht natürlich auch.

Dokumentation

  • @jjx und @domfi haben die Eulenfunk-Dokumentation inkl der Skripte inzwischen zu einem runden Paket geschnürt. http://www.eulenfunk.de (Das ist ein ReadTheDocs, das über sein GIT auch Issues und Pullrequests nimmt, falls ihr Punkte dafür habt.)

L2TP-Setup hat sich bewährt

  • Die L2TP-Server sitzten als eigene VMs auf dem jeweiligen Eisen neben den bestehenden fastd-servern und sind per vmbr zusammengeschaltet. Auf dem l2tp-server läuft bewusst kein batman-adv, sondern der tunneldigger geht direkt auf das bat0 des Nachbarn. So konnte der gleiche UDP-Port (10000) weiterverwendet werden, nur die Ziel-IP ist anders. Und man spart sich die Hop-Penalty.
  • Das Setup ist überraschenderweise so problmlos, dass seit Installatin vor 14 Tagen keine form von Restart notwendig geworden wäre.
  • Firmware auf den Plasteroutern läuft ebenfalls störungsfrei nach der bisherigen Erfahrung auf >20 Geräten.
  • Die Diskussion um „Automigration von fastd zu l2tp via Autoupdate“ ist noch offen. Bislang sind nur Knoten „manuell“ auf l2tp umgestellt worden.
  • Wer manuell umstellen möchte, Cut&Paste für die Shell dort, alternativ eine „sysupgrade“-Firmware im Setupmode per Browser hochladen. Ein Parameter-Reset ist nicht notwendig.

Neue Firmware

Seit Sa, 23.04.16 gibt es eine neue experimental-Firmware (die vorher als „broken“ getestet wurde).
(fastd, l2tp)

  • Änderungen betreffen insbesondere die Airtime-Optimierungen. Potentiell weniger Reichweite, dafür aber mehr Durchsatz für die Clients im Umfeld. Und ggf. schnelleren Wechsel zum nächsten (stärkeren) Knoten durch früheren Abwurf.
  • Reduktion auf maximalen Sendepegel auf 19dBm (sonst 20 oder 21)
  • Erhöhung der „mcast_rate“ auf 12000 (von vormals 6000), um weniger Airtime mit faktisch nicht nutzbaren -weil langsamen- Links zu vergeuden. (18000 wäre besser, hat aber im Test einige sinnvolle Links veschwinden lassen.)
  • Sperrung der Datenraten unterhalb von 6MBit/s (u.a. 802.11a/b) für clients, damit diese nicht im „Trödelmodus“ den besser vernetzten Clients mit ihren langen Präambeln und dem Trödel-Speed die Airtime stehlen. (Danke an @RubenKelevra für die Hinweise dazu)
  • Das Linkcheck-Script ist wieder drin, welches Router restartet, die auf einem Interfaces (seit dem Boot) mindestens(!) 2 Nachbarn gesehen haben und wo dann fortgesetzt alle Nachbarn verschwunden sind (3 Checks, in jeweils 5 Minuten Abstand). Hintergrund sind Semi-Abstürze bei denen das Wifi-Modul oder aber auch ein Laninterface im laufenden Betrieb die Connectivity verliert, ohne dass das anders per Software klar erkennbar wäre. In der letzten Stable war es entfernt gewesen, da die Vermutung im Raum stand, es würde selbst für zusätzliche Instabilität sorgen. Die instabilen Nodes blieben aber (leider) auch ohne das Script wackelig.
  • Das APon/off-Script und das VPN-Meshlimit-Zeitschaltuhr-Script hatten einen Fehler, der es wirkungslos machte. Das ist gefixt.
  • Bitte gebt Bescheid, wenn ihr Schwierigkeiten deswegen an Endgeräten (Clients) beobachtet oder Meshlinks dann vermisst, die früher sinnvoll genutzt werden konnten.

Hopglass-Map

  • unterscheidet nun fastd und l2tp als meshvpn-link in der Liste der Connects in der Infobox
  • vpn-server sind nun auch auf dem Nodegraphen mit „dünnen Linien“ und untereinander verbunden und haben „ordentliche Namen“ (statt nur Mac-Adressen)
  • mehrere „falsch platzierte Nodes“ werden nun per manueller Alias-Datei auf dem Server an die richtige Stelle gezogen.

    und

5 Likes

Freut mich das es bei euch so viel bringt, bei uns sind die Anpassungen schon seit einigen Monaten drin, man merkt halt nur noch was wenn man einen großen Haufen Router updated. :smile:

Die Diskussion um „Automigration von fastd zu l2tp via Autoupdate“ ist noch offen. Bislang sind nur Knoten „manuell“ auf l2tp umgestellt worden.

Das ist ganz einfach, es muss nur das Paket „gluon-migrate-vpn“ in die Firmware mit aufgenommen werden. Dies sorgt dafür das L2TP aktiviert wird wenn Fastd vorher aktiv war. Dies klappt natürlich auch umgekehrt :smile:

Das ist schon lange drin.
Nur die Firmware ist noch nicht in dem normalen release-channel.

BTW: Per Autoupdater ist jetzt seit Samstag 30.04 die Gluon2016.1.4 im Experimental ausgerollt.
(allerdings vom Master gezogen, also noch ein paar exerimentelle Sachen mit drin)

Seit Sonntag 01.05.16 habe ich vom gleichen Build-Stand die Stable nachgezogen.
(Änderungen seit dem Master vom 23.04.2016 waren so überschaubar, dass ich das gewagt habe.)

1 Like

Kann es sein, dass manche 841er nicht mitziehen bei dem Firmware-Update?
Vergleiche Inkonsistenzen zwischen karte und map.ffdus.de bei zwei Routern:

http://map.ffdus.de/#!v:m;n:30b5c2b565da https://karte.ffdus.de/#!v:m;n:30b5c2b565da
http://map.ffdus.de/#!v:m;n:60e327c70a3c https://karte.ffdus.de/#!v:m;n:60e327c70a3c

Ich versuch nachher mal von zuhause aus den 841er (repeater) per ssh zu erreichen. Hab hier leider weder ipv6 noch ffdus-Freifunk.
Reboot des Repeaters nur durch Powercycle der ganzen Bahnseite…

Ich bin unentschlossen.
Es könnte sein. Es passiert nur leider so selten, dass ich es nie schaffe, das bei mir auf dem Tisch zu reproduzieren. Im Direkten Zugriff habe ich leider nur 8 Router und 15 weitere im erweiterten Zugriff… und denen passiert nach Murphy nix bei den Tests.

Und bei anderen ist es dann immer wichtiger, die schnell ans Laufen zu bekommen statt sie „halb lebendig“ aufzuschrauben und sich am offenen Herzen an den seriellen Port zu hängen, um da auf der Konsole PostMortem zu machen.

So, habe den 5bwash (841er) neu gestartet. Er war unterwegs mit Freifunk-SSID, verteilte aber eine 169er IPv4. Das ging so schnell, dass ich nicht an die Windows-eigene IP-Vergabe glaube (WLAN connect und nach 5 Sekunden war die IP da).

IPs:

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   IPv6-Adresse. . . . . . . . . . . : fda0:747e:ab29:9375:7da5:b194:8fd2:6167
   Temporäre IPv6-Adresse. . . . . . : fda0:747e:ab29:9375:d981:dba5:8310:1b00
   Verbindungslokale IPv6-Adresse  . : fe80::7da5:b194:8fd2:6167%11
   IPv4-Adresse (Auto. Konfiguration): 169.254.97.103
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : fe80::7c71:f7ff:fe2a:c925%11
                                       fe80::6061:61ff:fe32:6564%11

Das DNS-Suffix sieht aber wie bei mir zuhause aus, trotz Reboot des Laptop glaube ich nicht daran, dass der 841er dieses alles verteilt haben soll.

Mit dieser Freifunk-Verbindung konnte ich den 841er nicht per SSH erreichen.

Dann Powercycle, jetzt sieht alles gut aus.
Wenn der wieder abstürzt, tausche ich ihn gegen den BB16, einen von denen, die ich noch verteilen will.

Weitere Details später wieder iim Router-Debugging-Thread.