Hat schon mal jemand den SSID-Changer (wir setzen den Eulenfunk-Fork ein) versucht mit LEDE zu benutzen? Die Images werden erzeugt und das Script ist auch auf dem Knoten vorhanden, aber im Offline-Fall wird nicht auf die Offline-SSID umgeschaltet, die „normale“ Online-SSID bleibt immer bestehen, egal ob der Knoten eine Gateway-Verbindung hat oder nicht.
Wie kann man das am besten tracen?
ich habe leider keinen Lede-Knoten im Zugriff, vermutlich wird es an der batctl-version 2017.0 liegen, oder?
(Habe ich schon mal erwähnt, dass ich screenscraping nicht mag und es viel lieber hätte, wenn batctl auch mit einem json oder meinetwegen xml anworten würde?)
Knackpunkt wird die Zeile sein:
GATEWAY_TQ=batctl gwl | grep -e "^=>" -e "^\*" | awk -F'[()]' '{print $2}'| tr -d " "
Schau mal, ob Du
batctl gwl | grep -e „^=>“ -e „^*“ | awk -F’[()]’ ‚{print $2}‘| tr -d " "
so umgebogen bekommst, dass da der Wert der TQ zum gewählten Gateway zurückkommt.
Ich fürchte dafür reichen meine Kenntnisse nicht aus.
Wenn dir eine fertige LEDE-Firmware zum Testen hilft: HiDrive
Unter Firmware/Beta/0.8.25/images/d1/lip findest du eine aktuelle Beta.
verrätst Du mir die Nextnode-IP?
BTW: Bist Du sicher, dass das LEDE ist?
Ist vom aktuellen Master gebaut - es wird auch unterhalb des gluon-Ordners ein Unterordner „lede“ angelegt und nicht mehr „openwrt“.
next_node = {
– anycast IPs of all nodes
ip4 = ‚10.15.0.1‘,
ip6 = ‚2a03:2260:2004:100::1‘,
Dein Knoten:
Der Fehler war völlig banal, keine Ahnung, warum das „uci“ mit „-q“ hinten als letztem Parameter früher überhaupt funktioniert hat.
Ist gefixt, kannst Du aber ggf. auch von Hand editieren im Knoten zum Testen mit dem vi.
https://github.com/eulenfunk/packages/commit/1951b97db14ca7b098db76cd6c64363a14de3903
/lib/gluon/ssid-changer/ssid-changer.sh
-ONLINE_SSID=$(uci get wireless.client_radio0.ssid -q)
+ONLINE_SSID=$(uci -q get wireless.client_radio0.ssid)Herzlichen Dank! Ich baue mal neu und berichte.
Perfekt, jetzt funktioniert es einwandfrei.
Nochmals herzlichen Dank!
Ich noch mal. Seit dem Release v2017.1 sorgt das Paket gluon-ssid-changer wieder dafür, dass nur noch die Offline-SSID aktiv ist. Über die Offline-SSID kann man surfen. Der Typo vom letzten Mal ist es definitiv nicht. Kannst du dir das bitte noch mal anschauen? Test-Images gibt es unter untenstehendem Link.
Wo kommt der „gluon-ssid-changer“ aus Deiner Config denn her?
Und ist der bereits auf 2017.x portiert?
Er stammt hier her: packages/gluon-ssid-changer at master · eulenfunk/packages · GitHub
Ob die Version portiert ist, kann ich dir nicht sagen. Zumindest hat sie mit dem Gluon-Master auf LEDE-Basis funktioniert, bevor v2017.1 released wurde.
Bist Du sicher, dass Du den eingebunden hast? Zumindest die von Dir oben verlinkten Dateien für site.mk und modules finde ich KEINE Referenz zum Eulenfunk-Respository. Oder ist es ein lokaler Fork?
BTW:
Ich werde -wenn die Tests laufen- den hiesigen Eulenfunk-Fork (den besagten obigen) zugunsten dessen des Rubo77-Forks aufgeben.
Ja, es ist ein lokaler Fork.
Ich baue gerade mit dem Fork von rubo77 neu und werde berichten.
Mit dem neuen Fork funktioniert es. Vielen Dank!
@collimas: teste gerne mal mit den uci einstallungen rum für den ssid-changer:
uci show ssid-changer
Für Feedback wäre ich sehr dankbar, ob alles so funktioniert, wie es soll.
Wir könnten auch mal überlegen, ob es noch weitere möglichkeiten gibt, zu testen ob der Router online ist, die wir noch einbauen könnten.
Im Moment wird ja nur getestet ob ein Gateway erreichbar ist. Wichtig wäre ja eigentlich auch, ob man über das Gateway auch ins internet kommt und dass der Router sich auch dann auf Offline stellt.
Vielleicht so was?
ping -q -i 60 -c 5 ipdieonlineseinmuss | grep -o 100%
Also beim Verlust von 5 von 5 Pings die im Abstand von 60 Sekunden verschickt werden soll reagiert werden. ( Aus comment #20 hier)
Wirklich offline ist der ja nicht … Interne Dienste sind dann trotzdem nutzbar
Dörrobstausscheider! Der Einwand ist soetwas von durch und gegessen.
Rate mal, warum dieser Thread 167 Postings lang ist. Bitte mit neuem Argument wiederkommen. Oder einfach „nicht tun“. Wir sind alle freiwillig hier und Freifunk ist dezentral.
Hab mir nur das letzte Posting angeguckt, ehrlich gesagt 
Aber wenn ich offline lese, dann ist das für mich auch offline. Vllt macht man dann 2 verschiedene IDs … Offline und OnlyFreifunk - keine Ahnung.
Aber für Otto-Normal auf der Straße wird kein Internet tatsächlich = Offline bedeuten 
Es tut mir leid, dass die hier Postenden nicht in jedem Posting ein Almannach mitliefern, welches den darüber liegenden Diskussionsstand zusammenfasst.
Auch das gibt es, siehe oben.
Ich würde es nicht zu kompliziert bauen; wenn das (batman-) Gateway kein Internet liefert, kann das Bug oder Feature sein (quasi ein DS-Lite mit jedem öffentlichen v4-Ziel unerreichbar wäre denk- und machbar) und bei denen, die v4-Internet zu liefern planen, sollte eigentlich auf den Gateways ein Test laufen, der im Zweifel „batctl gw off“ macht, wenn’s v4-Internet-Routing klemmt. Oder welches Setup man auch gewählt hat …
Andersrum ist nicht funktionierendes v6 trotz öffentlicher v6-IP auch mindestens ein Fehler, sprich das müßte der Vollständigkeit halber dann auch noch überprüft werden.