17 Dec
2015
17 Dec
'15
6:56 p.m.
On Thursday, December 17, 2015 06:37:02 PM vittgam(a)mietitrebbia.rocks wrote:
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
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,
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
LibreMesh has the same behavior by default ;)
Please add Vittorio in our list soon ;)
Cheers!
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... 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. 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... 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 ;) (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ò.