Gluon (Lede) und Archer C2600

Bist du mit deinen C2600 weitergekommen?

Jain, konnte noch nichts testen. Aber schau mal hier:

Lieben Gruß

Ruben

@RubenKelevra
Genau damit (dein Link) habe ich ja meine Version gebaut. (s.o.)

Testen hört sich so an als ob du eine Version installiert bekommen hast und läuft bei dir batman?
Hast du auch das Boot-Problem?
(Habe im Git dein damaliges Issue gelesen)
Schönen Gruß zurück
Clemens

Ich hatte mal OpenWRT drauf, das lief (nur halt ohne passende WLAN-Treiber).

Gluon wollte damals nicht kompilieren, seit dem Ticket ist von meiner Seite nichts mehr passiert, hab schon genug Zeit investiert gehabt und 0 Unterstützung dafür zurück.

Alles was LEDE angeht kann ich dir nicht beantworten, hab noch keine Hardware damit ausgestattet. Der C2600 liegt hier im Schrank bis Gluon damit läuft.

Gruß

Ruben

So einen passiv-agressiven Kommentar halte ich für wenig zielführend. Wie wär’s stattdessen mit konstruktiver Kritik? :wink:
Keine Ahnung, wieso genau du gefrustet bist, aber meine Erfahrung ist da eine gänzlich andere. Ich habe viel und gute Unterstützung von @anon75826926 bekommen, als ich am LEDE-Support für den D-Link DIR-869 mitgearbeitet habe. Wenn man Spaß am Tüfteln, Durchhaltevermögen und eine hohe Frustrationstoleranz hat, dann kann man sich der Aufgabe, an der LEDE-/Gluon-Unterstützung für ein neues Gerät zu arbeiten, stellen - mir hat’s Spaß gemacht und ich habe viel dazugelernt.

Das war in keiner Weise aggressiv gemeint.

OpenWRT kompilierte wunderbar, Kiste lief und deswegen sollte Gluon kein großes Hindernis sein.

Nachdem ich den gesamten Branch von OpenWRT durchforstet hatte und alles zusammen gesammelt in ein großes Patchset, damit auch die ältere OpenWRT-Version das Target kompilieren kann, welches Gluon damals verwendet hat musste ich feststellen, das Gluon nach allem Kompilieren am Zusammenbau des Images scheiterte.

Ich hab noch einige Stunden herum gesucht aber das eigentliche Problem nicht gefunden. Dann hab ich das entsprechende Ticket erstellt.

Ich erwarte nicht unbedingt Hilfe bei solchen Problemen, wenn aber Zusagen wie, in zwei Wochen hab ich dafür Zeit, gemacht werden, das ist es einfach frustrierend wenn dann doch über Monate nichts passiert.

Insbesondere da die Hardware durchweg interessante Spezifikationen hat.

Auf die Bitte hin die Patches per Mail einzureichen ist übrigens auch, außerhalb des Tickets, keinerlei Antwort mehr eingegangen.

Insgesamt war meine Antwort hier mit keiner Wertung verbunden, das ist ein Freizeit Projekt und Freizeit bedeutet auch, jeder investiert die Zeit die er hat und tut das wo er Lust und Spaß dabei hat.

Jemanden dafür zu kritisieren auf meine Problemlösung keine Lust zu haben liegt nicht ferner von dem was ich ausdrücken wollte.

Hätte ich ein Problem mit @anon75826926 oder seiner Arbeit, würde ich diese Kritik ihm gegenüber äußern uns nicht öffentlich in einem Forum.

Im Gegenteil, er macht eine unglaublich umfangreiche und verantwortungsvolle Aufgabe in unserer Community und sollte dafür öfter gelobt werden!

Die Frage die sich hier gestellt hat war aber, ob ich helfen kann - und das muss ich verneinen. Ich hab derzeit keine Lust mehr die Hardware aus dem Schrank zu kramen und weiter herumzudoktorn, das können andere erstens viel effektiver und zweitens mit viel mehr Spaß dabei.

1 „Gefällt mir“

Hallo zusammen,

habe gerade den Archer C2600 mit Gluon auf Lede Basis 2017.1.1 ausprobiert, jedoch bestehen die genannten Probleme immer noch. Bei Reboot schaltet der Router ab, VPN wird nicht aufgebaut. An der Konfig kann es nicht liegen, habe andere Router mit dem gleichen Build laufen WDR4900 z.B. Es handelt sich bei meinem C2600 auch um Version 1.1.
Per SSH komme ich ja drauf, im Logread fiel mir auf: Failed to resolve hostname ‚wetter-1.ff-en.de‘.
Vielleicht hilft das irgentwie, komplettes Logread kann ich auch gern bereitstellen.

Hier ein erstes Fazit mit Gluon 2018.1:

  • Reboot-Problem beim C2600 v1.1
  • Mesh-VPN via Tunneldigger/L2TP läuft
  • WLAN-Meshing läuft ebenfalls
  • Mesh-on-LAN-Config muss noch gefixt werden
  • Client-Netz läuft noch nicht richtig
  • LEDs funktionieren noch nicht richtig

Ich baue gerade den Gluon-Master, der basiert auf der neuen OpenWRT-Version. Stay tuned.

3 „Gefällt mir“

Das Gerät läuft jetzt mit dem aktuellen Gluon-Master (Stand 2018-07-13)
https://karte.freifunk-muensterland.de/map36/#!v:g;n:18a6f758646a

  • Client-Netz auf jeden Fall stabiler, aber wohl noch mit Luft nach oben
  • Reboot klappt jetzt auch beim C2600 v1.1
    • Vermutung: firstboot muss nach dem Upgrade von LEDE 17 auf OpenWRT 18 ausgeführt werden, um das Reboot-Problem zu beheben.

Was genau bedeutet das? sehr vage Angaben, die zu einer möglichen Lösung wenig nützen :wink:

Ich arbeite dran :sweat_smile:

Das versuche ich gerade zu präzisieren. Vielleicht ist es auch nur ein Irrtum – aber wenn ein Multicast-Ping auf die link local-Adresse keine Antwort liefert, sieht das m. E. nach einem Fehler aus.

EDIT: Wie kann man sich zukünftig über eine MoL-Port mit dem Router via SSH verbinden oder ist das nicht mehr vorgesehen?

Es kommte eine Verbindung zustande, die wird häufig innerhalb von wenigen Sekunden wieder beendet. Ich poste Details, sobald ich sie habe.

Die WiFi-LEDs funktionieren nicht, der Rest schon. Das Problem ist bekannt.

So – da ist natürlich™ alles in Ordnung. $Benutzer war nur nich darauf vorbereitet, dass er seit 2018.1 nicht mehr einfach seinen Laptop an den MoL-Port anschließt und sich dann über die link local-Adresse per SSH verbindet…

Das ist natürlich ärgerlich, das war hier bei halb abstürzenden Routern im Mesh immer der Notnagel, ssh auf der fe80-Adresse.

Wenn das nicht mehr geht, dann brauche ich Paket, was das wieder möglich macht… Anyone?

Ggf. geht das noch, wenn man die ‚eigene‘ Netzwerkschnittstelle von Hand konfiguriert, da fehlt mit bei IPv6 aber die Ahnung, we das geht.

Die Clients fliegen nach ca. 4 Sekunden wieder raus. Mein Debian-Laptop bekommt gar keine Verbindung. Das Fairphon2 bleibt z. B. trotz der ständigen Disconnects verbunden, aber nur, wenn kein anderer Knoten in der Nähe ist.

Sun Jul 15 19:31:27 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: associated (aid 1)
Sun Jul 15 19:31:27 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:31 2018 daemon.notice hostapd: client1: AP-STA-DISCONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:31 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: disassociated
Sun Jul 15 19:31:32 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Jul 15 19:31:32 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: authenticated
Sun Jul 15 19:31:32 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: associated (aid 1)
Sun Jul 15 19:31:32 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:35 2018 daemon.notice hostapd: client1: AP-STA-DISCONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:35 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: disassociated
Sun Jul 15 19:31:36 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Jul 15 19:31:36 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: authenticated
Sun Jul 15 19:31:36 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: associated (aid 1)
Sun Jul 15 19:31:36 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:39 2018 daemon.notice hostapd: client1: AP-STA-DISCONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:39 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: disassociated
Sun Jul 15 19:31:40 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Jul 15 19:31:41 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: authenticated
Sun Jul 15 19:31:41 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: associated (aid 1)
Sun Jul 15 19:31:41 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:45 2018 daemon.notice hostapd: client1: AP-STA-DISCONNECTED b0:f1:ec:fd:2f:fb
Sun Jul 15 19:31:45 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: disassociated
Sun Jul 15 19:31:46 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Jul 15 19:31:46 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: authenticated
Sun Jul 15 19:31:46 2018 daemon.info hostapd: client1: STA b0:f1:ec:fd:2f:fb IEEE 802.11: associated (aid 1)

Ein anderes Endgerät springt pausenlos zwischen 2.4 GHz und 5 GHz-Band hin und her:

Sun Jul 15 22:41:30 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:41:31 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:41:31 2018 daemon.notice hostapd: client0: AP-STA-CONNECTED 84:55:a5:54:52:83
Sun Jul 15 22:41:41 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:41:41 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:41:41 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED 84:55:a5:54:52:83
Sun Jul 15 22:41:45 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:41:45 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:41:45 2018 daemon.notice hostapd: client0: AP-STA-CONNECTED 84:55:a5:54:52:83
Sun Jul 15 22:41:53 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:41:53 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:41:53 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED 84:55:a5:54:52:83
Sun Jul 15 22:41:57 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:41:58 2018 daemon.info hostapd: client0: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:41:58 2018 daemon.notice hostapd: client0: AP-STA-CONNECTED 84:55:a5:54:52:83
Sun Jul 15 22:42:06 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: authenticated
Sun Jul 15 22:42:06 2018 daemon.info hostapd: client1: STA 84:55:a5:54:52:83 IEEE 802.11: associated (aid 1)
Sun Jul 15 22:42:06 2018 daemon.notice hostapd: client1: AP-STA-CONNECTED 84:55:a5:54:52:83

Hmm, ist das nicht »nur« der VXLAN-Layer, den man per »mesh = { vxlan = false, },« in der site.conf deaktivieren kann?

ich wusste bisher gar nicht, dass die link-local Adressen auf mesh-on-lan ports funktioniert hatten :smiley:
vielleicht war das nur „aus Versehen“ möglich, da mit Release 2018.1 die firewall etwas umgebaut wurde geht es nun nicht mehr?
oder @wusel hat Recht und es liegt an der VXLAN-Umstellung

Bzgl. der Client-Verbindungen bin ich etwas ratlos.
wurde mit 11s oder ibss gebaut?
gehen wifi-mesh-Verbindungen einwandfrei? (dazu bitte alle mesh-on-lan/-wan/-vpn abstecken)

1 „Gefällt mir“

Das war der Regelbetrieb bei uns, weil man sich dann am wenigsten Gedanken machen muss, insbesondere wenn man über Stock-Richtfunk-Links kommt, auf denen nur Batman gesprochen wird.

1 „Gefällt mir“

Eventuell liegt die Änderung „nur“ an der Firewall. Archer C2600 – Mesh-on-LAN interface unavailable · Issue #1481 · freifunk-gluon/gluon · GitHub

Ein ganz konventioneller Build mit 11s. Das WiFi-Mesh läuft ganz hervorragend. Das Build lief mit einer auf v2018.1 angepassten site.conf des Freifunk Münsterland mit vxlan = false,.

1 „Gefällt mir“