Es gibt einen LEDE-Patch und Gluon basiert auf LEDE. Und LEDE-technisch wird auch LEDE fortgeführt, es heißt dann nur wieder OpenWRT.
Das einzige, was halt etwas kniffelig sein könnte, wäre es den Patch von LEDE-Master auf Lede-Release zu portieren. Das hat aber @rotanid scheinbar getan, weil es einen PR gibt.
und sobald jemand nachweislich erfolgreich auf dem v2017.1.x branch getestet hat, kommt er auch dorthin.
sollte funktionieren, aber ohne test trotzdem erstmal nicht.
Danke Mathias, ich seh das der Router auf die IP 10.83.0.1 nur Anfragen per SSH zulässt.
Es läuft über Netzwerkkabel auch kein DHCP, über WLAN SSID „trainstation.freifunk“ bekomme ich eine IP zugeweisen aus dem Bereich: 10.83.0.x
Hallo Christian
danke, ich hatten soeben die IP 10.83.0.1 gepingt und hatte etwas unter 6 ms, und das über WLAN dachte erst es sei der Router selbst. Nachdem ich das WAN Kabel enfernt habe, war auch kein Ping mehr auf die 10.83.0.1 möglich. Einzugriff auf die LAN Ports 192.168.1.1 ist auch nicht möglich.
Dachte wirklich diese bassiert auch auf OpenWRT ops…
Adressen sollten auch per SSH gehen, default PW ist root:ffol sowohl ssh als auch Webui (bitte umgehend ändern)
P.S. Der Webserver auf dem Gateway der in der Trainstation eine Sperrseite ausliefert war leider auch kaputt, ich hab das eben mal repariert. Wenn du nun „einfach“ example.com (oder irgendeine andere Seite bis auf ein paar wenige Ausnamen) aufrufst, sollte eine Sperrseite mit einem Link zur Routerkonfiguration kommen. Der keyxchangev2 den du aktuell nutzt, ist noch stark in der Entwicklung daher gibt es hier oder da noch hakler, also nicht wundern. Danke auf jeden Fall für die Info hab gerade wieder paar Probleme beheben können
Und achja, das ganze hat nix mit Gluon zu tun, du hast kein Gluon also werf alle Gluonanleitungen über den haufen
wie bereits gesagt, wir nutzen kein Gluon und bei uns gibt es kein 192.168.1.1 oder irgendeinen Konfigurationsmodus, vergess alles was Gluon so sagt, das ist für uns nicht gültig. Der Router wird im laufenden Betrieb konfiguriert. Die richtigen Adressen sind:
Was macht ihr (Du und andere) dann hier? Das hier ist das Gluon-Unterforum, nicht das „generell für Hardware“.
Wenn es um die Bedienung von Gluon ging, dann wäre das hier richtig.
Aber generell die Unterschiede zwischen Gluon und anderen Firmwares herauszuarbeiten erscheint mir zumindest dieser Thread hier nicht geeignete.
Und der Nutzer, der Hilfe sucht, muss auf solche Unterschiede nicht hingewiesen werden, weil …?
Wüsste er, warum er im falschen Unterforum fragt, müsste er ja nicht mehr fragen…
ich les nur mit und mir ist aufgefallen das „der andere“ eben meint das er Gluon nutzt was aber falsch ist, also hab ich das klar gestellt. Ich hab nur geholfen aber wenn das auch nicht mehr gewünscht wird nun gut, dann helf ich halt nicht mehr ¯_(ツ)_/¯
@der andere (immer schön abwertend schreiben ja…?) kontaktiere doch Freifunk Franken auf unseren Kontaktwegen Kommunikation – Freifunk Franken dann muss man sich nicht mit einen unfreundlichen Forum herumschlagen
Kleine Ergänzung. Christian vom Freifunk Harz e.V hat mich drauf aufmerksam gemacht, dass Mesh on LAN auf dem Master mit eine 1043v5 nicht funktioniert.
Es gibt jetzt im Vergleich zu anderen Routern ein zusätzliches Interface vx_mesh_lan.
root@x:~# ifconfig
…
vx_mesh_lan Link encap:Ethernet HWaddr 2A:E2:30:B8:AB:5C
inet6 addr: fe80::28e2:30ff:feb8:ab5c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1430 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:13634 errors:1 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:3227780 (3.0 MiB)
…
root@x:~# batctl if
primary0: active
ibss0: active
mesh0: active
vx_mesh_lan: active
mesh-vpn: active
Mit folgendem Befehl funktioniert Mesh on LAN zwischen dem 1043v5 mit Routern und Gluon 2017.1.4.
root@x:~# batctl if add br-mesh_lan
Offensichtlich ist die Änderung im Master nicht kompatibel / noch nicht vollständig mit alten Konfigurationen.
NEIN. Mailing Liste lesen ist für Firmware-Bauer pflicht, und dort wurde die „Lösung“ legacy am 27.06.2017 genannt. Sobald es ein major release gibt, steht das auch in den release notes. In der Doku steht es nicht, weil nicht-Upgrades, neue Communities, das nicht brauchen.
könntest du bitte den Backport Pull Request testen stattdessen?
Wenn der als erfolgreich getestet wird, freuen sich viele weil man dann nicht den Master Branch braucht für das Gerät in v5:
in das bisherige Protokoll um. Leider bleibt diese Einstellung nicht über ein Autoupdate erhalten. Für eine Migration ist der Default ‚0‘ nicht geeignet, denn alle Router müssen aufdatiert und umgestellt werden oder ein neuer Router muss per Hand auf das alte Protokoll umgestellt werden. Wenn der Router nur über eine Kabelverbindung erreichbar ist, muss man wohl die Turnschuhe bemühen.