TP-Link WR841N: RAM und Flash aufrüsten

Der PR bezieht sich doch aber auch auf „unaufgerüstete“ 841er.
Ein erfolgreicher PR für Gluon für (Flash-) aufegrüstete 841er wäre mich eigentlich wesentlich lieber und würde vor allem auch zum Thema dieses Threads besser passen.

@adorfer
Mir ging es um den ath79-Support bei OpenWrt, das wurde ja ganz oben auch aufgeworfen.
Irgendwann wird ja auch Gluon dann umsteigen, und dann braucht auch Gluon diesen Support.

Zwecks gluon-Implementierung kann ich nicht weiterhelfen. Wenn jemand dafür einen v10 braucht, kann ich die Spende aber gerne weiterschicken.

(Ich habe gerade meine Off-Topic-Beiträge, die jetzt ohnehin irrelevant sind, gelöscht).

I fand die Fragestellung, ob der WR841N v12 in Deutschland verkauft wurde, interessant.

Unter den > 5000 Knoten im Freifunk Münsterland finden sich derzeit 11 Stück des WR841N/ND v12. Er ist also wirklich ziemlich selten.
https://karte.freifunk-muensterland.de/map/

Von einer auf alle Communitys zu schließen ist aber auch nicht das gelbe vom Ei.

Bei FFMUC sind es vier WR841N/ND v12 bei circa 1800 Knoten.

Freifunk Münsterland hat ca. 10,6% aller Knoten weltweit, dürfte daher schon eine gewisse Aussagekraft haben.

Da wir ja nun bereits vor vielen Wochen erfolgreich entsprechende v12 organisieren konnten für eine technische Analyse von Umbau/OpenWRT-Target:

  1. warum siehst Du Ausagekraft von Münsterland anders als die von München?
    Münsterland hat 2,2 Promill, München 2,22 Promill 841v12).
    Geht es Dir um die Nachkommastellen? Angesichts der unscharfen Basisgröße („bei über 5000“/„ca. 1800 Knoten“) ist das nun wirklich nicht mathematisch scharf.
    Oder war es schlicht die Aussage, noch einmal festzustellen, dass es keiner Werte aus München bedarf, wenn man schon bessere aus dem Münsterland hat?

  2. Was ist der Takeaway dieser Diskussion heute?
    Wenn wir also feststellen sollten, dass 841V12 nicht in Deuschland verkauft worden ist (lies: „keine EU-Inverkehrbringung in Deutschland“), sondern es sich z.B. ausschließlich um Importe z.B. aus dem polnischen Markt handeln sollte: Welche Auswirkungen hätte das für unsere Flash-Aufrüstungen?
    Was müsste dann beachtet oder gar anders gemacht werden?

Hast Du meine Einleitung gelesen?
Es geht nicht darum Hardware für einen Test zu beschaffen. Das ist, wie Du richtig schriebst, bereits erledigt.
Es geht darum zu sehen, wie häufig der Router wirklich ist, also eher für die Statistik-Interessierten bzw. Planer unter uns.
Ich habe auf @Tarnatos geantwortet, und die Aussage von @awlnx nicht bewertet - das hätte ich kenntlich machen können…

Münsterland und München entsprechen ca. 15 % der weltweiten Router im Freifunk-Netz. Zusammen kommen wir auf 15 Exemplare. Der Router ist in der Hardware-Version also recht selten.

Eine Schlussfolgerung daraus wurde nicht gegeben.

Takeaway:
Das hilft uns, bei aufkommenden Problemen, uns auf die richtigen Router / Hardware-Versionen zu konzentrieren - da wo der Effekt für die Community am größten ist. (Unsere Freizeit dürfte stark limitiert sein, daher ist es gut den Fokus zu behalten).

PS:
Du schreibst viel, schnell und oft mit sehr breitem und tiefen Wissen - das gefällt mir. Ich würde mich freuen, wenn Deine nächsten Beiträge freundlicher und positiver werden.

1 Like

Daher fragte ich nach der Intention, was denn der „interesannte Aspekt“ sein könnte.

Wo siehst Du das Einsparpotential den 841v12 bei den Upgrade-Aktionen explizit „auszusparen“, also für das Gerät keine Aufrüstung anzubieten (also z.B. in den zu definierenden Target-Zeilen) nicht mit einzubauen?
Platz-Einsparung auf den Download-Servern? Zeiteinsparung im Build-Prozess? Übersichtleres Target-File?
Nach meiner Auffassung frisst es gar nicht genug Brot, um sich darüber überhaupt Gedanken zu machen.

Ich versuche zu verstehen, was Dein konkreter Vorschlag ist und eben nicht zwischen den Zeilen zu interpretieren.

In Ddorf sind es 2 841v12 von 668. Ich kenne die Aufsteller, ich frage mal, wo sie sie her haben… :slight_smile:

2 Likes

Die modifizierten u-boot Sourcen auf github wollten gestern nicht compilieren während die alten pepe2k Sourcen sauber bauten.
Du hast 'nen #PR als Fix. Kleine Änderungen im Makefile und Kosmetisches im build-all.sh ansonsten im fetched repo

3 Likes

Hallo alladin,

danke für deine Hilfe.
Ich habe etwa 50 commits hier rumliegen für WR940N v3, Telnet, DHCP-Server und unzählige kosmetische Änderungen. Leider bin ich noch nicht dazu gekommen, die aufzuräumen und zu committen. Deinen PR muss ich mir noch genauer angucken. Wenn ich die Änderungen gepusht habe, gebe ich Bescheid und stelle neue Images bereit.

Lieben Gruß,

Vincent

4 Likes

genieß den #PR mit Vorsicht - ich habe nur geschrieben, der compiler läuft dann durch - Assembler war noch nie eine meiner Stärken ;D

leider nur generische Antworten Amazon… keine Herkunftsinfos verfügbar

Habe seit gestern einen lauffähigen Patch für die 841er v8 v9 v10 und v11 für ath79.
Hab die auch schon auf nem v9 und v11 getestet und an sich keine Probleme festgestellt.
Upgrade geht auch zum teil, nur bleibt das WLAN auf der strecke weil sich der device path durch ath79 ändert.
Leider habe ich nicht dafür die Fähigkeiten ne Lösung zu bauen. Ist aber denke ich das selbe Problem, dass alle anderen Geräte beim Upgrade auf ath79 haben werden und somit wird es hoffentlich seitens gluon ne Lösung geben die man adaptieren kann.
Wer es mal ausprobieren möchte (muss allerdings noch supported devices korrigiert einpflegen, damit ein upgrade ohne force klapt, lokal hab ich das bereits drin):

Sollte auch nicht schwer sein weitere Geräte (z.B. TL-WR940N) einzubauen. Würde ich aber erst angehen, sobald @CodeFetch u-boot dafür fertig hat.

Update: Patch ist nun fertig in meinem git!

Update2: Script, damit die nahtlose Migration auf ath79 von ar71xx läuft, ist nun auch drin. Muss ich nur noch einmal auf allen Versionen testen.

6 Likes

Update2: Script, damit die nahtlose Migration auf ath79 von ar71xx läuft, ist nun auch drin. Muss ich nur noch einmal auf allen Versionen testen.

Der Code für die wmac Migration, der schon ewig im Master liegt, wurde heute auch in 19.07 gebackportet, falls das hierfür was nützt.

2 Likes

Tatsache, habe den commit bereits im Patch. Für Gluon 2020.1 reichts leider nicht mehr aber danach (evtl. 2020.1.1) kann ich dann wohl den Commit im Patch wieder rauslassen.
Deckt aber v8-v11 ab.

2 Likes

Habe die Migration mit dem ATH79 Patch jetzt getestet. V9-V11 laufen wunderbar weiter. Für V8 ist noch Arbeit nötig. WLAN wurde zwar migriert aber Ethernet und LEDs stimmer nicht mehr huntertprozentig, wobei Mesh on Lan grad garnicht will.

1 Like

Für die LED migration bitte nen PR machen und das Äquivalent zu diesem File mit den entsprechenden Einträgen für tiny erstellen:


Ich porte das dann ggf. auch für 19.07 zurück.

Die Ethernet Migration ist im Moment ungelöst und Gegenstand konzeptioneller Diskussionen:
http://lists.infradead.org/pipermail/openwrt-devel/2020-January/021339.html

1 Like

Werd ich mir mal ansehen. Das mit Ethernet ist ärgerlich. Aber ich verstehe die Diskussion. Dann werd ich wohl mit 2020.1 erstmal v9-v11 migrieren und v8 mit ar71xx weiterlaufen lassen bis es da eine gute Lösung gibt.