Raspberry Pi fit für Freifunk

hab die letzten Tage damit verbracht einen Raspberry Pi fit für Freifunk zu machen,
da läuft nun Raspbian mit 4.1.7+ Kernel auf einer arm6c

https://viisauksena.de/blog/raspberry-pi-und-freifunk-freiburg-or-batman-adv-mesh-network/

Ziel ist dort einiges an Service laufen zu lassen, die Meshviewer Karten mit den RRDtools Grafiken wären ein Traum gewesen, die brauchen aber bei dem Raspberry 4:37 Minuten zum generieren, inaktzeptabel. Kann sein das das mit dem neuen Raspberry deutlich besser geht.

dort und im start [Wiki] finden sich unmengen Hinweise wie man Batman-adv , batctl alfred alfred-json und fastd in Debian Umgebungen zum laufen bekommt

1 Like

Sehr schön. Ich kann ArchLinux ARM empfehlen. Dort gibt es batman und fastd im AUR (Arch User Repository) und es kann mit wenigen Befehlen installiert werden.
Per Wifi-Stick mit ath9k kann man dann auch recht einfach meshe.

Hast du eine Empfehlung für einen guten Stick mit ath9k?

Das ganze Tool funktioniert eher so inakzeptabel, Auslaufmodell. :wink:

Welche Vorteile / Nachteile habe ich zu Gluon für Raspi, das im Moment noch auf Broken steht?

Leider funktioniert Freifunk mit dem Raspi Out-of-the-box (Distro: Raspian und Co) nur bedingt da z.b. sämtliche Gluon Patches für Batman sowie OpenWRT selbst fehlen.
Ohne diese Patches gibt es mehrere Probleme:

  • Der Uplink wird mit Rebroadcasts geflutet.
  • Alfred funktioniert nicht einwandfrei da der Fragment Size zu groß ist.
  • Die Roguenet sowie Ebtables Filter greifen bei direkt angeschlossenen Clients nicht und das Mesh wird unnötigt belastet. Gerade dieser Punkt ist wichtig da man innerhalb der Batman Frames nicht filtern kann, d.h. die Pakete dürfen erst gar nicht ins Mesh geraten.

Bitte informiert euch detailliert über alle Aspekte von Gluon, dies ist nicht nur eine Zusammenstellung von Software sondern auch von Optimierungen und Fixes.

1 Like

nope leider nicht, kommt mir eher wie glücksspiel vor was die alles (zuverlässig) für modes können

mhm, die gluonpatches unterscheiden sich signifikant von den jeweiligen upstream? zumindest hatte ich alfred und batman-adv nach deren anleitung auf dem gerät gebaut

@CyrusFox ich weiß nicht was einige hier mit dem Re-Broadcast haben…
aber in unserer Bat15 Community mit 600+ Routern sieht das aktuell so aus…OHNE PATCHES!

Alfred funktioniert einwandfrei solange man ein macvlan dev mit fixer MTU anlegt.
Allerdings sehe ich auch eher einen Vorteil in Gluon da Updates eingespielt werden können
und Gluon sehr aktive Maintainer hat die schnell reagieren.

PS: Tipps & Kritik statt nur Kritik wäre auch mal nett :smiley:
Filter kann man anpassen…sind auch nur ein paar zeilen im Script^^

LG

Ich rede hier nicht primär von Supernodes, dort haben wir die Patches erst letztens wegen L2TP auch installiert, da kann man das Rebroadcasting dann auch in Richtung der Nodes abschalten. Damit sparen wir wieder ein paar Kilobit ein, auf der Node sowie Supernode Seite. Jedes bißchen hilft, daher sollte man auch die selben Version von Batman verwenden.

Im Fall von Raspberry Pi und Co als Offloader, muss Rebroadcasting abgeschaltet werden sonst hat man symetrisch zum Downlink den selben Traffic Upstream.

Ich gehe außerdem davon das wir alle was lernen wollen, daher verpacke ich meine „Tipps“ erst mal so das sie zum selbst nachdenken anregen. Die Gluon Patches anzuwenden ist jetzt nicht unbedingt Magie und es gibt sogar DKMS Debian Pakete davon.

Wenn dann jemand damit Probleme hat es einzurichten, helfe ich gerne. Aber bitte erst mal selbst ausprobieren, wir haben alle auch noch ein Leben abseits des Freifunks und können nicht immer so viel Zeit investieren um direkt alles für jeden verständlich darzustellen. Zumal es auch den Rahmen dieses Threads sprengt.

Jedes Bit was gespart werden kann sollte auch gespart werden. Evtl schaffen wir dann 250 Nodes ohne den Uplink übermäßig zu belasten und zu viel der Airtime auf den Nodes zu belegen.
In Düsseldorf steht schon der nächste Split vor der Tür, hier wird ein neues maximum von 80-100 Nodes pro Kollisionsdomäne gesetzt. Natürlich mit ein wenig Luft nach oben.

1 Like

Wir reden aber schon davon das nicht jeder Router/node im master mode läuft und clients das batman iface erst garnicht zu gesicht bekommen (in der regel), oder ? wir haben nur sehr sehr wenig alfred traffic bei 200 nodes und etwa doppelt sovielen clients hier

der kleine Raspberry sollt eübertaktet werden alfred stürzt sonst regelmässig ab,
zusätzlich sollte alfred nicht so schnell vergessen , in unserem fall haben wir die timeout von 600 (10 minuten) auf 3600 gesetzt.
dann gibt es noch einen bug der die logs vollmüllt im GB bereich : dazu hier lösungsvorschlag aus dem bugreport lesen http://www.open-mesh.org/issues/224
unnötiges zeug, xserver und so alles deinstallieren