Hi all, I have two devices (Ubiquiti PicoStation M2 and Ubiquiti NanoStation M5) mounted on the same pole both running libre-mesh [1] firmware (batman-adv: 2014.1.0) and both attached to a Mikrotik RB250GS gigabit switch (latest 1.11 firmware, default configuration) which is attached to my pc [2]. When isolated (turning off the port of the other device via the switch interface), both Ubiquiti devices doesn't see any other device with batman neither have any client connected. Both the devices independently (also when are isolated) print the same error in dmesg: br-lan: received packet on bat0 with own address as source address
This error is an indication that batman loop avoidance has some problems, right? Obviously loop avoidance is enabled. # batctl bl enabled
Various interfaces are bridged, for example in PicoStation I have: # brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.dc9fdb31c136 no eth0 bat0 wlan0_ap
I noticed that I'm not the first to ask here about this message [3][4]. I attach to this email dmesg form both isolated devices, /etc/config/network, ip a, ifconfig, brctl and info from batctl. Thanks, Ilario
[1] http://libre-mesh.org/projects/libre-mesh [2] https://github.com/ilario/configurazione-ilario-fisso [3] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-February/006234.html [4] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-October/010770.html
On Mon, 31 Mar 2014 22:10:37 +0200 Ilario Gelmetti ilario.gelmetti@sns.it wrote:
I have two devices (Ubiquiti PicoStation M2 and Ubiquiti NanoStation M5) mounted on the same pole both running libre-mesh [1] firmware (batman-adv: 2014.1.0) and both attached to a Mikrotik RB250GS gigabit switch (latest 1.11 firmware, default configuration) ... Both the devices independently (also when are isolated) print the same error in dmesg: br-lan: received packet on bat0 with own address as source address
On libre-mesh mailing list there's a solution suggesting to change a mac addresses: http://lists.libre-mesh.org/pipermail/dev/2014-April/000316.html I tried changing the mac address config interface 'lm_eth0_batadv' option ifname 'eth0.11' option proto 'batadv' option mesh 'bat0' option mtu '1496' option macaddr 'dc:9f:db:31:c1:38' and that error in dmesg went away.
On Tuesday 01 April 2014 11:33:01 Ilario GELMETTI wrote:
I tried changing the mac address config interface 'lm_eth0_batadv' option ifname 'eth0.11' option proto 'batadv' option mesh 'bat0' option mtu '1496' option macaddr 'dc:9f:db:31:c1:38' and that error in dmesg went away.
Why a packet form eth0.11 should arrive periodically to the bridge ? Someone can make some sense out of this ?
On 01/04/14 12:35, Gioacchino Mazzurco wrote:
On Tuesday 01 April 2014 11:33:01 Ilario GELMETTI wrote:
I tried changing the mac address config interface 'lm_eth0_batadv' option ifname 'eth0.11' option proto 'batadv' option mesh 'bat0' option mtu '1496' option macaddr 'dc:9f:db:31:c1:38' and that error in dmesg went away.
Why a packet form eth0.11 should arrive periodically to the bridge ? Someone can make some sense out of this ?
I guess that the packet hits the bridge before being de-multiplexed by the vlan code (or both the paths are followed till a certain point?). We should dig into the bridge/vlan code to better understand what is going on..
Cheers,
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
Gioacchino Mazzurco -
Ilario GELMETTI -
Ilario Gelmetti