17 Dec
2015
17 Dec
'15
8:41 p.m.
Hello list, this is my first post here! :)
On 17/12/2015 19:56:50 CET, Gio wrote:
Are you sure the macvlan was in passthru mode ?
I can't remember very well, now that I think about it again I'm not sure it
was actually in passthru mode, probably in private mode.
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
Are you talking about XW series with the problematic ar803x ethernet chip,
or the ar7240 (not ar7241) problem of older XM series?
I think that both problems have just been "solved" in OpenWrt, by handling the
switch reset correctly (like the ubnt firmware does, but with a better
implementation):
https://dev.openwrt.org/ticket/19085
I'm going to test this patch on the UniFi's we have in Pisa, that have the
ar7240 ethernet bug.
LibreMesh has the same behavior by default ;)
I mean, by setting hostnames such as "casottino-pico" or
"casottino-m5" and
IPv4's such as 10.174.146.3. Of course there is a list of MACs, names and IPs
in the firmware.
I think that it's better to use mnemonic hostnames and IPv4's...
It's working here with the CC 3.18.20 kernel on Ubiquiti antennas (so without
the ar8327 switch).
Please add Vittorio in our list soon ;)
I've been added, thank you :)
Cheers,
Vittorio
On Thursday, December 17, 2015 06:37:02 PM
vittgam(a)mietitrebbia.rocks wrote:
I've just tried this and in fact, it says that the device is busy.
# ip link add link eth0 name test0 address 02:aa:cc:bb:22:44 type macvlan mode passthru
The reverse is valid too, if I create the macvlan and then try to put eth0 in the
bridge, brctl will fail with the same error message.
So it seems that macvlan is not thought to be used along with the lower device
of a bridge, even if it could make sense in passthrough mode.
Furthermore it won't let me change the macvlan mac address in passthru mode.
The 02:aa:cc:bb:22:44 is not set either. Maybe it's a kernel bug?
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
A macvlan should automatically enable promiscuous mode for the parent interface
when it is brought up, if it doesn't then it could very well be a kernel bug.
Anyway here it does.
And, it seems that here this configuration is actually working, by having eth0
out of the bridge, and test0 as the only interface in the bridge, then the node
is still reachable. Tcpdump shows that the used MAC address is the one of the
bridge, correctly.
But again, macvlans aren't thought to be used below a bridge, because they are
a partial bridge by themselves...
Instead, adding a passthru macvlan on top of a bridge seems to have killed the
bridge, data is not being sent out of it anymore. Maybe that's because it isn't
able to change the mac address when in passthru mode, since it doesn't happen
with a private, vepa or bridge mode macvlan, where it can change the mac address.
- 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
Yes, because the mac address of the underlying interface is kept the same
and the batman BLA will trigger it again.
We need to change that mac address, and this works in OpenWrt:
config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
list ifname 'eth0'
list ifname 'bat0'
option macaddr 'de:9f:db:aa:bb:cc'
[...]
config interface 'eigenNet_lan_iface'
option proto 'none'
option ifname 'eth0'
option auto '1'
option macaddr 'de:9f:db:aa:bb:cc'
config interface 'eigenNet_lan_mesh_legacy'
option proto 'batadv'
option ifname 'eth0.10'
option mesh 'bat0'
option auto '1'
option macaddr 'dc:9f:db:aa:bb:cc'
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. 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,
The wdr4300 and generally routers with ar8327 switch are special, I think it's
a problem with the switch or its driver, and not with Linux itself.
Anyway yes, it seems that on CC passthru will not let the MAC address change.
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ò.