| Message ID | 005301d4ea73$d1a42080$74ec6180$@adrianschmutzler.de |
|---|---|
| State | Not Applicable |
| Headers | show |
--- /dev/null +++ b/src/packages/fff/fff-network/ar71xx-generic/network.archer-c7-v5 @@ -0,0 +1,14 @@ +PORTORDER="1 2 3 4 5" + +WANDEV=eth0 +SWITCHDEV=eth0 +CLIENT_PORTS="4 5 0t" +WAN_PORTS="1 0t" +BATMAN_PORTS="2 3 0t" + +# Use WAN-MAC, which is LAN-MAC + 1 +. /lib/functions.sh +. /lib/functions/system.sh + +ROUTERMAC=$(cat /sys/class/net/eth0/address) +ETHMESHMAC=$(macaddr_add $ROUTERMAC 1)
Hallo Adrian. On 04.04.19 01:20, mail@adrianschmutzler.de wrote: > Hallo Fabian, > > Test hat soweit geklappt, auch das Batman über w5mesh scheint zu gehen. > > PORTORDER="1 2 3 4 5" Danke. > Zur ETHMESHMAC: > Die "normale" Aufteilung (Stock-FW) beim C7v5 ist folgende: > 5 GHz LANMAC-1 > 2.4 GHz LANMAC > LAN LANMAC > WAN LANMAC +1 > > Mir würde es daher als sinnvoll erscheinen, für die ETHMESHMAC die WANMAC zu nehmen, weil die quasi "noch frei" ist. Das könnte dann folgendermaßen aussehen: Beim MAC Adressen hin und her rechnen hab ich ein sehr ungutes Gefühl (siehe auch deine letzte Mail zu dem Thema). Spricht etwas gegen die MAC, die ich verwendet hab? Ansonsten würde ich es dabei belassen. Gruß Fabian
Hallo Fabian, OpenWrt macht bei TP-Link auch nichts anderes als eine Mac-Adresse auszulesen und dann die anderen mit +/-1 auszurechnen, je nachdem was die Original-FW benutzt. Wir kriegen das halt nur nicht mit, weil wir die dann vergebenen Adressen wieder von eth0/eth1/phy0 usw. runter holen. Die WAN-MAC werfen wir nur mit der aktuellen network-config-Strategie quasi weg. Ansonsten ist es wahrscheinlich ziemlich egal, ob man die WAN-MAC oder das Local-Bit nimmt. Ich versuche halt immer möglichst Adressen mit local-bit zu vermeiden. Auf der anderen Seite hätte das local-bit den Vorteil, dass man das irgendwann sogar automatisieren könnte: Für das ethmesh einfach die bestehende MAC mit allen phys vergleichen, wenn Übereinstimmung dann Bit klappen. So könnte man ggf. die komplette ETHMESHMAC-Definition loswerden. Aber ich schweife ab … Mach wie du möchtest, ist wohl insgesamt relativ wurscht. Ansonsten würde ich noch überlegen, entweder CT-Treiber UND Firmware zu nehmen oder beides Non-CT. Ich wäre für letzteres. Grüße Adrian From: Fabian Bläse [mailto:fabian@blaese.de] Sent: Freitag, 31. Mai 2019 17:44 To: mail@adrianschmutzler.de; franken-dev@freifunk.net Subject: Re: [RFC PATCH] Add support for TP-Link Archer C7 v5 Hallo Adrian. On 04.04.19 01:20, mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> wrote: > Hallo Fabian, > > Test hat soweit geklappt, auch das Batman über w5mesh scheint zu gehen. > > PORTORDER="1 2 3 4 5" Danke. > Zur ETHMESHMAC: > Die "normale" Aufteilung (Stock-FW) beim C7v5 ist folgende: > 5 GHz LANMAC-1 > 2.4 GHz LANMAC > LAN LANMAC > WAN LANMAC +1 > > Mir würde es daher als sinnvoll erscheinen, für die ETHMESHMAC die WANMAC zu nehmen, weil die quasi "noch frei" ist. Das könnte dann folgendermaßen aussehen: Beim MAC Adressen hin und her rechnen hab ich ein sehr ungutes Gefühl (siehe auch deine letzte Mail zu dem Thema). Spricht etwas gegen die MAC, die ich verwendet hab? Ansonsten würde ich es dabei belassen. Gruß Fabian
Hallo Adrian, On 31.05.19 22:37, mail@adrianschmutzler.de wrote: > OpenWrt macht bei TP-Link auch nichts anderes als eine Mac-Adresse auszulesen und dann die anderen mit +/-1 auszurechnen, je nachdem was die Original-FW benutzt. Wir kriegen das halt nur nicht mit, weil wir die dann vergebenen Adressen wieder von eth0/eth1/phy0 usw. runter holen. Die WAN-MAC werfen wir nur mit der aktuellen network-config-Strategie quasi weg. Jo, aber OpenWRT liest die Mac Adresse aus dem Flash und kann sich (vermutlich) darauf verlassen, dass da die "richtige" für die Rechnung drin steht. Wir lesen dagegen aus einem Interface raus.. Ich hätte dabei ein ungutes Gefühl, wenn es nicht unbedingt nötig ist. > Auf der anderen Seite hätte das local-bit den Vorteil, dass man das irgendwann sogar automatisieren könnte: Für das ethmesh einfach die bestehende MAC mit allen phys vergleichen, wenn Übereinstimmung dann Bit klappen. So könnte man ggf. die komplette ETHMESHMAC-Definition loswerden. Aber ich schweife ab … Über so eine automatisierung habe ich schon vor Ewigkeiten mal nachgedacht, die Idee aber wieder verworfen, da ich es zu undurchsichtig fand. Aber man kann über so etwas natürlich mal nachdenken. > Mach wie du möchtest, ist wohl insgesamt relativ wurscht. Ich würde meine Lösung bevorzugen und das demnächst als nicht-RFC Patch senden. > Ansonsten würde ich noch überlegen, entweder CT-Treiber UND Firmware zu nehmen oder beides Non-CT. Ich wäre für letzteres. Ich hatte das einfach analog zum C7v2 umgesetzt. Für diese Diskussion gibt es einen eigenen Thread, das Ergebnis davon warte ich mal noch ab. :-) Gruß Fabian