zwar sehe ich mich noch als neu in der Freifunk-Community (Wiesbaden), jedoch habe ich mich jetzt schon voller Begeisterung auf das Thema Raspberry Pi gestürzt…
Nach längerer Recherche im Forum, war ich tatsächlich erfolgreich beim selber Kompilieren von Gluon v2016.1.5 für und dem Deployen auf meinen Raspberry Pi 2. Als USB-WiFi-Adapter habe ich mich für den TL-WN722N entschieden, da dieser bereits mit entsprechenden Modulen unterstütz wird.
Jetzt stelle ich mir die Frage, wie ich das Meshen des Raspberry Pi auch nachvollziehbar testen kann? Meine häusliche Freifunk-Installation beruht auf einem TL-WR1043ND ebenfalls mit Gluon, der über VPN-Mesh mit dem Freifunk-Netz kommuniziert. Mein Raspberry Pi soll aber über kein LAN-Kabel verfügen, sondern ausschließlich über WiFi meshen. Beiden Gluon-Geräten habe ich einen SSH-PublicKey hinterlegt, sodass ich mich gerne im Terminal austoben kann.
Meine konkreten Fragen:
Wie kann ich also nachvollziehbar beweisen, dass der Raspberry Pi auch tatsächlich mit dem TL-WR1043ND kommunizert und seinen Weg ins Internet findet?
Wie kann ich sicherstellen, dass mein Laptop am Raspberry Pi und nicht am TL-WR1043ND verbunden ist (beide haben die gleiche SSID wiesbaden.freifunk.net)?
zu 1)
wenn er auf Statusseite und/oder Karte deiner Community auftaucht, mesht er wohl.
alternativ schaltest du temporär das client-wifi des 1043 ab und guckst, ob du dennoch im Freifunk-WLAN Verbindung ins Internet hast.
per SSH kannst du es aber auch prüfen, wenn du auf einem der beiden eingeloggt bist:
batctl o | grep -v vpn
zu 2)
grob Anhand deines Empfangsbalkens, genauer bei Linux anhand der MAC-Adresse.
alternativ aber auch einfach anhand der Anzahl der Clients, meist sichtbar auf der Karte und/oder der Statusseite des Knotens.
per SSH:
batctl kennt auch den traceroute … damit bekommst du den genauen weg auch gesagt.
mit batctl gwl … siehst du auch den nexthop und das zugehörige interface was er als „gateway benutzt“
Danke für den Hinweis auf batctl, das kannte ich bisher nicht.
Auf dem 1043er erhalte ich mit den Befehlen auch sinnvolle Ergebnisse. Auf dem Raspberry Pi allerdings erhalte ich bei den Aufrufen von batctl mit o oder tl oder gwl leider nur die Fehlermeldung:
Error - interface bat0 is not present or not a batman-adv interface
ist batman geladen? mesh überhaupt an?
ich erinnere mich das nach dem laden des kernelmoduls (bspw. modprobe batman-adv ) man auch noch unterschiedliche IF in batman einhängen muss (bspw. batctl if add wlan0 ) und auch das default IF bat0 hoch nehmen muss (bswp. ifconfig bat0 up )
batctl if - wird dir im moment vermutlich auch nicht die interfaces sagen , sondern auch mit einem fehler enden, dmesg |grep bat wäre ganz gut , wenn du denn das kernelmodul geladen hast.
So sieht es so aus , als ob das nicht geladen ist, insofern ist auch das meshen eher nicht !
vielleicht schauste mal bei diesem links hier vorbei :
Inzwischen habe ich feststellen müssen, dass Gluon auf meinem Raspberry Pi zwar läuft aber nicht mesht, obwohl ich meine, im Web-Frontend alles korrekt eingestellt zu haben. Darum habe ich mich mit all euren Hinweisen auf die Suche nach dem Problem begeben.
Mir ist also aufgefallen, dass das Interface bat0 überhaupt nicht vorhanden war. Mangels Erfahrung habe ich zunächst nicht gewusst, was das bedeuten mag…? Intuitiv habe ich nochmals den Konfigurationsmodus aufgesucht und testweise auch das VPN-meschen über’s WAN zu aktivieren. Daraufhin ist tatsächlich das Interface bat0 aufgetaucht und plötzlich konnte dieser Knoten auch über WLAN meschen. Komisch.
Was ich jedoch haben möchte ist ein Knoten, bei dem ich das VPN-Meschen bewusst abschalte. Der Knoten soll über gar kein LAN-Kabel angeschlossen sein, sondern ausschließlich über’s WLAN meschen. Wenn ich jetzt hoffentlich korrekterweise das VPN-Meschen über WAN abschalte, verschwindet das Interface bat0wieder.
Ist dieses Verhalten von Gluon so korrekt oder habe ich selbst einen Denkfehler?
nochmal langsam zum mitschreiben, bitte beschreibe nochmal seeeehr genau woran der kabelmässig hängt, ob an dem ende „nativ“ internet rauspurzelt (wie an einem xbeliebigen router) … ob daran andere meshende Freifunkgeräte hängen.
mesh-vpn als Interface ist das was fastd in den meisten beschreibungen benutzt. insofern würde dein raspberry den uplink via kabel benutzen um sich direkt mit einem supernode zu verbinden. Das willst du nicht, sagst du.
Zum meshen via WLAN - brauchst du 1. einen meshenden Freifunkknoten in deiner nähe und musst 2. entsprechendes IF aufmachen auf dem WLAN deines raspberry, bitte beschreibe doch mal 1. welche Community mit welchem Mesh"Technik" und 2. welche bridge und was du getan hast um die mit diesem mesh netz zu verbinden
als technik wird da häufig ibss0 - also adhoc verbindungen aufgebaut, oder der 802.11s meshpoints (hoffe da sag ich jetzt nix falsches)
unabhängig davon musste dieses IF auch noch in bat0 als client einhängen. (weil du meintest das zu wollen)
du hast nichts zu meinen bisherigen Fragen gesagt, insofern ist eine "blind"hilfe für dich echt schwierig.
nochmal, bitte beantworte (dir und) uns die obigen fragen und evtl die ausgabe von batctl gwl batctl if batctl gw dmesg |grep batman ifconfig -a
mit deiner Hilfe kriegen wir das schon irgendwie gewuppt
Gluon auf einer „Exotischen Platform“ (egal ob jetzt Futro, VM oder RPI) ist etwas, was kaum zum Einstieg oder Erstlingswerk taugt.
Wenn man das tut, dann sollte man mindestens einen weiteren FF-Router mit möglichst ähnlicher Firmware im Zugriff oder besser noch direkt daneben haben.
Und vielleicht auch Übung mit dem Werkzeugsatz in der Gluon-Busybox. Ansonsten wird das mit dem Debugging nicht trivial.
Also, wie Anfangs erwähnt, habe ich einen 1043er als Freifunk-Router im Einsatz. Der Raspberry Pi soll keine eigene VPN-Verbindung ins Freifunknetz aufbauen, sondern ausschließlich übers WLAN meshen.
Folgend sind das die Ausgaben der o.g. Kommandozeilenbefehle. Es gibt die Interfaces wlan0 sowie wlan1, weil ich noch austesten will, welcher USB Dongle dazu besser taugt.
root@1-FF-Frauenstein-Nord:~# batctl gwl
Error - interface bat0 is not present or not a batman-adv interface
root@1-FF-Frauenstein-Nord:~# batctl if
root@1-FF-Frauenstein-Nord:~# batctl gw
Error - interface bat0 is not present or not a batman-adv interface
root@1-FF-Frauenstein-Nord:~# dmesg | grep batman
[ 9.006066] batman_adv: B.A.T.M.A.N. advanced 2015.1 (compatibility version 15) loaded
root@1-FF-Frauenstein-Nord:~# ifconfig -a
br-client Link encap:Ethernet HWaddr B8:27:EB:6D:96:24
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
br-wan Link encap:Ethernet HWaddr BA:28:EB:6D:96:24
inet addr:192.168.1.108 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::b828:ebff:fe6d:9624/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:700 errors:0 dropped:0 overruns:0 frame:0
TX packets:363 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100506 (98.1 KiB) TX bytes:60812 (59.3 KiB)
eth0 Link encap:Ethernet HWaddr B8:27:EB:6D:96:24
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:700 errors:0 dropped:0 overruns:0 frame:0
TX packets:363 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:100506 (98.1 KiB) TX bytes:65072 (63.5 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:612 errors:0 dropped:0 overruns:0 frame:0
TX packets:612 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:43002 (41.9 KiB) TX bytes:43002 (41.9 KiB)
local-node Link encap:Ethernet HWaddr 02:00:0A:38:00:01
inet addr:10.56.0.1 Bcast:10.56.63.255 Mask:255.255.192.0
inet6 addr: fd56:b4dc:4b1e::1/128 Scope:Global
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
teql0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr C0:4A:00:11:2E:86
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan1 Link encap:Ethernet HWaddr 80:1F:02:C4:EE:5B
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Und wie folgt sieht die WLAN-Konfiguration im Webfrontend aus.
ok das hilft ein wenig, weisst du welches batman wiesbaden benutzt? du benutzt bat-v15 … kann gut sein das das passt, aber sicherheitshalber sollte das abgeglichen werden. (einfach per ssh auf dem Wiesbaden Knoten mal batctl gwl aufrufen, da steht die batman version in der ersten zeile.
Da du da eh schonmal drauf bist auf deinem Knoten, check gleich mal ifconfig ibss0 und cat /etc/config/wireless - die daten brauchst du …
Wenn das passt, was ja gut sein kann, dann fehlt dir in jedem Fall das passende MESH interface … ibss0 in dem wiesbadener Teil. Das ist das IF was du für dein mesh wlan brauchst … der Wiesbadener Knoten sollte sowas ja schon haben - und der raspberry muss das ja erstmal aufmachen dieses IF fügst du dann mit ____ batctl if add ibss0 ____ zu bat0 zu https://github.com/freifunk-mwu/site-ffmwu/blob/master/site.conf.tpl#L26
da musste mal kucken was und wie genau das IF da sein muss … siehe oben. Am einfachsten aus dem knoten kopiert, der wiesbadener source selber benutzt da variablen.
hier beispielsweise /etc/config/wireless aus Freiburg (kann sein das das bei euch ANDERS ist)
Wenn dein Raspberry auch gar kein Kabel am LAN-Port hat, lass doch einfach das Mesh-VPN aktiviert, dann hast du deine Lösung. Ohne Kabel nutzt er es ja dann sowieso nicht
@rotanid er will glaub nicht via wifi-client einen eigenen tunnel aufmachen - was freifunk durch freifunk wäre, wenn der wifi-ap selber ein freifunk knoten ist. - ich glaube genau darum geht es -das ganze sauber hinzubekommen
@rotanid stimmt ich hab die ausgangsfrage nochmal gelesen, das gerät ja gerne mal out of focus … die „einfachste“ lösung ist tatsächlich sich selber mit dem raspberry in das Freifunk als client einloggen … und dann das wifi if in bat0 hängen. Sowie am Gegenstück , dem freifunk 1043 knoten mit mesh-vpn ins freifunknetz client0 (ist glaub das wifi IF ) dort ebenfalls in bat0 hängen.
(mein Denkfehler war das man dort eben tunlichst dann nicht fastd drauf lassen sollte , was ja bisher keiner vorhatte, die irritation kommt daher was denn genau da „meshen“ soll - batman alleine würde das ja tun. Wenn der raspberry aber wirklich das mesh if aufmachen soll und so auch anderen freifunk knoten einen "mesh"point geben soll, dann musste wie weiter oben beschrieben das ibss0 an den start bringen)
einige schnelle tipps dazu … falls es hakt, am raspberry batman kernel modul laden (modprobe batman-adv) , ifconfig bat0 up, batctl if add wlan0 (oder welches if sich als client einloggt)
und eben das einloggen „machen“ …
am Freifunk knoten , batctl if add client0
je nachdem was du mit dem knoten der dann im batman-layer2 switch = freifunk hängt vorhast kommen dann weitere schritte (wie bspw. batctl gw client 20 , udhcpc -b -i wlan0 , odhcpc wlan0…) … aber vielleicht willste ja nur batman und alfred nutzen, was an dieser stelle dann schon geht
Generell funktioniert der Raspberry PI zwar unter Gluon, ich durfte aber die Erfahrung machen das bei meinen Tests jeweils die komplette Wifi-Config kaputt war.
Schau mal unter /etc/config/wireless was denn für eine Konfiguration für deinen WLANSticks angelegt wurde.
Normalerweise legt er dort dann die Openwrt-Default-Config an, die leider nicht wirklich für Freifunk geeignet ist.
Wie von @fuzzle beschrieben musst du die komplette WLanconfig daher manuell einrichten.
Generell:
Mit den WLanSticks aufpassen - nicht alle können Mesh+Clientnetz gleichzeitig.
Daher mit iw list in der Konsole nachschauen was supported wird, oder 2 Sticks nutzen.
Wenn eine nicht unterstütze Kombination gefahren wird, ist meist das Fehlerbild sehr uneindeutig, der Stick startet einfach nicht oder hängt anderweitig.
Einfach greppen wird wohl nichts, aber schaue mal unter den Zeilen nach „Supported interface modes:“ und „interface combinations“.
Bei den interface modes muss IBSS mit drinnen stehen, neben AP.
Bei den Combinations muss dann IBSS und AP gleichzeitig möglich sein. Bzw es darf nicht dastehen, das sie unsupported sind.
Sieht für mich so aus, als würde ibss mesh und managed Mode nicht gleichzeitig gehen(Interface combinations). Damit brauchst du 2 Sticks, oder musst warten bis 11s in deiner community ausgerollt wird.
Einen Stick als Ibss mesh konfigurieren und ins bat0 einbinden(config wie im link, oder vom bestehenden Knoten kopieren), den anderen dann das Clientnetz aufspannen lassen.
Edit: Vll reicht es auch schon, im webinterface/configmode jeweils nur einen der Modi pro Stick zu aktivieren - sollte ja auch nichts anderes sein wie wenn man es manuell eintraegt.
Das ist schade. Vielleicht bin ich einem Irrtum erlegen? Denn den USB-WLAN-Adapter TL-WN722N habe ich mir gekauft, weil dieser in einer anderen Diskussion in diesem Forum empfohlen wurde: Gluon-tauglicher USB-WLAN-Stick