New subject: Info linux bridging

17 Dec 2015

On Thursday, December 17, 2015 06:37:02 PM vittgam(a)mietitrebbia.rocks wrote:
...
  On 17/12/2015 12:14:53 CET, Gio wrote:
 > On Wednesday, December 16, 2015 06:17:30 PM vittgam(a)mietitrebbia.rocks 
wrote:
...
    La soluzione dovrebbe essere quella di cambiare il MAC
di eth0 o eth0.10.
 Proverò su eigenNet e ti farò sapere (mi è venuta in mente ora tutta
 sta cosa :D)  
 Questo l'ho già provato io pero cosi' si rompe lo stack di networking di
 linux in realtà anche se eth0.X si espone come un'interfaccia ethernet
 all'utente non lo e' dentro, quello che succede a me e' che se i
 macaddress
 di eth0 ed eth0.X non sono gli stessi non ti arrivano piu' i pacchetti
 sull'interfaccia taggata, in tutto questo si potrebbero fare prove per
 esempio l'interfaccia eth0 in modo promisc ( non sembra una cosa pulita e
 non ho pensate alle implicazioni che possa avere ) e vedere che succede
 oppure l'altra strada che ho provato e' fare altri tentativi con macvlan
 + vlan che pero non hanno funzionato visto che quando metti
 un'interfaccia dentro a un bridge non sei piu' cosi' libero...  
 Io credo che la modalità promisc sia impostata internamente da linux...
 In ogni caso se eth0 fa parte del bridge allora è già promisc di per sé,
 anche se ifconfig non lo dice (se ad esempio fai tcpdump -ni eth0 vedi
 che il kernel non dice più che l'interfaccia è entrata e poi uscita
 dal promiscuous mode; poi invece se non sbaglio lo dice appena la si
 mette nel bridge). 
Yep,

Other tests i have done are:
- While eth0 is bridged to create a macvlan on top of eth0 the kernel refuses 
to create the macvlan saying that the device is busy
- Create a macvlan on top of eth0 and put the macvlan in the bridge, the 
kernel accept to do it but seems a macvlan port is not capable of learning and 
stuff like that, probably is that the kernel is not propagating the promisc flag 
to eth0 meybe setting manually eth0 promisc mode may be helpful but i didn't 
try it yet
- Don't use macvlan but change the mac address of br-lan the mac address is 
changed but "br-lan: received packet with same mac" keep being printed on 
dmesg

...
   Per far
funzionare la macvlan con il bridge l'ho dovuta mettere in modo
 passthru tuttavia questa modalità forza che il macaddress sia lo stesso
 sull'interfaccia base e su quella macvlan tornando quindi alla situazione
 iniziale...

 https://github.com/libre-mesh/lime-packages/commit/c0e945c6b25dd1d802b188d
 dcbc88047e614db7d

 Ho fatto prove con altre modalita di macvlan ma non sembrano funzionare in
 presenza di bridge  
 Mi sembra strano, le macvlan mi funzionavano su kernel più vecchi (3.2) in
 passthru e con mac addresses diversi (cioè è questo il punto delle macvlan),
 però su x86 e schede di rete Intel... Devo provare con OpenWrt su ar71xx. 
Are you sure the macvlan was in passthru mode ? I noticed it have different 
behaviour on different devices when you change the macaddress of a passthru on 
a tl-wdr4300 it changes the macaddress of eth0 too while doing the same on a 
mynet-n600 have no effect in the sense that no error message is printed as the 
mac address was changed but doing ip link show the old mac address both for 
eth0 and passthru,

...
   Ti succede
anche con batman recenti e/o con devices non ubiquity (ubnt
 hanno bachi hardware/driver nelle schede ethernet -_- ) ?  
 Batman 2013.4.0 e Ubiquiti PicoStation M2 su OpenWrt CC r46767, appunto.

 I bug delle ubiquiti sono assurdi, sembra che ce li hanno tutti loro...
 Anche alle nostre unifi gli si resetta l'ethernet a caso per colpa di
 un bug dell'ar7240... 
On some nanostation M2 I do have in Sicilia disabling the ethernet rate 
autonegotiation and fixing it to 100mbps full duplex with ethtool have reduced 
the number of failures now the device is usable but i am not sure it solve all 
problems

...
   Mentre invece
purtroppo sembra che non sia lo stesso per macvlan :(  
 Farò delle prove.. forse non è implementato ancora, perché la situazione
 era così per le VLAN ma ora hanno risolto da un pezzo...

  Non ho capito bene come finiscono i pacchetti
batman sugli AP  
 Se allo stesso switch sono collegate due antenne (che parlano batman tra
 loro con una VLAN e allo stesso tempo bridgeano eth0 con bat0) e client
 ethernet e anche gli AP (gli AP non parlano batman), allora il traffico
 della VLAN di batman entrerebbe nel bridge degli AP e uscirebbe da wlan0.

  pero sembra sia
 un fattore fondamentale quello di usare firmware deversi nello stesso
 spazio/tempo vero ?  
 Per ora stiamo usando questo su CC r46767:

 https://gitlab.com/VittGam/eigenfw/tree/feed

 Prima usavamo un miscuglio di vecchi AA e BB con versioni di batman diverse
 (il firmware "eigennet" insomma).
 La rete ora è uniforme e funziona, e appena è stabile potremo cominciare ad
 aggiornare tutto a Libre-Mesh.

 Una cosa carina di questo firmware è che crea un'immagine unica
 autoconfigurante che decide configurazione (anche hostname e ipv4) in base
 al mac address dell'antenna su cui è flashato, non so se lime lo prevede,
 nel caso si potrebbe aggiungere ;) 
LibreMesh has the same behavior by default ;)

...
  (Comunque l'approccio dell'eth0 con mac
diverso da eth0.10 sta fungendo qui.
 eth0 fa sempre parte di br-lan qui comunque...) 
Yeah i remember we used that approach in Pisa but it was with an old kernel, 
with newer kernels on tl-wdrXXXX i don't get the packets on the vlan if the 
mac address get changed

...
   Che te ne pare
se continuiamo la discussione su dev(a)lists.libre-mesh.org ?  
 Perché no? Mi sono appena iscritto, credo che un admin debba autorizzare
 però. 
Please add Vittorio in our list soon ;)

Cheers!

Re: [lime-dev] Info linux bridging