[PATCH 1/2] fff-network: Only use one Switch Port on Archer C7v2

[Fabian Bläse]

Hallo nochmal,

On 03.12.19 15:59, Fabian Bläse wrote:
> On 03.12.19 15:47, Adrian Schmutzler wrote:
>> Hallo,
>>
>>> -----Original Message-----
>>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf Of
>>> Fabian Bläse
>>> Sent: Dienstag, 3. Dezember 2019 15:23
>>> To: franken-dev at freifunk.net
>>> Subject: [PATCH 1/2] fff-network: Only use one Switch Port on Archer C7v2
>>>
>>> Previously the TP-Link Archer C7v2 was configured to use
>>> two Switch CPU Interfaces. One for Trunk (Client + Batman), one
>>> for WAN.
>>>
>>> As this setup is very uncommon it is converted to a single trunk port
>>> setup just like most of the other routers with integrated managed switches.
>>
>> Also "very uncommon" ist es nicht, ich würde nicht mal behaupten, dass es "uncommon" ist. Streng genommen wäre der 1043 v4/v5 genauso, den haben wir bloß schon immer falsch aufgesetzt. Dementsprechend würde ich hier nicht den Eindruck erwecken, dass das so sei, sondern einfach feststellen, dass es für unsere Firmware (im Moment) einfacher ist, alles an eth0 zu hängen.
> 
> Tatsache. Ich hab vorhin irgendeinen Mist gegrept. Da gibts noch einige Geräte die das ebenfalls so machen.
> Das ist natürlich unglücklich. Ich wäre ja fast dafür, alle Geräte dahingehend anzupassen, dass sie nur den einen CPU Port benutzen. Dann muss man nicht so viel zwischen tagged/untagged, vlan-interface/interface etc. unterscheiden.
> 
> Für die Layer3 Variante ist das aktuell auf jeden Fall ein Problem, weil der CPU-Port dort ja automatisch gesetzt wird.
> Man ist dann viel weniger flexibel, auf welchen Port man jetzt WAN haben möchte.

Ach, jetzt weiß ich wieder: der c7v2 ist das einzige Gerät, der eth1 nutzt, obwohl der WAN-Port ebenfalls am internen Switch hängt.
Alle anderen Geräte, die das WANDEV nicht auf SWITCHDEV haben, haben den WAN-Port als eigenes Interface, das nicht am managed Switch hängt.

Daher halte ich meinen Patch, zumindest für das nächste Release, in dem wir ja noch von configurenetwork abhängig sind, für sinnvoll.
Das Problem mit dem falschen CPU-Port muss ich aber noch reparieren, v2 folgt.

Gruß
Fabian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20191203/f4aa184e/attachment.sig>