31 Mar
2014
31 Mar
'14
9:49 a.m.
Hi all,
I have two devices (Ubiquiti PicoStation M2 and Ubiquiti NanoStation M5) in a very simple
configuration: both attached to a Mikrotik RB250GS gigabit switch (latest 1.11 firmware)
and both running the latest libre-mesh firmware.
From dmesg of the two devices I can see some error form
batman loop avoidance:
br-lan: received packet on bat0 with own address as source
address
Do you think that could be a libre-mesh related problem?
This is from the PicoStation
[...]
[ 15.520000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.520000] device eth0 entered promiscuous mode
[ 15.540000] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[ 15.640000] device br-lan entered promiscuous mode
[ 15.640000] IPv6: ADDRCONF(NETDEV_UP): anygw: link is not ready
[ 15.690000] IPv6: ADDRCONF(NETDEV_UP): eth0.11: link is not ready
[ 15.840000] IPv6: ADDRCONF(NETDEV_UP): eth0.12: link is not ready
[ 16.060000] batman_adv: bat0: Adding interface: eth0.11
[ 16.060000] batman_adv: bat0: The MTU of interface eth0.11 is too small (1496) to
handle the transport of batman-adv packets. Packets going over this interface will be
fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would
solve the problem.
[ 16.090000] batman_adv: bat0: Interface activated: eth0.11
[ 16.100000] 8021q: adding VLAN 0 to HW filter on device bat0
[ 16.100000] device bat0 entered promiscuous mode
[ 16.110000] br-lan: port 2(baINBOXt0) entered forwarding state
[ 16.110000] br-lan: port 2(bat0) entered forwarding state
[ 16.220000] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 16.220000] IPv6: ADDRCONF(NETDEV_CHANGE): anygw: link becomes ready
[ 16.240000] br-lan: received packet on bat0 with own address as source address
[ 16.410000] eth0: link up (100Mbps/Full duplex)
[ 16.410000] br-lan: port 1(eth0) entered forwarding state
[ 16.420000] br-lan: port 1(eth0) entered forwarding state
[ 16.420000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 16.440000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.11: link becomes ready
[ 16.480000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.12: link becomes ready
[ 17.340000] batman_adv: bat0: bridge_loop_avoidance: Changing from: disabled to:
enabled
[ 17.370000] batman_adv: bat0: distributed_arp_table: Changing from: enabled to:
disabled
[ 18.110000] br-lan: port 2(bat0) entered forwarding state
[ 18.420000] br-lan: port 1(eth0) entered forwarding state
[ 20.350000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap: link is not ready
[ 20.370000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap.12: link is not ready
[ 23.510000] device wlan0_ap entered promiscuous mode
[ 23.530000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap.12: link is not ready
[ 23.540000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap: link is not ready
[ 23.560000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_ap: link becomes ready
[ 23.560000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_ap.12: link becomes ready
[ 23.580000] br-lan: port 3(wlan0_ap) entered forwarding state
[ 23.580000] br-lan: port 3(wlan0_ap) entered forwarding state
[ 25.580000] br-lan: port 3(wlan0_ap) entered forwarding state
[ 26.040000] br-lan: received packet on bat0 with own address as source address
[ 27.090000] IPv6: ADDRCONF(NETDEV_UP): wlan0_adhoc: link is not ready
[ 27.110000] wlan0_adhoc: Created IBSS using preconfigured BSSID ca:fe:00:c0:ff:ee
[ 27.110000] wlan0_adhoc: Creating new IBSS network, BSSID ca:fe:00:c0:ff:ee
[ 27.120000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_adhoc: link becomes ready
[ 36.060000] br-lan: received packet on bat0 with own address as source address
[ 46.080000] br-lan: received packet on bat0 with own address as source address
[ 56.100000] br-lan: received packet on bat0 with own address as source address
[ 66.120000] br-lan: received packet on bat0 with own address as source address
[...]
batctl s
tx: 12
tx_bytes: 1264
tx_dropped: 43
rx: 20
rx_bytes: 948
forward: 0
forward_bytes: 0
mgmt_tx: 365
mgmt_tx_bytes: 23182
mgmt_rx: 362
mgmt_rx_bytes: 22912
frag_tx: 0
frag_tx_bytes: 0
frag_rx: 0
frag_rx_bytes: 0
frag_fwd: 0
frag_fwd_bytes: 0
tt_request_tx: 1
tt_request_rx: 2
tt_response_tx: 2
tt_response_rx: 1
tt_roam_adv_tx: 0
tt_roam_adv_rx: 0
dat_get_tx: 0
dat_get_rx: 0
dat_put_tx: 0
dat_put_rx: 0
dat_cached_reply_tx: 0
and this is from NanoStation:
[...]
[ 17.460000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 17.460000] device eth0 entered promiscuous mode
[ 17.480000] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[ 17.520000] device br-lan entered promiscuous mode
[ 17.520000] IPv6: ADDRCONF(NETDEV_UP): anygw: link is not ready
[ 17.550000] eth0: link up (100Mbps/Full duplex)
[ 17.550000] br-lan: port 1(eth0) entered forwarding state
[ 17.560000] br-lan: port 1(eth0) entered forwarding state
[ 17.560000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 18.610000] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 18.610000] device eth1 entered promiscuous mode
[ 18.620000] br-lan: port 2(eth1) entered forwarding state
[ 18.620000] br-lan: port 2(eth1) entered forwarding state
[ 18.630000] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 18.660000] br-lan: port 2(eth1) entered disabled state
[ 18.740000] IPv6: ADDRCONF(NETDEV_UP): eth1.11: link is not ready
[ 18.750000] IPv6: ADDRCONF(NETDEV_CHANGE): anygw: link becomes ready
[ 18.800000] IPv6: ADDRCONF(NETDEV_UP): eth1.12: link is not ready
[ 19.120000] batman_adv: bat0: Adding interface: eth0.11
[ 19.130000] batman_adv: bat0: The MTU of interface eth0.11 is too small (1496) to
handle the transport of batman-adv packets. Packets going over this interface will be
fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would
solve the problem.
[ 19.150000] batman_adv: bat0: Interface activated: eth0.11
[ 19.160000] 8021q: adding VLAN 0 to HW filter on device bat0
[ 19.210000] device bat0 entered promiscuous mode
[ 19.210000] br-lan: port 3(bat0) entered forwarding state
[ 19.220000] br-lan: port 3(bat0) entered forwarding state
[ 19.270000] batman_adv: bat0: Adding interface: eth1.11
[ 19.270000] batman_adv: bat0: The MTU of interface eth1.11 is too small (1496) to
handle the transport of batman-adv packets. Packets going over this interface will be
fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would
solve the problem.
[ 19.300000] batman_adv: bat0: Interface activated: eth1.11
[ 19.560000] br-lan: port 1(eth0) entered forwarding state
[ 20.810000] batman_adv: bat0: bridge_loop_avoidance: Changing from: disabled to:
enabled
[ 20.810000] batman_adv: bat0: distributed_arp_table: Changing from: enabled to:
disabled
[ 21.220000] br-lan: port 3(bat0) entered forwarding state
[ 22.650000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap: link is not ready
[ 22.680000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap.12: link is not ready
[ 27.590000] device wlan0_ap entered promiscuous mode
[ 27.620000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap.12: link is not ready
[ 27.630000] IPv6: ADDRCONF(NETDEV_UP): wlan0_ap: link is not ready
[ 27.650000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_ap: link becomes ready
[ 27.650000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_ap.12: link becomes ready
[ 27.670000] br-lan: port 4(wlan0_ap) entered forwarding state
[ 27.670000] br-lan: port 4(wlan0_ap) entered forwarding state
[ 29.140000] br-lan: received packet on bat0 with own address as source address
[ 29.670000] br-lan: port 4(wlan0_ap) entered forwarding state
[ 31.750000] IPv6: ADDRCONF(NETDEV_UP): wlan0_adhoc: link is not ready
[ 31.770000] wlan0_adhoc: Created IBSS using preconfigured BSSID ca:fe:00:c0:ff:ee
[ 31.780000] wlan0_adhoc: Creating new IBSS network, BSSID ca:fe:00:c0:ff:ee
[ 31.790000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0_adhoc: link becomes ready
[ 39.160000] br-lan: received packet on bat0 with own address as source address
[ 49.180000] br-lan: received packet on bat0 with own address as source address
[ 59.200000] br-lan: received packet on bat0 with own address as source address
[ 69.220000] br-lan: received packet on bat0 with own address as source address
[...]
batctl s
tx: 10
tx_bytes: 1096
tx_dropped: 41
rx: 18
rx_bytes: 756
forward: 0
forward_bytes: 0
mgmt_tx: 879
mgmt_tx_bytes: 51202
mgmt_rx: 352
mgmt_rx_bytes: 22292
frag_tx: 0
frag_tx_bytes: 0
frag_rx: 0
frag_rx_bytes: 0
frag_fwd: 0
frag_fwd_bytes: 0
tt_request_tx: 4
tt_request_rx: 1
tt_response_tx: 1
tt_response_rx: 2
tt_roam_adv_tx: 0
tt_roam_adv_rx: 0
dat_get_tx: 0
dat_get_rx: 0
dat_put_tx: 0
dat_put_rx: 0
dat_cached_reply_tx: 0
This problem isn't related to interaction between two devices, because also isolating
a device via switch web interface, the other one after rebooting shows the same error
again.
Again, I don't know if this is a libre-mesh related problem or a problem of batman
loop avoidance.
Maybe the problem is related to this old closed bug? http://www.open-mesh.org/issues/170
Thanks,
Ilario
31 Mar
31 Mar
10:14 a.m.
On Monday 31 March 2014 11:49:44 Ilario GELMETTI wrote:
firmware. From dmesg of the two devices I can see some
error form batman
loop avoidance: br-lan: received packet on bat0 with own address as source
address Do you think that could be a libre-mesh related problem?
It seems it is related but inside batman-adv problem is causing this, i have
already reported this various times to batman-adv folks moreover it doesn't
depend on your fisical setup because it happens also with just one device
Please report this bug to batma-adv guys too so they have more data to
investigate
5:18 p.m.
On Mon, 31 Mar 2014 12:14:42 +0200
Gioacchino Mazzurco <gio(a)eigenlab.org> wrote:
On Monday 31 March 2014 11:49:44 Ilario GELMETTI
wrote:
I'm going to ask on batman-adv mailing list, btw no one has this problem using libre
mesh with meshing activated also on the wired interface?
firmware. From dmesg of the two devices I can see
some error form batman
loop avoidance: br-lan: received packet on bat0 with own address as source
address Do you think that could be a libre-mesh related problem?
It seems it is related but inside batman-adv problem is causing this, i have
already reported this various times to batman-adv folks moreover it doesn't
depend on your fisical setup because it happens also with just one device
Please report this bug to batma-adv guys too so they have more data to
investigate 
7:05 p.m.
New subject: br-lan: received packet on bat0 with own address as source address
El 31/03/14 14:18, Ilario GELMETTI escribió:
On Mon, 31 Mar 2014 12:14:42 +0200 Gioacchino
Mazzurco
<gio(a)eigenlab.org> wrote:
It is relatively common to see this message from time to time in batman
nodes, but if you start seeing it very frequently it will most surely be
sign of a problem. Search the batman list archives for this, there has
been some discussion already.
I've seen a network start logging this error repeatedly on every node
when a router's switch is broken by an electrical discharge; I've seen
this three times actually. It renders the network practically unusable
until the router is detected and replaced.
cheers,
Nico
On Monday 31 March 2014 11:49:44 Ilario GELMETTI
wrote:
I'm going to ask on batman-adv mailing list, btw no one has this
problem using libre mesh with meshing activated also on the wired
interface? firmware. From dmesg of the two devices I can see
some error form
batman loop avoidance: br-lan: received packet on bat0 with own
address as source address Do you think that could be a libre-mesh
related problem?
It seems it is related but inside batman-adv problem is causing
this, i have already reported this various times to batman-adv
folks moreover it doesn't depend on your fisical setup because it
happens also with just one device
Please report this bug to batma-adv guys too so they have more data
to investigate
8:40 p.m.
On Monday 31 March 2014 16:05:20 Nicolás Echániz wrote:
It is relatively common to see this message from time
to time in batman
nodes, but if you start seeing it very frequently it will most surely be
sign of a problem.
I believe you see this message only time to time because you are still using
altermesh firmware, with libremesh setup this message is fired a lot and also
with working device, with ordex we was discussing this and we didn't
understand from were it comes... furter investigation is needed
8:43 p.m.
New subject: br-lan: received packet on bat0 with own address as source address
Il 31/03/2014 21:05, Nicolás Echániz ha scritto:
El 31/03/14 14:18, Ilario GELMETTI escribió:
I can see this message in dmesg every 10.02 seconds.
On Mon, 31 Mar 2014 12:14:42 +0200 Gioacchino
Mazzurco
<gio(a)eigenlab.org> wrote:
It is relatively common to see this message from time to time in batman
nodes, but if you start seeing it very frequently it will most surely be
sign of a problem. On Monday 31 March 2014 11:49:44 Ilario GELMETTI
wrote:
I'm going to ask on batman-adv mailing list, btw no one has this
problem using libre mesh with meshing activated also on the wired
interface? firmware. From dmesg of the two devices I can see
some error form
batman loop avoidance: br-lan: received packet on bat0 with own
address as source address Do you think that could be a libre-mesh
related problem?
It seems it is related but inside batman-adv problem is causing
this, i have already reported this various times to batman-adv
folks moreover it doesn't depend on your fisical setup because it
happens also with just one device
Please report this bug to batma-adv guys too so they have more data
to investigate Search the batman list archives for this, there has
been some discussion already.
Yep, in these discussions:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-February/006234.html
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-October/010770.html
I sent an email to batman-adv list:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
Bye,
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
ilario.gelmetti(a)sns.it
1 Apr
1 Apr
6:33 a.m.
New subject: br-lan: received packet on bat0 with own address as source address
I solved this troubble some months ago.
The problem come in openwrt because by default the macaddr of br-mesh (the
bridge where i put bat0) is the same of vlan macaddr (inserted in bat0)
For example, in tplink wdr4300 with openwrt in /etc/config/network I have:
config interface 'mesh2'
option proto 'batadv'
option mesh 'bat0'
option ifname 'eth0.7'
option macaddr '90:f6:52:f2:8c:2*c*'
root@tl-wrd4300:~# cat /sys/class/net/eth0.7/address
90:f6:52:f2:8c:2*c*
root@tl-wrd4300:~# cat /sys/class/net/br-mesh/address
90:f6:52:f2:8c:2*a*
There is another small problem about this configuration in config/network.
After setup new macaddr of vlan and uci commit network, /etc/init.d/network
restart don't change the macaddr correctly, but reboot is needed.
ciao
LP
On Mon, Mar 31, 2014 at 10:43 PM, Ilario Gelmetti <ilario.gelmetti(a)sns.it>wrote;wrote:
Il 31/03/2014 21:05, Nicolás Echániz ha scritto:
--
luca.postregna.name
twitter.com/lucapost
El 31/03/14 14:18, Ilario GELMETTI escribió:
I can see this message in dmesg every 10.02 seconds.
On Mon, 31 Mar 2014 12:14:42 +0200 Gioacchino
Mazzurco
<gio(a)eigenlab.org> wrote:
It is relatively common to see this message from time to time in batman
nodes, but if you start seeing it very frequently it will most surely be
sign of a problem. On Monday 31 March 2014 11:49:44 Ilario GELMETTI
wrote:
> firmware. From dmesg of the two devices I can see some error form
> batman loop avoidance: br-lan: received packet on bat0 with own
> address as source address Do you think that could be a libre-mesh
> related problem?
It seems it is related but inside batman-adv problem is causing
this, i have already reported this various times to batman-adv
folks moreover it doesn't depend on your fisical setup because it
happens also with just one device
Please report this bug to batma-adv guys too so they have more data
to investigate
I'm going to ask on batman-adv mailing list, btw no one has this
problem using libre mesh with meshing activated also on the wired
interface? Search the batman list archives for this, there
has
been some discussion already.
Yep, in these discussions:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-February/006234.html
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-October/010770.html
I sent an email to batman-adv list:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
Bye,
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
ilario.gelmetti(a)sns.it
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
10:18 a.m.
Thanks, I followed your suggestion and changing the mac address of
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:3*8*'
(and also of lm_eth1_batadv on the nanostation) and when the bridge loop avoidance is
enabled the error messages disappear.
root@31c136:~# cat /sys/class/net/eth0.11/address
dc:9f:db:31:c1:38
root@31c136:~# cat /sys/class/net/br-lan/address
dc:9f:db:31:c1:36
Do you think that this setting could have any drawback?
Thanks again,
Ilario
On Tue, 1 Apr 2014 08:33:34 +0200
Luca Postregna <luca.postregna(a)gmail.com> wrote:
I solved this troubble some months ago.
The problem come in openwrt because by default the macaddr of br-mesh (the
bridge where i put bat0) is the same of vlan macaddr (inserted in bat0)
For example, in tplink wdr4300 with openwrt in /etc/config/network I have:
config interface 'mesh2'
option proto 'batadv'
option mesh 'bat0'
option ifname 'eth0.7'
option macaddr '90:f6:52:f2:8c:2*c*'
root@tl-wrd4300:~# cat /sys/class/net/eth0.7/address
90:f6:52:f2:8c:2*c*
root@tl-wrd4300:~# cat /sys/class/net/br-mesh/address
90:f6:52:f2:8c:2*a*
There is another small problem about this configuration in config/network.
After setup new macaddr of vlan and uci commit network, /etc/init.d/network
restart don't change the macaddr correctly, but reboot is needed.
ciao
LP
On Mon, Mar 31, 2014 at 10:43 PM, Ilario Gelmetti <ilario.gelmetti(a)sns.it>wrote;wrote:
> Il 31/03/2014 21:05, Nicolás Echániz ha scritto:
> > El 31/03/14 14:18, Ilario GELMETTI escribió:
> >> On Mon, 31 Mar 2014 12:14:42 +0200 Gioacchino Mazzurco
> >> <gio(a)eigenlab.org> wrote:
> >>> On Monday 31 March 2014 11:49:44 Ilario GELMETTI wrote:
> >>>> firmware. From dmesg of the two devices I can see some error form
> >>>> batman loop avoidance: br-lan: received packet on bat0 with own
> >>>> address as source address Do you think that could be a libre-mesh
> >>>> related problem?
> >>>
> >>> It seems it is related but inside batman-adv problem is causing
> >>> this, i have already reported this various times to batman-adv
> >>> folks moreover it doesn't depend on your fisical setup because it
> >>> happens also with just one device
> >>>
> >>> Please report this bug to batma-adv guys too so they have more data
> >>> to investigate
> >>
> >> I'm going to ask on batman-adv mailing list, btw no one has this
> >> problem using libre mesh with meshing activated also on the wired
> >> interface?
> >
> > It is relatively common to see this message from time to time in batman
> > nodes, but if you start seeing it very frequently it will most surely be
> > sign of a problem.
>
> I can see this message in dmesg every 10.02 seconds.
>
> > Search the batman list archives for this, there has
> > been some discussion already.
>
> Yep, in these discussions:
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-February/006234.html
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-October/010770.html
>
> I sent an email to batman-adv list:
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
> Bye,
> Ilario
11:18 a.m.
New subject: br-lan: received packet on bat0 with own address as source address
Openwrt devs said me to ask to Batman devs. Batman devs said me to ask to
openwrt devs. Now, libre-mesh devs said to ask to others devs. I love
opensource devs!
On Apr 1, 2014 12:26 PM, "Gioacchino Mazzurco" <gio(a)eigenlab.org> wrote:
On Tuesday 01 April 2014 12:18:14 Ilario GELMETTI
wrote:
Do you think that this setting could have any
drawback?
This shouldn't have any drawback but there is no reason why a packet form
eth0.X should arrive ti the bridge, so please report to batman-adv ml ;)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
2:43 p.m.
On Tuesday 01 April 2014 13:18:05 Luca Postregna wrote:
Openwrt devs said me to ask to Batman devs. Batman
devs said me to ask to
openwrt devs. Now, libre-mesh devs said to ask to others devs. I love
opensource devs!
I think we are slowly converging to investigate linux kernel vlan and bridge
code ;)
3672
days inactive
3673
days old
12 comments
5 participants
participants (5)
-
Gioacchino Mazzurco -
Ilario GELMETTI -
Ilario Gelmetti
-
Luca Postregna -
Nicolás Echániz