Firmware für TP-Link TL-WA801ND v5

Technik
1

Hey! Ich bin neu bei Freifunk und würde gerne Freifunk auf meinen vorhandenen Router installieren. Dieser ist jedoch nicht in der List der kompatiblen Geräte (es ist ein TP-Link TL-WA801ND v5). Vor ein paar Wochen habe ich aber schon OpenWRT darauf installieren können… Das Hauptproblem an der Hardware-Version 5 ist, dass die mitgelieferte Firmware nur die Installation signierter Firmwares zulässt und man deshalb OpenWRT nur per TFTP drauf bekommt. Wenn OpenWRT aber einmal läuft, kann man ja aus OpenWRT heraus eine neue Firmware aufspielen. Gibt es da realistische Chancen, dass ich den Router für Freifunk nutzen kann, oder soll ich es lieber lassen?

Die Hardware ist ein MediaTek MT7628AN. Habt ihr irgendwo auch einen Image-Download nach Hardware und nicht nach Router-Modell? Oder eine Anleitung, wie man vorgehen muss, wenn man Freifunk “from scratch” installieren möchte? Also ohne auf ein fertiges Image zurückzugreifen?

2

Ohne mich mit den Details von Gluon auszukennen, die OpenWRT Seite zum WA801 gibt an, dass es für die v5 noch keine stabile Firmware gibt. Da OpenWrt dafür auch nur von Hand gebaut werden kann, befürchte ich du musst mit Gluon bzw. der FFRN Firmware das selbe versuchen.

3

Hey. Also wäre die Anleitung folgende:

Firmware aus dem Repo klönen, analog zu OpenWRT kompilieren und dann einfach drauf-döngeln?

Kann ich gerne mal probieren. Wo dokumentiere ich das am besten? Hier im Forum?

4

Ich habe vor Ewigkeiten mal ein paar Firmwares für FFRN gebaut, hier sind noch einige Fragmente von unserer Diskussion damals. Vielleicht hilft Dir das:

https://forum.ffrn.de/t/workaround-841n-load-neustart-problem/1167/77?u=tobox

5

Vielen Dank an tobox!

@joker: den release dates nach sollte ich mich eher an die beiden Repos site-ffrn und gluon halten.

Ist denn die Version 2016.1.3 immernoch aktuell, oder kann ich mir inzwischen die 2016.1.5 bauen?

6

Nein, das ist zu alt glaube ich. Ich vermute, Du musst den Branch V.1.2.x von site-ffrn nehmen, und dann von dort aus das original gluon (nicht den ffrn fork). Sicher bin ich mir aber nicht mehr, hat vielleicht @NurticVibe einen Tipp?

https://github.com/Freifunk-Rhein-Neckar/site-ffrn/tree/ffrn-v.1.2.x

7

OK. Also V.1.2.x zusammen mit freifunk-gluon v2018.1.2? Tut mir leid, dass mich das mit den Versionen von Gluon und site-ffrn etwas verwirrt…

8

Im ersten Schritt würde ich mal versuchen, die Originalfirmware nachzubauen, also auf Basis von Gluon 2017.1.8.

Sobald dass dann funktioniert, kannst Du versuchen, es mit einer neueren Gluon-Versioin zu machen.

9

Vielen Dank. Habe es gerade versucht zu kompilieren. Es scheint aber ein grundlegendes Problem mit dem Router zu geben.

Falls es jemanden interessiert, wie man die Firmware prinzipiell baut:

git clone -b v2017.1.8 https://github.com/freifunk-gluon/gluon.git
git clone -b ffrn-v.1.2.x https://github.com/Freifunk-Rhein-Neckar/site-ffrn.git
cd gluon
ln -s ../site-ffrn site
vi ../site-ffrn/modules

Hier habe ich Zeile 6 von PACKAGES_FFHO_REPO=git://github.com/FreifunkHochstift/ffho-packages.git auf PACKAGES_FFHO_REPO=https://github.com/FreifunkHochstift/ffho-packages.git ändern müssen. Könnte aber auch daran liegen, dass ich hinter einem Proxy bin.

make update
make GLUON_TARGET=ramips-mt7628

Der letzte Schritt funktioniert nicht, weil die Architektur nicht gültig sei. Für andere, gültige Architekturen, wie etwa ramips-mt7621 kompiliert er es aber durch. Wenn man in der targets/targets.mk nachsieht, findet man dort den folgenden Hinweis:

$(eval $(call GluonTarget,ramips,mt7628)) # BROKEN: No AP+IBSS support

Beziehungsweise in der aktuellsten Version der Datei im GIT:

$(eval $(call GluonTarget,ramips,mt76x8)) # BROKEN: unstable WiFi

Der entsprechende Commit vom 17. September ist mit dem folgenden Kommentar versehen:

The MT76x8 is currently not stable enough for worry-free use with Gluon.
It suffers from reboots in intervals as little as 12 hours or WiFi
freezes for several hours.

It may be unflagged as soon the situation with mt76 got better.

Quelle: https://github.com/freifunk-gluon/gluon/commit/728d1ffdb1a3dd3a6db68770a5bb78e8ae851cd1

Daraus schließe ich, dass der TP-Link TL-WA801ND v5 bis auf weiteres nicht Freifunk-kompatibel ist. Das ist schade, weil OpenWrt eigentlich ganz brauchbar darauf läuft. Das WiFi hatte ich allerdings im Client- und nicht im AP-Modus betrieben.

Vielen Dank aber für eure Tipps! Ohne hätte ich es wohl nicht gefunden bzw. geschafft, so weit zu kommen. Falls mir jemand kompatible Hardware bereitstellen oder günstig verkaufen kann, würde ich diese weiterhin gerne aufstellen; kann einen Standort am Marktplatz in der Heidelberger Altstadt anbieten. Ansonsten würde ich auf neure Firmware warten, die ramips-mt76x8 zuverlässig unterstützt.

2 „Gefällt mir“
10

Danke für das Dokumentieren des Scheiterns. Das machen viele Leute nicht, es ist aber trotzdem super hilfreich!

Viel Glück weiterhin - dann halt mit kompatibler Hardware.

2 „Gefällt mir“
11

Habe heute nochmal das Repo gecheckt; Gluon scheint seit v2018.2 vom 29.12.2018 auch auf ramips-mt76x8 zu laufen: https://github.com/freifunk-gluon/gluon/commit/a6bce7959dc9a051d3ba0bbefd8d8ec652c85600

Ich habe nun folgendermaßen kompiliert:

git clone -b v2018.2 https://github.com/freifunk-gluon/gluon.git
git clone -b ffrn-v.1.2.x https://github.com/Freifunk-Rhein-Neckar/site-ffrn.git
cd gluon
ln -s ../site-ffrn site
vi ../site-ffrn/modules

Hier habe ich Zeile 6 von PACKAGES_FFHO_REPO=git://github.com/FreifunkHochstift/ffho-packages.git auf PACKAGES_FFHO_REPO=https://github.com/FreifunkHochstift/ffho-packages.git ändern müssen. Könnte aber auch daran liegen, dass ich hinter einem Proxy bin.

Schließlich:

make update
make GLUON_TARGET=ramips-mt76x8

Das so erstellte Sysupgrade-Image habe ich jetzt auf den Router geflasht (vie OpenWRT) und die Lämpchen blinken alle munter. Leider komme ich aber nicht weiter. Was ich versucht habe, ist, ein Laptop per Netzwerkkabel anzuschließen und auf 192.168.1.1 zu kommen. Der Rechner bekommt aber leider keine IP zugewiesen und auch eine fixe Vergabe einer Adresse erlaubt es nicht, auf den Router zu kommen. Ein Freifunk-WLAN sehe ich leider auch nicht.

Da es sich um einen Access Point handelt, habe ich nur eine Netzwerkbuchse und keine klassische Trennung in WAN und LAN1-4, lese aber überall, dass es wichtig sei, LAN1 und nicht WAN zu verwenden. Ist das Image nicht lauffähig, oder mache ich bei der Bedienung etwas falsch? Sollte ersteres der Fall sein, würde ich OpenWRT via TFTP wieder zurückflashen.

12

Update: Wenn ich die selbst kompilierte Gluon-Firmware via TFTP flashe, scheint das Gerät nicht mehr zu funktionieren (alle LED blinken nach dem Einschalten im Gleichtakt und das Gerät lässt sich weder per Ethernet noch per Wifi erreichen). Ich würde also sagen, dass das Problem das Image ist. Wenn ich das gleiche Image über das Webinterface von OpenWRT flashe, scheint das Gerät den LEDs nach noch irgendwas zu machen, es könnte aber sein, dass dies die Reste vom teilweise funktionierenden OpenWRT sind. Schließlich hat das Gerät 8 MB internen Speicher und das OpenWRT-Image hat auch 8 MB, während das Gluon-Binary ist nur 4 MB groß ist. OpenWRT lässt sich natürlich jederzeit via TFTP wieder zurückflashen.

Was für mich als Frage offen bleibt, ist, ob das Image nicht funktioniert, weil ich es nicht richtig kompiliert habe (zum Beispiel weil die site-ffrn-Version nicht zur Gluon-Version passt), oder ob das Problem wirklich die inkompatible Hardware ist. Wenn sich da vielleicht jemand zu äußern könnte, der schon versucht hat, Gluon 2018.2 mit site-ffrn selber zu bauen?

13

Wow!
Vielen Dank für das riesige Technische Feedback.
Eigentlich sollte im Nightly Branch immer jedes Target (egal ob Broken oder nicht) gebaut werden. Habe hier einen Fehler behoben und das Image wieder lauffähig gemacht.
Die Firmware wird heute Nacht hochgeladen.

Folgende Target werden gebaut:

  • ar71xx-generic
  • ar71xx-tiny
  • ar71xx-nand
  • brcm2708-bcm2708
  • brcm2708-bcm2709
  • mpc85xx-generic
  • ramips-mt7621
  • sunxi-cortexa7
  • x86-generic
  • x86-geode
  • x86-64
  • ipq40xx
  • ramips-mt7620
  • ramips-mt76x8
  • ramips-rt305x
  • ar71xx-mikrotik
  • brcm2708-bcm2710
  • ipq806x
  • mvebu-cortexa9
14

Vieeelen Dank für die Antwort und den Hinweis auf die Nightlys online.

Also ich habe nochmal weiter zu dem Thema recherchiert und es scheint so zu sein, dass Gluon noch nicht für den WA801N v5 gepatcht ist. In Darmstadt scheint aktuell etwas Entwicklung in Richtung des Targets ramips-mt76x8 zu geben. Habe mir die Commits für den Archer C50 v4 (https://github.com/freifunk-gluon/gluon/commit/1ace3d5bb0acb8c1f7f8261e4b877b2025d270d6) angesehen und da ich mich mit Gluon und Freifunk garnicht auskenne, übersteigt das etwas meine Fähigkeiten, fürchte ich. Ich hatte angenommen, dass es überschaubar sei, Gluon zu kompillieren, wenn es ein funktionierendes OpenWRT für das gleiche Gerät gibt.

Gerne würde ich mein Gerät einem Entwickler zur Verfügung stellen, um Gluon darauf ans Laufen zu bringen. An wen wende ich mich da am besten? Soll ich dazu direkt die Darmstädter kontaktieren, die sich auch mit dem Archer beschäftigt haben? Oder gibt es auch hier in der Region Leute, die sich mit der Gluon-Entwicklung/Hardware beschäftigen und Interesse hätten?

15

Inzwischen gibt es einen Nightly für den TP-Link TL-WA801ND v5. Begeistert habe ich das Image heruntergeladen und geflasht! Es freut mich, endlich die Hardware zu haben, um bei Freifunk mitmachen zu können! In die Konfiguration bin ich auch gekommen und ich habe die Konfiguration fertig abgeschlossen und den neuen Knoten registriert. Zuerst habe ich es mit einem privaten WLAN parallel probiert. Dieses hat einwandfrei funktioniert und darüber kam ich ins Internet. Das „freifunk-rhein-neckar.de“-WLAN sehe ich auch, komme darüber aber leider nicht ins Internet. Daraufhin habe ich das private WLAN wieder deaktiviert und das WAN-bridging aktiviert. Aber auch das hat, trotz einiger Wartezeit, das Problem leider nicht behoben. Da es sich bei dem Gerät um einen Access Point handelt, ist nur ein Ethernet-Port vorhanden; kann das mit dem Problem zusammenhängen? Habt ihr Tipps, wie ich das Problem diagnostizieren kann?

1 „Gefällt mir“
16

Nevermind. Inzwischen läuft alles wie gewünscht. Ich habe zum Debuggen Logging via rsyslog aktiviert. Das Problem lag in der DNS-Auflösung. Ich hatte angenommen, dass es mit statischer IP reicht, das Standardgateway anzugeben, wenn dieses auch als DNS-Server fungiert. Dem war aber nicht so; der Hilfetext hatte mich in die Irre geführt. Ich habe es jetzt mit statischen DNS-Servern eingerichtet und es läuft sogar mit privatem WLAN parallel. Wichtig anzumerken ist noch, dass es tatsächlich nur funktioniert, wenn man WAN-Bridging (also Mesh über WAN) aktiviert und dass dies entgegen dem Infotext sehr wohl in Kombination mit einem privaten WLAN funktioniert.

1 „Gefällt mir“
17

Schön wenn es nun funktioniert :+1:

Das verstehe ich jetzt nicht so ganz. Du hast ja (wie du schreibst) nur einen WAN Port an dem Gerät. Dort musst du ja (wenn du nicht per WLAN oder Kabel meshen möchtest) dein LAN anschließen. Und dementsprechend sollte da doch eigentlich kein Mesh auf dem Port sein. :thinking: Gerade auch wenn du die „Privates WLAN“ Funktion nutzen möchtest.

Jetzt mal unter der Annahme das der eine Port an dem TL-WA801ND v5 der WAN Port ist.

1 „Gefällt mir“
18

Hm. Da hast Du natürlich recht. Habe gerade nochmal in die Konfiguration geschaut und es Mesh über WAN war tatsächlich deaktiviert. Hm. Dann weiß ich leider tatsächlich nicht, was beim vorletzten Test dazu geführt hatte, dass die FFRN Server laut Log nicht erreichbar waren. Also Korrektur: Es läuft wunderbar mit Mesh über WAN deaktiviert. Ob der einzige Ethernet-Anschluss WAN oder LAN ist, weiß ich leider nicht.

2 „Gefällt mir“