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
Hi all,
on the Libre-Mesh site I can read:
You need to install dependencies:
(i.e. in Debian 7.0 or higger)
apt-get install git build-essential libncurses5-dev zlib1g-dev gawk
after installing those packages and trying to compile I get
Checking 'non-root'... ok.
Build dependency: Please install the subversion client.
Prerequisite check failed. Use FORCE=1 to override.
make[1]: *** [tmp/.prereq-build] Error 1
make[1]: Leaving directory `/home/ilario/software/lime-build/build/trunk'
make: *** [checkout] Error 2
So subversion also is needed?
Bye,
Ilario
Hi!
On one node we are announcing a tunIn for internet and anotherone that have a
corresponding tunOut is tring to reach internet, but there is some problem,
packets never reach the other nodes and sniffing on interfaces never goes out
from the originating node, and on dmesg i have found some of this messages
[ 8829.860000] ip6_tunnel: bmxOut_9f4872: Path to destination invalid or
inactive!
That seems related ecause appears only on the node that is trying to go out,
is it a well known problem or it is necessary a deeper debug ?
Hi, people from Linksys answered me.
As I sent a very informal mail they are interested to know more about (one of) our organization(s). I think they are interested concretely in which way we technically improve by software routers. I think is much better that someone of you that are working or was working in drivers code, dynamic routing daemons code or abstraction layers code (I think before Libre-mesh) send mail to them. Or write your experience and we can send it with a formal e-mail (maybe @libre-mesh.org or @qmp.cat or @bmx6.net or whatever).
Here more or less quick idea of that: http://pad.marsupi.org/WRT1900ac
Finally we can send e-mail to "Karen sohl" <Karen.sohl at belkin.com>
----- Mensaje original -----
> De: "al" <al(a)blogmail.cc>
> Para: "libre-mesh developement" <dev(a)lists.libre-mesh.org>
> Enviados: Martes, 18 de Febrero 2014 15:07:32
> Asunto: Re: [lime-dev] Fwd: Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
>
> One month and no answer.
>
> I sent it again. But... maybe best forget it for now.
>
> I think Compex WPJ344 has more support:
> http://wiki.openwrt.org/toh/compex/wpj344
> https://wikidevi.com/wiki/Compex_WPJ344_%28WPJ344LV%29
>
> ----- Mensaje original -----
> > Enviados: Viernes, 17 de Enero 2014 13:06:36
> > Asunto: Re: [lime-dev] Fwd: Re: [OpenWrt-Devel] is anybody working
> > on supporting Linksys WRT1900ac ?
> >
> > On Thursday 16 January 2014 00:42:00 al wrote:
> > > I sent an email to contact in post.
> >
> > Great!
> >
>
The past week I was in Garraf at La Responsable together with Al to work on
libre-mesh, here I'll do a little report of the work done:
First of all my attention was dedicated to complete stabilize and merge into
develop, wireless mode modularization (branch features/modes-modularization),
wireless modes supported were implemented directly in wireless core file and
didn't support adding of new wireless level configuration modules, so if
someone would for example implement support for 802.11s ¹ in libre-mesh had to
edit core wireless configuration files, while now he can just implement a mode
module, writing very little number of line of code and without the risc of
breaking the libre-mesh core.
Then guided by testing and features requests emerged talking with Al about
emerging communities needs, we decided moving on the following:
First I had to change some default values that was giving trouble for example
the channel 60 is DFS then radios had some difficult waking up we moved to
channel 48 as default that doesn't give such troubles.
Then because we had some cheap device around we tried to flash them with libre-
mesh but the image was too big, so andother pass of modularization was needed,
this time I have splitted protocols support in defferents packages, so for
example cheap battery nodes can ship just batman-adv or just bmx6 according to
user needs, also debug tools were removed form lime-system depends and
splitted to lime-debug tools, so we can install them just when needed and when
them fits.
This new rounds of modularizations evidenced some bad abits in the code like
using a global uci cursor and stuff like that, all things that were fixed before
merge in develop ( more detalis on features/onadiet branch )
The new possibility of having a hybrid mesh of nodes having L2+L3 or L2 only
support suggested the needs of having bmx6 take advantage also of L2 only
piece of mesh so in the branch features/bmx6_over_batman the autoconfiguration
module doing this was implemented and then merged into develop
The rest of time was used to debug why bmx6 wasn't working as expected that
resulted in the discovery that older bmx6 version are working as expected
while newer manifest a bug already reported on this mailing list, plus enjoing
life :)
While waiting fore the dealyed aircraft i was thinking to some odd output of
ps command missing dnsmasq then now i have tested and DHCPv4 is not working
thanks to libre-mesh new modular nature debug of this part will be easier and
hopefully done in following days!
Thanks to La Responsable for ospitality and fun time together!!
[¹] http://en.wikipedia.org/wiki/IEEE_802.11s
---------- Forwarded Message ----------
Subject: Re: [Freifunk-Mentors] GSoC 2014 - Wanna do it?
Date: Saturday 15 February 2014, 17:48:21
From: Mitar <mmitar(a)gmail.com>
To: freifunk-mentors(a)googlegroups.com
Hi!
I added table to each of our ideas. Others, please do the same for your ideas.
Mitar
On Sat, Feb 15, 2014 at 5:17 PM, Mitar <mmitar(a)gmail.com> wrote:
> Hi!
>
> So I think that TODO does not server anybody, but it just makes our
> list of ideas looking less serious.
>
>
> Mitar
>
> On Sat, Feb 15, 2014 at 5:14 PM, Mitar <mmitar(a)gmail.com> wrote:
>> Hi!
>>
>> No, there is no way somebody could take shine away from nodewatcher. ;-)
>>
>> But last time they were checking ideas immediately after the deadline.
>> So I do not see the reason to have TODO in there. They can always add
>> it later, the whole section.
>>
>>
>> Mitar
>>
>> On Sat, Feb 15, 2014 at 4:59 PM, Gioacchino Mazzurco
>> <gmazzurco89(a)gmail.com> wrote:
>>> On Saturday 15 February 2014 16:37:34 Mitar wrote:
>>>> LibreMap is TODO. Can this be filled in or removed?
>>>
>>> Hopefully LibreMap guys will fill it soon, anyway don't think it's a
problem if
>>> it stay as TODO some day more, anyway i'll forward your email to remember
to
>>> the about the idea on the wiki ;)
>>>
>>> [ JOKE ] Mitar do you worry LibreMap taking some shine instead of
Nodewatcher
>>> ? :p [ / JOKE ]
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
"Freifunk Free Community Networks Mentors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
email to freifunk-mentors+unsubscribe(a)googlegroups.com.
>>> Visit this group at http://groups.google.com/group/freifunk-mentors.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>
>
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
--
http://mitar.tnode.com/https://twitter.com/mitar_m
--
You received this message because you are subscribed to the Google Groups
"Freifunk Free Community Networks Mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to freifunk-mentors+unsubscribe(a)googlegroups.com.
Visit this group at http://groups.google.com/group/freifunk-mentors.
For more options, visit https://groups.google.com/groups/opt_out.
-----------------------------------------
