[1/1] ramips/mt76x8: Add support for TPLINK TL-WR841Nv13

Submitted by Dominik Heidler on April 9, 2020, 10:26 p.m.

Details

Message ID 20200409222644.4661-2-dominik@heidler.eu
State Superseded
Headers show

Commit Message

Dominik Heidler April 9, 2020, 10:26 p.m. 
From: Dominik Heidler <dheidler@gmail.com>

Signed-off-by: Dominik Heidler <dominik@heidler.eu>
---
 bsp/board_mt76x8.bsp                          |  6 ++++
 bsp/mt76x8/.config                            | 29 +++++++++++++++++++
 .../files/etc/uci-defaults/15-fff-boardname   |  3 ++
 .../fff-network/ramips/network.tl-wr841-v13   |  9 ++++++
 4 files changed, 47 insertions(+)
 create mode 100644 bsp/board_mt76x8.bsp
 create mode 100644 bsp/mt76x8/.config
 create mode 100644 src/packages/fff/fff-network/ramips/network.tl-wr841-v13

Patch hide | download patch | download mbox 

diff --git a/bsp/board_mt76x8.bsp b/bsp/board_mt76x8.bsp
new file mode 100644
index 0000000..bf8d236
--- /dev/null
+++ b/bsp/board_mt76x8.bsp
@@ -0,0 +1,6 @@ 
+machine=mt76x8
+chipset=ramips
+subtarget=mt76x8
+images=("openwrt-${chipset}-${subtarget}-tplink_c50-v3-squashfs-sysupgrade.bin"
+        "openwrt-${chipset}-${subtarget}-tl-wr841n-v13-squashfs-sysupgrade.bin"
+        )
diff --git a/bsp/mt76x8/.config b/bsp/mt76x8/.config
new file mode 100644
index 0000000..c908b98
--- /dev/null
+++ b/bsp/mt76x8/.config
@@ -0,0 +1,29 @@ 
+# Generated using "./buildscript config openwrt".
+# Do no edit manually
+#
+CONFIG_TARGET_ramips=y
+CONFIG_TARGET_ramips_mt76x8=y
+CONFIG_TARGET_MULTI_PROFILE=y
+CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tplink_c50-v3=y
+CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tplink_c50-v3=""
+CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tl-wr841n-v13=y
+CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tl-wr841n-v13=""
+CONFIG_BUSYBOX_CUSTOM=y
+CONFIG_TARGET_PER_DEVICE_ROOTFS=y
+# CONFIG_BUSYBOX_CONFIG_BRCTL is not set
+# CONFIG_BUSYBOX_CONFIG_CROND is not set
+# CONFIG_BUSYBOX_CONFIG_CRONTAB is not set
+# CONFIG_BUSYBOX_CONFIG_FEATURE_FAST_TOP is not set
+# CONFIG_BUSYBOX_CONFIG_FEATURE_NTPD_SERVER is not set
+CONFIG_CLEAN_IPKG=y
+# CONFIG_DROPBEAR_CURVE25519 is not set
+# CONFIG_FASTD_ENABLE_CIPHER_SALSA2012 is not set
+# CONFIG_FASTD_ENABLE_MAC_GHASH is not set
+# CONFIG_FASTD_ENABLE_MAC_UHASH is not set
+# CONFIG_FASTD_ENABLE_METHOD_COMPOSED_GMAC is not set
+# CONFIG_FASTD_ENABLE_METHOD_COMPOSED_UMAC is not set
+# CONFIG_FASTD_ENABLE_METHOD_GENERIC_GMAC is not set
+# CONFIG_FASTD_ENABLE_METHOD_GENERIC_UMAC is not set
+# CONFIG_PACKAGE_ALFRED_VIS is not set
+CONFIG_PACKAGE_opkg=m
+CONFIG_STRIP_KERNEL_EXPORTS=y
diff --git a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-boardname b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-boardname
index a96c05a..5213c1e 100644
--- a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-boardname
+++ b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-boardname
@@ -29,6 +29,9 @@  case "$BOARD" in
         BOARD=tl-wr841-v11
         grep "v12" /var/sysinfo/model && BOARD=tl-wr841-v12
         ;;
+    tl-wr841n-v13)
+        BOARD=tl-wr841-v13
+        ;;
     nanostation-m)
         BOARD=ubnt-nano-m
         ;;
diff --git a/src/packages/fff/fff-network/ramips/network.tl-wr841-v13 b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
new file mode 100644
index 0000000..bd33c1f
--- /dev/null
+++ b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
@@ -0,0 +1,9 @@ 
+PORTORDER="4 3 2 1"
+
+WANDEV=eth0
+SWITCHDEV=eth0
+CLIENT_PORTS="6t 3 4"
+WAN_PORTS="6t 0"
+BATMAN_PORTS="6t 1 2"
+
+ROUTERMAC=$(cat /sys/class/net/eth0/address)

Comments

Adrian Schmutzler April 11, 2020, 9:44 p.m. 
Hallo Dominik,

zunächst vorab:

Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support für ein 4/32-Gerät hinzuzufügen.

Das mt76x8-(Sub)target hat zudem kein "small_flash" in OpenWrt aktiviert, d.h. bestimmte direkt in den Kernel eingebaute Features, die bei ar71xx-tiny deaktiviert werden, sind hier noch vorhanden, und machen das Image größer. Zudem hat man hier für ein einzelnes 4/32-Gerät dann einen Sonderfall, um den man sich nochmal extra kümmern muss, wenn es darum geht, Support für diese Geräte generell zu erhalten.

Selbst wenn das Gerät jetzt (offensichtlich) noch unterstützt werden kann, sendet dies in meinen Augen das falsche Signal aus.
Außerdem gibt es schon länger einen v14, wir unterstützen hiermit also nicht mal die "aktuellste" Version.

Ich werde den Support deshalb nicht blockieren, wenn jemand anderes dies als sinnvoll erachtet. Ich wollte nur meine Bedenken äußern.

Nun zum Content:

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
> Of Dominik Heidler
> Sent: Freitag, 10. April 2020 00:27
> To: franken-dev@freifunk.net
> Cc: Dominik Heidler <dheidler@gmail.com>
> Subject: [PATCH 1/1] ramips/mt76x8: Add support for TPLINK TL-WR841Nv13

"TP-Link TL-WR841N v13"

Ich will hier jetzt nicht auf der Commit Message rumreiten, für den speziellen Fall der Mediatek-Geräte wäre es aber erstrebenswert, hier "Flashing instructions" mit einzubauen; man muss zwar scheinbar nur TFTP verwenden, aber es ist dennoch eine gewisse Abweichung vom gewohnten WebUI-Flashing, daher würde ich das an der Stelle highlighten. Für meinen Geschmack würde es reichen, einfach die Flashing-Instruktionen vom OpenWrt-Commit hier reinzukopieren:

https://github.com/openwrt/openwrt/commit/24043a0d2e01b9843c0dc529205b3b0bc7ecbbf9

> 
> From: Dominik Heidler <dheidler@gmail.com>
> 
> Signed-off-by: Dominik Heidler <dominik@heidler.eu>

Die Mail-Adressen für Author und Signed-off sind unterschiedlich. Das ist für uns zwar wurscht, aber FYI. (Bei OpenWrt müssten die gleich sein.)

> ---
>  bsp/board_mt76x8.bsp                          |  6 ++++
>  bsp/mt76x8/.config                            | 29 +++++++++++++++++++
>  .../files/etc/uci-defaults/15-fff-boardname   |  3 ++
>  .../fff-network/ramips/network.tl-wr841-v13   |  9 ++++++
>  4 files changed, 47 insertions(+)
>  create mode 100644 bsp/board_mt76x8.bsp  create mode 100644
> bsp/mt76x8/.config  create mode 100644 src/packages/fff/fff-
> network/ramips/network.tl-wr841-v13
> 
> diff --git a/bsp/board_mt76x8.bsp b/bsp/board_mt76x8.bsp new file mode
> 100644 index 0000000..bf8d236
> --- /dev/null
> +++ b/bsp/board_mt76x8.bsp
> @@ -0,0 +1,6 @@
> +machine=mt76x8
> +chipset=ramips
> +subtarget=mt76x8
> +images=("openwrt-${chipset}-${subtarget}-tplink_c50-v3-squashfs-
> sysupgrade.bin"

Das überschneidet sich mit dem C50 v3. Ist aber wurscht, das kann man beim Applien hinbasteln, je nachdem, wer zuerst dran kommt.

> +        "openwrt-${chipset}-${subtarget}-tl-wr841n-v13-squashfs-
> sysupgrade.bin"
> +        )
> diff --git a/bsp/mt76x8/.config b/bsp/mt76x8/.config new file mode 100644
> index 0000000..c908b98
> --- /dev/null
> +++ b/bsp/mt76x8/.config
> @@ -0,0 +1,29 @@
> +# Generated using "./buildscript config openwrt".
> +# Do no edit manually
> +#
> +CONFIG_TARGET_ramips=y
> +CONFIG_TARGET_ramips_mt76x8=y
> +CONFIG_TARGET_MULTI_PROFILE=y
> +CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tplink_c50-v3=y
> +CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tplink_c50-
> v3=""
> +CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tl-wr841n-v13=y
> +CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tl-wr841n-
> v13=""
> +CONFIG_BUSYBOX_CUSTOM=y
> +CONFIG_TARGET_PER_DEVICE_ROOTFS=y
> +# CONFIG_BUSYBOX_CONFIG_BRCTL is not set #
> CONFIG_BUSYBOX_CONFIG_CROND
> +is not set # CONFIG_BUSYBOX_CONFIG_CRONTAB is not set #
> +CONFIG_BUSYBOX_CONFIG_FEATURE_FAST_TOP is not set #
> +CONFIG_BUSYBOX_CONFIG_FEATURE_NTPD_SERVER is not set
> +CONFIG_CLEAN_IPKG=y # CONFIG_DROPBEAR_CURVE25519 is not set #
> +CONFIG_FASTD_ENABLE_CIPHER_SALSA2012 is not set #
> +CONFIG_FASTD_ENABLE_MAC_GHASH is not set #
> +CONFIG_FASTD_ENABLE_MAC_UHASH is not set #
> +CONFIG_FASTD_ENABLE_METHOD_COMPOSED_GMAC is not set #
> +CONFIG_FASTD_ENABLE_METHOD_COMPOSED_UMAC is not set #
> +CONFIG_FASTD_ENABLE_METHOD_GENERIC_GMAC is not set #
> +CONFIG_FASTD_ENABLE_METHOD_GENERIC_UMAC is not set #
> +CONFIG_PACKAGE_ALFRED_VIS is not set CONFIG_PACKAGE_opkg=m
> +CONFIG_STRIP_KERNEL_EXPORTS=y
> diff --git a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
> boardname b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
> boardname
> index a96c05a..5213c1e 100644
> --- a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
> boardname
> +++ b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-board
> +++ name
> @@ -29,6 +29,9 @@ case "$BOARD" in
>          BOARD=tl-wr841-v11
>          grep "v12" /var/sysinfo/model && BOARD=tl-wr841-v12
>          ;;
> +    tl-wr841n-v13)
> +        BOARD=tl-wr841-v13
> +        ;;

Dieses Umbenennen macht für ramips keinen Sinn.
Bei den anderen (ar71xx) 841ern ist der Grund für das Umbennen, dass der Name im Image (tl-wr841-vX) vom board name abweicht (tl-wr841n-vX).
Bei ramips ist das nicht der Fall, sondern der Image-Name ist zum Boardnamen konsistent. Insofern macht es mehr Sinn, hier nicht umzubenennen, und die Inkonsistenz bei unseren Namen in Kauf zu nehmen, anstatt erst hier A nach B zu ändern und bei sysupgrade dann wieder B zu A.

Dabei ist auch zu beachten, dass mit Wechsel von ar71xx auf ath79 und für mt76x8 mit Wechsel zum nächsten OpenWrt-stable Branch die Benennung ohnehin wieder anders ist.

>      nanostation-m)
>          BOARD=ubnt-nano-m
>          ;;
> diff --git a/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
> b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
> new file mode 100644
> index 0000000..bd33c1f
> --- /dev/null
> +++ b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13

Diesen Dateinamen entsprechend anpassen, wenn der board name nicht geändert wird:
-> tl-wr841n-v13

> @@ -0,0 +1,9 @@
> +PORTORDER="4 3 2 1"

Da hier der WAN-Port im Switch integriert ist, muss er mit in die Portliste. Entsprechend deiner Zuordnung unten sollte folgendes richtig sein:

PORTORDER="4 3 2 1 0"

Bisher habe ich (ohne dass dies irgendwo als Regel steht) immer den WAN-Port nach links gesetzt, also:

PORTORDER="0 1 2 3 4"

> +
> +WANDEV=eth0
> +SWITCHDEV=eth0
> +CLIENT_PORTS="6t 3 4"
> +WAN_PORTS="6t 0"
> +BATMAN_PORTS="6t 1 2"
> +
> +ROUTERMAC=$(cat /sys/class/net/eth0/address)

Bei OpenWrt überlappen die MAC-Adressen von &ethernet und &wmac. Damit wir keine kollidierenden MAC-Adressen im Mesh haben, muss daher die ETHMESHMAC ergänzt werden.

Entweder (WAN-Adresse):

. /lib/functions/system.sh
ETHMESHMAC=$(macaddr_add "$ROUTERMAC" 1)

Oder (local bit):

. /lib/functions/system.sh
ETHMESHMAC=$(macaddr_setbit_la "$ROUTERMAC")

Letzteres wurde zuletzt präferiert.

Das mit dem Mesh solltest du unbedingt noch testen. Einfach irgendeinen anderen Router als Uplink nehmen. Früher ging bei bestimmten Mediatek-Chip AP und Mesh nur einzeln, aber nicht gleichzeitig.

Beste Grüße

Adrian

> --
> 2.20.1
Fabian Blaese April 11, 2020, 9:51 p.m. 
Guten Abend,

On 11.04.20 23:44, mail@adrianschmutzler.de wrote:
> Hallo Dominik,
> 
> zunächst vorab:
> 
> Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support für ein 4/32-Gerät hinzuzufügen.
Ich auch nicht, glücklicherweise hat der 841v13 8MB Flash und 64MB RAM. :-)
Der v14 ist dieses eklige Geräte mit 4MB Flash und 32MB RAM, da bin ich genauso der Meinung, dass wir diesen eher nicht unterstützen, und keinesfalls empfehlen sollten.

Gruß
Fabian
Christian Dresel April 11, 2020, 9:55 p.m. 
Hallo Adrian

On 11.04.20 23:44, mail@adrianschmutzler.de wrote:
> Hallo Dominik,
> 
> zunächst vorab:
> 
> Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support für ein 4/32-Gerät hinzuzufügen.

Flash MB: 8
RAM MB: 64

Quelle: https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr841n_v13

Man hat also bei TP-Link dazu gelernt das man für OpenWRT mehr braucht ;)

Gruß

Christian

> 
> Das mt76x8-(Sub)target hat zudem kein "small_flash" in OpenWrt aktiviert, d.h. bestimmte direkt in den Kernel eingebaute Features, die bei ar71xx-tiny deaktiviert werden, sind hier noch vorhanden, und machen das Image größer. Zudem hat man hier für ein einzelnes 4/32-Gerät dann einen Sonderfall, um den man sich nochmal extra kümmern muss, wenn es darum geht, Support für diese Geräte generell zu erhalten.
> 
> Selbst wenn das Gerät jetzt (offensichtlich) noch unterstützt werden kann, sendet dies in meinen Augen das falsche Signal aus.
> Außerdem gibt es schon länger einen v14, wir unterstützen hiermit also nicht mal die "aktuellste" Version.
> 
> Ich werde den Support deshalb nicht blockieren, wenn jemand anderes dies als sinnvoll erachtet. Ich wollte nur meine Bedenken äußern.
> 
> Nun zum Content:
> 
>> -----Original Message-----
>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
>> Of Dominik Heidler
>> Sent: Freitag, 10. April 2020 00:27
>> To: franken-dev@freifunk.net
>> Cc: Dominik Heidler <dheidler@gmail.com>
>> Subject: [PATCH 1/1] ramips/mt76x8: Add support for TPLINK TL-WR841Nv13
> 
> "TP-Link TL-WR841N v13"
> 
> Ich will hier jetzt nicht auf der Commit Message rumreiten, für den speziellen Fall der Mediatek-Geräte wäre es aber erstrebenswert, hier "Flashing instructions" mit einzubauen; man muss zwar scheinbar nur TFTP verwenden, aber es ist dennoch eine gewisse Abweichung vom gewohnten WebUI-Flashing, daher würde ich das an der Stelle highlighten. Für meinen Geschmack würde es reichen, einfach die Flashing-Instruktionen vom OpenWrt-Commit hier reinzukopieren:
> 
> https://github.com/openwrt/openwrt/commit/24043a0d2e01b9843c0dc529205b3b0bc7ecbbf9
> 
>>
>> From: Dominik Heidler <dheidler@gmail.com>
>>
>> Signed-off-by: Dominik Heidler <dominik@heidler.eu>
> 
> Die Mail-Adressen für Author und Signed-off sind unterschiedlich. Das ist für uns zwar wurscht, aber FYI. (Bei OpenWrt müssten die gleich sein.)
> 
>> ---
>>  bsp/board_mt76x8.bsp                          |  6 ++++
>>  bsp/mt76x8/.config                            | 29 +++++++++++++++++++
>>  .../files/etc/uci-defaults/15-fff-boardname   |  3 ++
>>  .../fff-network/ramips/network.tl-wr841-v13   |  9 ++++++
>>  4 files changed, 47 insertions(+)
>>  create mode 100644 bsp/board_mt76x8.bsp  create mode 100644
>> bsp/mt76x8/.config  create mode 100644 src/packages/fff/fff-
>> network/ramips/network.tl-wr841-v13
>>
>> diff --git a/bsp/board_mt76x8.bsp b/bsp/board_mt76x8.bsp new file mode
>> 100644 index 0000000..bf8d236
>> --- /dev/null
>> +++ b/bsp/board_mt76x8.bsp
>> @@ -0,0 +1,6 @@
>> +machine=mt76x8
>> +chipset=ramips
>> +subtarget=mt76x8
>> +images=("openwrt-${chipset}-${subtarget}-tplink_c50-v3-squashfs-
>> sysupgrade.bin"
> 
> Das überschneidet sich mit dem C50 v3. Ist aber wurscht, das kann man beim Applien hinbasteln, je nachdem, wer zuerst dran kommt.
> 
>> +        "openwrt-${chipset}-${subtarget}-tl-wr841n-v13-squashfs-
>> sysupgrade.bin"
>> +        )
>> diff --git a/bsp/mt76x8/.config b/bsp/mt76x8/.config new file mode 100644
>> index 0000000..c908b98
>> --- /dev/null
>> +++ b/bsp/mt76x8/.config
>> @@ -0,0 +1,29 @@
>> +# Generated using "./buildscript config openwrt".
>> +# Do no edit manually
>> +#
>> +CONFIG_TARGET_ramips=y
>> +CONFIG_TARGET_ramips_mt76x8=y
>> +CONFIG_TARGET_MULTI_PROFILE=y
>> +CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tplink_c50-v3=y
>> +CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tplink_c50-
>> v3=""
>> +CONFIG_TARGET_DEVICE_ramips_mt76x8_DEVICE_tl-wr841n-v13=y
>> +CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt76x8_DEVICE_tl-wr841n-
>> v13=""
>> +CONFIG_BUSYBOX_CUSTOM=y
>> +CONFIG_TARGET_PER_DEVICE_ROOTFS=y
>> +# CONFIG_BUSYBOX_CONFIG_BRCTL is not set #
>> CONFIG_BUSYBOX_CONFIG_CROND
>> +is not set # CONFIG_BUSYBOX_CONFIG_CRONTAB is not set #
>> +CONFIG_BUSYBOX_CONFIG_FEATURE_FAST_TOP is not set #
>> +CONFIG_BUSYBOX_CONFIG_FEATURE_NTPD_SERVER is not set
>> +CONFIG_CLEAN_IPKG=y # CONFIG_DROPBEAR_CURVE25519 is not set #
>> +CONFIG_FASTD_ENABLE_CIPHER_SALSA2012 is not set #
>> +CONFIG_FASTD_ENABLE_MAC_GHASH is not set #
>> +CONFIG_FASTD_ENABLE_MAC_UHASH is not set #
>> +CONFIG_FASTD_ENABLE_METHOD_COMPOSED_GMAC is not set #
>> +CONFIG_FASTD_ENABLE_METHOD_COMPOSED_UMAC is not set #
>> +CONFIG_FASTD_ENABLE_METHOD_GENERIC_GMAC is not set #
>> +CONFIG_FASTD_ENABLE_METHOD_GENERIC_UMAC is not set #
>> +CONFIG_PACKAGE_ALFRED_VIS is not set CONFIG_PACKAGE_opkg=m
>> +CONFIG_STRIP_KERNEL_EXPORTS=y
>> diff --git a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
>> boardname b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
>> boardname
>> index a96c05a..5213c1e 100644
>> --- a/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-
>> boardname
>> +++ b/src/packages/fff/fff-boardname/files/etc/uci-defaults/15-fff-board
>> +++ name
>> @@ -29,6 +29,9 @@ case "$BOARD" in
>>          BOARD=tl-wr841-v11
>>          grep "v12" /var/sysinfo/model && BOARD=tl-wr841-v12
>>          ;;
>> +    tl-wr841n-v13)
>> +        BOARD=tl-wr841-v13
>> +        ;;
> 
> Dieses Umbenennen macht für ramips keinen Sinn.
> Bei den anderen (ar71xx) 841ern ist der Grund für das Umbennen, dass der Name im Image (tl-wr841-vX) vom board name abweicht (tl-wr841n-vX).
> Bei ramips ist das nicht der Fall, sondern der Image-Name ist zum Boardnamen konsistent. Insofern macht es mehr Sinn, hier nicht umzubenennen, und die Inkonsistenz bei unseren Namen in Kauf zu nehmen, anstatt erst hier A nach B zu ändern und bei sysupgrade dann wieder B zu A.
> 
> Dabei ist auch zu beachten, dass mit Wechsel von ar71xx auf ath79 und für mt76x8 mit Wechsel zum nächsten OpenWrt-stable Branch die Benennung ohnehin wieder anders ist.
> 
>>      nanostation-m)
>>          BOARD=ubnt-nano-m
>>          ;;
>> diff --git a/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
>> b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
>> new file mode 100644
>> index 0000000..bd33c1f
>> --- /dev/null
>> +++ b/src/packages/fff/fff-network/ramips/network.tl-wr841-v13
> 
> Diesen Dateinamen entsprechend anpassen, wenn der board name nicht geändert wird:
> -> tl-wr841n-v13
> 
>> @@ -0,0 +1,9 @@
>> +PORTORDER="4 3 2 1"
> 
> Da hier der WAN-Port im Switch integriert ist, muss er mit in die Portliste. Entsprechend deiner Zuordnung unten sollte folgendes richtig sein:
> 
> PORTORDER="4 3 2 1 0"
> 
> Bisher habe ich (ohne dass dies irgendwo als Regel steht) immer den WAN-Port nach links gesetzt, also:
> 
> PORTORDER="0 1 2 3 4"
> 
>> +
>> +WANDEV=eth0
>> +SWITCHDEV=eth0
>> +CLIENT_PORTS="6t 3 4"
>> +WAN_PORTS="6t 0"
>> +BATMAN_PORTS="6t 1 2"
>> +
>> +ROUTERMAC=$(cat /sys/class/net/eth0/address)
> 
> Bei OpenWrt überlappen die MAC-Adressen von &ethernet und &wmac. Damit wir keine kollidierenden MAC-Adressen im Mesh haben, muss daher die ETHMESHMAC ergänzt werden.
> 
> Entweder (WAN-Adresse):
> 
> . /lib/functions/system.sh
> ETHMESHMAC=$(macaddr_add "$ROUTERMAC" 1)
> 
> Oder (local bit):
> 
> . /lib/functions/system.sh
> ETHMESHMAC=$(macaddr_setbit_la "$ROUTERMAC")
> 
> Letzteres wurde zuletzt präferiert.
> 
> Das mit dem Mesh solltest du unbedingt noch testen. Einfach irgendeinen anderen Router als Uplink nehmen. Früher ging bei bestimmten Mediatek-Chip AP und Mesh nur einzeln, aber nicht gleichzeitig.
> 
> Beste Grüße
> 
> Adrian
> 
>> --
>> 2.20.1
Adrian Schmutzler April 11, 2020, 10:33 p.m. 
Hallo,

>> Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support für ein 4/32-Gerät hinzuzufügen. 
> Ich auch nicht, glücklicherweise hat der 841v13 8MB Flash und 64MB RAM. :-) 

Fact. Hab mich wohl vom v14 täuschen lassen. Sorry.

> Der v14 ist dieses eklige Geräte mit 4MB Flash und 32MB RAM, da bin ich genauso der Meinung, dass wir diesen eher nicht unterstützen, und keinesfalls empfehlen sollten.

Tatsächlich würde ich in diesem Fall sogar trotzdem eher gegen einen Support des v13 plädieren, da es trotzdem so aussieht, als würden wir "die 841er" plötzlich wieder unterstützen.
Aber die Tendenz ist jetzt natürlich viel schwächer. Ich würde auch dennoch ein Reviewed-by für diesen Patch spendieren, wenn es eine v2 entsprechend den Kommentaren in der letzten Mail gibt.

Beste Grüße

Adrian
Dominik Heidler April 11, 2020, 10:37 p.m. 
Hi,

das mit den kollidierenden MACs habe ich auch schon bemerkt (siehe meine
Kommentare im Matrix Chat).
Ich hoffe, meine neue Version des Patches behebt das Problem.
Ich lasse den Patch einfach mal hier - egal ob er jetzt applied wird
oder nicht - damit mal dokumentiert ist, wie man den Router verwenden kann.

Grüße,
Dominik

Am 12.04.20 um 00:33 schrieb mail@adrianschmutzler.de:
> Hallo,
> 
>>> Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support für ein 4/32-Gerät hinzuzufügen. 
>> Ich auch nicht, glücklicherweise hat der 841v13 8MB Flash und 64MB RAM. :-) 
> 
> Fact. Hab mich wohl vom v14 täuschen lassen. Sorry.
> 
>> Der v14 ist dieses eklige Geräte mit 4MB Flash und 32MB RAM, da bin ich genauso der Meinung, dass wir diesen eher nicht unterstützen, und keinesfalls empfehlen sollten.
> 
> Tatsächlich würde ich in diesem Fall sogar trotzdem eher gegen einen Support des v13 plädieren, da es trotzdem so aussieht, als würden wir "die 841er" plötzlich wieder unterstützen.
> Aber die Tendenz ist jetzt natürlich viel schwächer. Ich würde auch dennoch ein Reviewed-by für diesen Patch spendieren, wenn es eine v2 entsprechend den Kommentaren in der letzten Mail gibt.
> 
> Beste Grüße
> 
> Adrian 
>
Adrian Schmutzler April 15, 2020, 2:16 p.m. 
Hallo,

habe den Patch in meiner Version mit ergänzter Commit Message applied (v3).

Grüße

Adrian

> -----Original Message-----
> From: Dominik Heidler [mailto:dominik@heidler.eu]
> Sent: Sonntag, 12. April 2020 00:37
> To: mail@adrianschmutzler.de; 'Fabian Bläse' <fabian@blaese.de>; franken-
> dev@freifunk.net
> Subject: Re: [PATCH 1/1] ramips/mt76x8: Add support for TPLINK TL-
> WR841Nv13
> 
> Hi,
> 
> das mit den kollidierenden MACs habe ich auch schon bemerkt (siehe meine
> Kommentare im Matrix Chat).
> Ich hoffe, meine neue Version des Patches behebt das Problem.
> Ich lasse den Patch einfach mal hier - egal ob er jetzt applied wird oder nicht -
> damit mal dokumentiert ist, wie man den Router verwenden kann.
> 
> Grüße,
> Dominik
> 
> Am 12.04.20 um 00:33 schrieb mail@adrianschmutzler.de:
> > Hallo,
> >
> >>> Ich finde es nicht unbedingt erstrebenswert, jetzt noch "neu" Support
> für ein 4/32-Gerät hinzuzufügen.
> >> Ich auch nicht, glücklicherweise hat der 841v13 8MB Flash und 64MB
> >> RAM. :-)
> >
> > Fact. Hab mich wohl vom v14 täuschen lassen. Sorry.
> >
> >> Der v14 ist dieses eklige Geräte mit 4MB Flash und 32MB RAM, da bin ich
> genauso der Meinung, dass wir diesen eher nicht unterstützen, und
> keinesfalls empfehlen sollten.
> >
> > Tatsächlich würde ich in diesem Fall sogar trotzdem eher gegen einen
> Support des v13 plädieren, da es trotzdem so aussieht, als würden wir "die
> 841er" plötzlich wieder unterstützen.
> > Aber die Tendenz ist jetzt natürlich viel schwächer. Ich würde auch
> dennoch ein Reviewed-by für diesen Patch spendieren, wenn es eine v2
> entsprechend den Kommentaren in der letzten Mail gibt.
> >
> > Beste Grüße
> >
> > Adrian
> >