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
Worauf lässt das schließen?
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 :
https://viisauksena.de/blog/raspberry-pi-und-freifunk-freiburg-or-batman-adv-mesh-network/
2 „Gefällt mir“
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.
Sorry, falls ich n00bhaft etwas verkorkst habe :-/
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)
config wifi-iface 'ibss_radio0'
option ifname 'ibss0'
option network 'ibss_radio0'
option device 'radio0'
option bssid '02:d1:11:37:fc:38'
option disabled '0'
option mcast_rate '12000'
option mode 'adhoc'
option macaddr '16:be:5d:07:e6:72'
option ssid '02:d1:11:37:fc:38'
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
seit wann machen gluon-APs VPN-Verbindungen über Wifi? zumindest nicht ohne manuelle Eingriffe…
1 „Gefällt mir“
@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.
Ich hatte das hier mal für unsere Firmware aufgeschrieben:
https://wiki.tecff.de/bastelprojekte/freifunk-pi
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.
1 „Gefällt mir“
Wonach muss ich bei iw list genau greppen, um sicher zu sein, dass ein Stick Mesh+Clientnetz gleichzeitig kann?
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.
Das hier ist die Ausgabe von iw list für den WLAN-USB-Adapter TL-WN722N:
Wiphy phy0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports T-DLS.
Available Antennas: TX 0x1 RX 0x1
Configured Antennas: TX 0x1 RX 0x1
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* outside context of a BSS
Band 1:
Capabilities: 0x116e
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
valid interface combinations:
* #{ managed, P2P-client } <= 2, #{ AP, mesh point, P2P-GO } <= 2,
total <= 2, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
` ` `
Sieht doch gut aus, oder?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
Der schaut auch super aus, was die Daten angeht, mit externer Antenne usw.
Ist auf keinen Fall eine Fehlanschaffung - nur halt für den gleichzeitigen (vermutlich!) Betrieb nicht geeignet.
Wenn ich mich korrekt erinnere hatten wir bei uns mal überlegt, ein zweites Mesh auf Kanal 13 zu legen, damit das Clientnetz nicht gestört wird, in Kombination mit Routern die USB unterstützen. Für sowas ist der dann super.
Wenn ich deinem Screenshot und Post richtig entnehme, dass du eh 2 Sticks hast, würde ich das so einstellen das ein Stick mesht und der andere auf einem anderen Kanal das Clientnetz aufmacht.
Ist auch besser für die Performance 
Kannst du mal deine /etc/config/wireless posten?
Die verlinkte Wikiseite hat auch die Anleitung, was da reinmuss - deine SSID fürs mesh ist dann aber die von Freifunk Wiesbaden, also ‚64:32:16:08:04:02‘ auf Channel 6.
Am einfachsten wäre es wohl, wenn du nur einen Stick einsteckst, rebootest, die wirelessconfig öffnest, dort die änderungen für das mesh einträgst(+die Änderungen in der /etc/config/network), dann schaust ob batman läuft und das meshing funktioniert.
Danach dann alles sichern, zweiten stick rein, schauen ob die config heilgeblieben ist, und das gleiche für den zweiten Stick und das Clientnetz wiederholen.
So hatte es bei mir dann nach einigem hin und her geklappt…
1 „Gefällt mir“
Um diesen Thread zum Abschluss zu bringen… habe ich es nun mit ALL EURER Hilfe geschafft! Mein Raspberry Pi verfügt jetzt über Zwei USB WLAN Adapter, die jeweils eine der Aufgaben, zum Meshen bzw. Accessen der Clients, übernehmen.
Mein initialer Irrtum war, wie sich tatsächlich heraugestellt hat, der, dass ich fälschlicherweise davon ausgegangen bin, mein Adapter könne gleichzeitig in den beiden Modi Adhoc sowie AP arbeiten.
Nach dem Hinweis von @Brother_Lal habe ich schließlich die Datei /etc/config/wireless zunächst verstanden und dann manuell entsprechend angepasst.
2 „Gefällt mir“