Openwrt auf JHR-N805R

@Meins321

Achtung! Bevor der Snapshot geflasht wird. Es ist bekannt, dass so ein Snapshot ohne Webinterface daher kommt und das Webinterface auch nicht nachinstalliert werden kann (kein Platz)?!

Das Updaten auf OpenWRT oder LEDE ist auch nicht wirklich eine Lösung. Der WLAN Treiber ist nicht ausgereift und an entsprechender Stelle findet sich niemand, der die seit Jahren bekannten Bugs austreiben könnte/wollte. Da ist also nicht mehr zu hoffen.

Besser als mit Originalsoftware und Sicherheitslücke wird es mit diesem Ding leider nicht werden…

Hat den N926R eigentlich noch jemand mit der neueren Originalsoftware am laufen?

Ich hatte den so jetzt bestimmt ein halbes Jahr als einfacher AP hinter SP Hybrid im Einsatz und war mit der ChinaFW zufrieden. Nur nimmt der N926R mein selbst vergebenes Passwort plötzlich nicht mehr an, läuft aber ansonsten völlig unauffällig vor sich hin. Schon komisch…

In den Kommentaren oben steht drin, dass die Original-FW massive Sicherheitslücken hat. Bist Du sicher, dass Du noch Herr über das Gerät bist?

1 „Gefällt mir“

Naja. Das Ding sitzt ja hinter der Firewall des Speedport Hybrids. Dann müsste der Angriff von intern gekommen sein/irgendein Rechner infiziert.

Die Lücke, die ich gefunden habe, ist in der Tat von außen nicht direkt angreifbar, weil sie in der Web-Oberfläche des Routers klafft, die nur aus dem internen Netz erreichbar ist. Eine entsprechend manipulierte Webseite könnte aber durchaus einen Browser im internen Netz dazu bringen, den HTTP-Request an den Router zu schicken, der dann dessen Firmware durch ein manipuliertes Exemplar überschreibt.

Der N926R läuft bei mir übrigens seit Monaten stabil als Accesspoint, den ich immer mal wieder auf die neueste Version von OpenWRT bzw. LEDE hochziehe. Das Problem mit den WLAN-Ausfällen ist schon länger nicht mehr aufgetreten und im Nachhinein scheinen mir das eher Ausfälle des WLAN-Treibers meines schon etwas in die Jahre gekommenen Notebooks gewesen zu sein.

Auch ein N805R läuft im Bekanntenkreis jetzt schon länger klaglos als AP, allerdings ohne LuCI und mit abgespeckter Konfig (Build und Laufzeit), um den RAM-Bedarf zu minimieren.

1 „Gefällt mir“

Ich hatte danach die LEDE 17.01.1 installiert. Da ich momentan kein relayd benötige, einfach das fertige Release und nicht per Imagebuilder.

Die lief für unsere Smartphones/Tablets eigentlich ganz gut. Im Log gab es keine Treiberfehler über die Zeit. Ganz gut, weil die WLAN Performance immer noch nicht so richtig den Hybrid Anschluß ausnutzt, wenn der Sender dann mal Kapazitäten frei hat. Da kann es hier einen passieren, dass ein paar Speedtests hintereinander über den N926R nur etwa 10k down, Speedtests im Anschluß aber über einen 740n v4 mit Freifunk/l2tp um die 20k down schaffen…

Ich hatte dann zwischendurch auch mal den fossilen Legacy Originaltreiber ausprobiert. Den konnte man total vergessen. Der lief wieder super lahm, so dass die Android Geräte ständig über die obligatorische Connectivität gemeckert haben.

Aber ist egal. LEDE mit 17.01.1 läuft für unsere Smartphones/Tablets hinreichend stabil - nur halt ein bisschen lahm, fürs Surfen mit mobilen Geräten reicht es problemlos aus. Mal schauen, wie sich die 17.01.2 schlägt, auf die ich gerade aktualisiert habe.

Mit der LEDE 17.01.2 hat der N926R hier jetzt nach knapp 2 Wochen Laufzeit, aber 2-3 Mal stromlos (Gewitter), seine WLAN AP Funktion eingestellt. Da hilft auch kein Reboot oder kurz stromlos.

Windows PCs verbinden sich und bekommen noch eine IP zugewiesen - mehr nicht, nicht mal Zugriff aus WebIf per WLAN möglich. Android Geräte können sich nicht mal mehr verbinden. Die WLAN Verbindung für RX/TX steigt dabei nicht über den 1stelligen Bereich hinaus. Der Syslog meldet nur fehlgeschlagene Verbindungsversuche, keine konkreten Fehler.

Wird dagegen auf den Legacy WLAN Treiber umgeschaltet, so funktioniert das WLAN sofort wieder.

Ich hätte zwar noch die beiden anderen N926R zum Gegentesten. Aber so langsam habe ich die Lust an den N926R verloren. Ich bin immer wieder überrascht, wenn ich hier lese, dass andere den N926R ohne Probleme einsetzten können. Ihr Glückspilze :smile:

1 „Gefällt mir“

Moin, ich scheitere etwas daran mir ein Image für den 926 mit luci zu bauen. Kann mir da jemand aushelfen?

Ich buddel mal diese Diskussion wieder aus der Versenkung heraus. Falls noch andere Nutzer einen der drei JCGs einsetzten, so sollte sich ein Update auf OpenWRT 18.06.4 lohnen.

In den letzten Monaten konnte man im WWW eine Diskussion verfolgen, den buggy rt2x00 WLAN Treiber zu fixen. Diese Aktivitäten waren wohl so erfolgreich, dass zwei Bugfixes dazu in den OpenWRT Releasechannel eingeflossen sind.

Ich jedenfalls habe jetzt einen meiner 926 wieder herausgekramt und gebe ihn eine zweite Change. Mal schauen, wie sich der 926 mit hoffentlich verbesserter WLAN Stabilität als WDS Client macht (den Aufwand selber zu bauen für RelayD Support mache ich mir mittlerweile nicht mehr und nutze ‚nur‘ WDS). Gut, dass ich meine 3x 926 doch nicht ins Recyling gegeben habe.

2 „Gefällt mir“

Ich habe meine 10 Stück „N805R“ noch in einer Kiste… aber die Perspektive da nur 16MB RAM vorzufinden motiviert mich nicht, die anzufassen… das ist selbst für einen reinen AP schon zu wenig. Und 1x1 ist auch nicht das, womit man heute noch Airtime verschwenden möchte.

Die erste Begeisterung ist schon wieder verflogen zum 926 mit 18.06.4. Bis gestern Abend lief der 926 gut als normaler WDS Client durch. Dann habe ich den 926 neu gestartet und das wars. Einstellungen verschwunden. Sysupdate neu geflasht, konfiguriert, reboot per Klick, Einstellungen wieder vergessen. Und angeblich sind knapp über 13MB laut Luci fürs Installieren von Software frei. Schön wäre es ja.

Update:

Ich habe gerade mal solange geflasht, bis eine Release Version funktioniert hat. Es sind bei mir alle 18er OpenWRT Versionen betroffen, ab RC1. Also bis Lede 17.01.7 funktioniert es noch.

n926r-18.06.0-rc1_defekt_startet.txt (1,8 KB) n926r-17.01.7_noch_ok.txt (1,8 KB)

Dann solltest Du ein Issue dazu aufmachen bei openwrt.
Es geht ja nicht nur um „Parameterverlust bei sysupgrade“, sondern auch um „Parameterverlust bei reboot“.

Das sollte nicht nötig sein. Da das Gerät nur 4MB Flash besitzt ist das mehr oder weniger das erwartete Verhalten. Siehe auch Report Devices Here With 18.06.0 Provided Image too big to save overlay - Installing and Using OpenWrt - OpenWrt Forum

ok, dann sollte man das Gerät in den Wusel-Thread dort mit hineinschreiben.

Ja. Ist tatsächlich das Platzproblem. Ich habe mir jetzt ein Image compiliert mit dem Üblichen, was man da so laut Wiki weglassen soll und damit läuft es dann. Schade. Ich dachte, jetzt, wo ich von RelayD auf WDS umgestiegen bin, muss man es nicht mehr selber compilieren wegen der 4MB Limitierung.

Anbei auch mein config.seed. Ich frage mich immer, ob ich da in Richtung IPv6 noch mehr streichen könnte. Die OpenWRT Geräte müssens bei mir im Netzwerk nur weiterleiten können. IPv6 vergibt der Speedport Hybrid.

In der von @blocktrron erwähnten Diskussion werden die 3 JCG Geräte auch schon indirekt erwähnt. Ein User schreibt dort, dass laut seiner Erfahrung eigentlich alle 4MB Ramips/rt305x betroffen sein müssen - stimmt wohl.

Das Snapshot ist auf alle Fälle klein genug und läuft out-of-the-box. Man kann daher zur Not auch das Release mit Luci installieren, alles nach Bedarf fertig konfigurieren und am Ende ohne Neustart dann das Snapshot mit Einstellungen beibehalten rüberinstallieren. Funktioniert. Nur steht man dann halt ohne Luci/Webinterface da. Vielleicht für den einen oder anderen Leser hier eine Alternative, der noch mal über diese Router stolpert, sich compilieren oder den ImageBuilder nicht zutraut, aber Konsole schon.

config.seed.txt (980 Bytes)

Update:
Nochmal zur Erinnerung mein Heimnetzsetup:
[1. Speedport Hybrid] <-LAN-> [2. 1043er FF&WDS AP] <-WDS Wifi, -63 dBm (SNR 191 dB) → [3. n926r WDS Client&AP]

Komisch. Solange am n926r bei mir nur Geräte per LAN angebunden werden, läuft der n926r bisher tadellos. Aber geht das gleiche Gerät per WLAN über den AP des n926r online, dann kann man die Verbindung allenfalls für ein bisschen Smartphone gebrauchen. Die Verbindung hat ständig Aussetzter (ping hängt, SSH bricht ab) und die sind auch im Log ersichtlich:

Sun Jul 7 13:15:07 2019 daemon.notice hostapd: wlan0-1: STA-OPMODE-SMPS-MODE-CHANGED 08:3e:8e:… static
Sun Jul 7 13:15:21 2019 daemon.notice hostapd: wlan0-1: STA-OPMODE-SMPS-MODE-CHANGED 08:3e:8e:… off
Sun Jul 7 13:16:01 2019 daemon.notice hostapd: wlan0-1: STA-OPMODE-SMPS-MODE-CHANGED 08:3e:8e:… static
Sun Jul 7 13:16:10 2019 daemon.notice hostapd: wlan0-1: STA-OPMODE-SMPS-MODE-CHANGED 08:3e:8e:… off

Ob das jetzt eine neue Baustelle ist oder der altbekannte Fehler ‚Dropping frame due to full tx queue‘ im neuen Gewand? Wifi überlebt hier jetzt jedenfalls die Last durch einem simplen Speedtest, ein Fortschritt, endlich.

Anbei auch die Wireless vom n926r, für den Fall, dass ich dort einen Fehler gemacht habe.

wirelessn926r.txt (1,1 KB)

1 „Gefällt mir“

Geht es jetzt um den N805R oder den N926R in Deinen letzten Posting?
Wenn letzteres, dann sollten wir den Thread wirklich mal splitten. Oder zumindest umbenennen.

Nicht nötig. Es geht bei mir von den drei JCG-lern um den 926, aber der ist jetzt wieder weggepackt worden. Ist mir einfach zu unzuverlässlich.

Gestern Abend noch mal auf die Idee gekommen, den mal als nur Access Point (per Powerline Adapter) zu nutzen. Da gab es dann zwar auch die `STA-OPMODE-SMPS-MODE-CHANGED Meldung, aber das ist wohl eh nur eine Infomeldung, keine Fehlermeldung, so wie ich die Erklärung dazu verstehe. Jedenfalls scheint die Meldung immer zu kommen, wenn die Kanalbandbreite zwischen 40 und 20 Mhz wechselt sowie Short GI (de-)aktiviert wird.

Zunächst positive Begeisterung, denn plötzlich lief die SSH Session über eine Stunde mit top ohne Abbruch. Die Meldung wurde zwar weiterhin fleissig geloggt, aber dennoch kein SSH Abbruch. So ganz mag der n926r diese Meldung aber doch nicht. Denn die Pingaussetzer treten immer mit so einer Meldung auf.

Also mal auf 20 Mhz reduziert, deutlich weniger Pingaussetzer/Meldungen im Log.

Dann wieder die WDS Clientverbindung aktiviert und Powerline ausgestöpselt. Die Verwunderung war groß. Denn auch jetzt wurde die SSH Verbindung nicht mehr mit dem ersten Auftreten dieser STA… Infomeldung gekappt. Warum sich ein einfaches enable/disable der WLAN Verbindung so positiv ausgewirkt hat, keine Ahnung. Wäre es nicht immer genau mit der ersten Infomeldung aufgetreten, hätte ich vermutet, war die Gegenseite daran Schuld.

Hierbei ist mir noch etwas anderes aufgefallen. Begrenze ich die Bandbreite der WLAN Verbindung auf 20 Mhz, so hält sich die Access Point Verbindung strict an diese Vorgabe. Die Client WDS Verbindung aber wechselt obgleichder 20 Mhz Einschränkung immer noch weiter zwischen 40 und 20 Mhz. Naja. Ist ja nicht weiter schlimm.

Klingt jetzt nach einer deutlichen Verbesserung (der WLAN Treiber läuft zugegeben deutlich verbessert mit den Patches), warum also habe ich den n926r dennoch wieder ausgemustert? Als ich heute Abend von der Arbeit wiedergekommen bin, hatte sich das Gerät komplett aufgehangen. Es leuchtete nur noch die PowerLED. Die WLAN LED und die LAN LEDs waren komplett aus. Also das WLAN war verschwunden und auch kein Zugriff per LAN möglich zwecks Log sichten. Da ich dem WLAN einen abweichenden Namen gegeben hatte und so keine unserer WLAN Geräte am n926r zu der Zeit eingeloggt gewesen sind, hat sich der n926r im Leerlauf komplett aufgehangen.

Da macht es dann auch kein Spaß mehr sich weiter mit dem n926r zu beschäftigen.

1 „Gefällt mir“

Hat hier eigentlich noch jemand die JHR Geräte im Einsatz oder sind die mittlerweile auch von euch ausgemustert worden?

Vor ein paar Tagen benötigte ich kurz ein weiteres Openwrt Gerät und wollte nicht extra meine genutze Hardware umflashen.

Also den N926R genommen (es lief darauf ein 19er Snapshot vom Jahresanfang) und die letzte 19.07.03.Stable heruntergeladen. Sysupgrade meckerte gleich, dass die FW nicht zur Hardware passt. Als noch mal sicherheitshalber nachgeschaut, ob ich mich „verladen“ habe und die Checksumme verglichen.

Dann das Sysupgrade mit force eingespielt und wie zu erwarten, der N926R ist tot. Der N926R ist jetzt im Bootloop und reagiert auch nicht mehr auf TFTPD32. Da ich eh noch zwei unbenutze N926R für eigentlich die Tonne habe, habe ich den Brick mal riskiert. Nicht weiter tragisch.

Ist natürlich auch eine Möglichkeit, die veralteten Geräte loszuwerden :slight_smile:

Ach ja. Auf die normale TFTPD32 Herstellerseite wollte mich Firefox nicht lassen. Wäre angeblich eine Virenschleuder?!

Ich hatte damals™ mir welche geholt, aber nachdem es keinen wirklichen Fortschritt gab, harren sie dem nächsten Reshuffle im Keller und werden dann wohl in die eSchrott-Tonne wandern.

Dito, hier liegen auch noch 8 Geräte davon in der Ecke. Ich sollte mal die Lankabel und Netzteile „abbergen“, damit zumindest die genutzt werden.