@FrancYescO Il mio è un Avago ABCU-5730GZ da 5€
Ho fatto una prova. Mentre l'sfp era collegato, eth4lanwanmode=1 come di sua spontanea volontà, ho verificato che un client connesso alla porta ethernet bivalente funzionasse correttamente e che il traffico generato venisse conteggiato su eth3. In questa situazione il comando ethswctl -c lanwan -p 1 restituisce 'LAN'.
Poi ho modificato eth4lanwanmode su 0, commit, reload. Come da commenti nel codice, il reload non mette down il link. Con dmesg di vedono le commutazioni che esegue quando si inverte il funzionamento e si applicano le modifiche mediante il reload del servizio ethernet. Al file /proc/LanWanMux non riesce ad accedere in nessun caso, credo che venisse usato su altri modelli per ottenere lo stesso risultato. Al termine, l'esito del comando detto prima diventa "WAN". Il collegamento via sfp continua a funzionare ma l'interfaccia eth3 diventa muta, e il cavo non viene rilevato come scollegato. A questo punto mi pare di capire che in questa situazione ad eth4 corrispondano entrambe le porte, e che inoltre eth4 non sia in nessun caso collegata allo switch, ma direttamente al SoC. Il mio 4131 non ha il quantenna come wifi secondario per cui non ho alcuna eth5 su cui provare, ma sarei curioso di sapere cosa siccede impostando wan=1 su eth5. Facendolo su una eth0-3 mi dice molto gentilmente che quelle porte non sono abilitabili per wan (forse perchè sono collegate allo switch e non al SoC?).
Comunque qualsiasi problema del bridging tra porte di switch differenti (eth0-3 vs eth4-5), o tra uno switch e un modem, è identico sia su questi 63138 che sui vecchi 63168, va fatto via software, solo che lì i due switch sono ben distinti, qui non mi è ancora tutto chiaro. Ad esempio il problema di
@stef84 io proverei a risolverlo togliendo eth4 e ptm0 dal bridge lan e definendone uno a parte solo con queste due, sempre con eth4lanwanmode su 1.
