lime-dev

lime-dev@lists.libremesh.org

338 discussions

br-lan: received packet on bat0 with own address as source address

by Ilario GELMETTI

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

10 years, 8 months

google SoC news

by Nicolás Echániz

Hi guys, I received an e-mail confirmation that I'm a mentor for this year's SoC. Have you received any e-mails? cheers, Nico

10 years, 9 months

subversion is a dependency for compilation?

by Ilario GELMETTI

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

10 years, 9 months

bmx6 debugging

by Gioacchino Mazzurco

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 ?

10 years, 9 months

Re: [lime-dev] Fwd: Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

by al

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! > > >

10 years, 9 months

New Libre-Mesh Idea for GSoC 2014

by Gioacchino Mazzurco

http://wiki.freifunk.net/Ideas#Libre-Mesh:_modules_runtime_depends

10 years, 9 months

Improvement on Libre-Mesh at HackErasmus #2

by Gioacchino Mazzurco

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

10 years, 9 months

New idea on freifunk GSoC wiki

by Gioacchino Mazzurco

http://wiki.freifunk.net/Ideas#OpenWrt_D-Link_DIR-632_support Axel do you wanna mentor some student implementing something for bmx6 ? At moment only babel have proposed ideas

10 years, 10 months

Fwd: Re: [Freifunk-Mentors] GSoC 2014 - Wanna do it?

by Gioacchino Mazzurco

---------- 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. -----------------------------------------

10 years, 10 months

libre-mesh.org down again

by al

root@eeprom:/home/al# ping libre-mesh.org PING libre-mesh.org (109.69.10.44) 56(84) bytes of data. ^C --- libre-mesh.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4030ms root@eeprom:/home/al# ping6 libre-mesh.org PING libre-mesh.org(2a00:1508:1:f001::106) 56 data bytes >From 2a00:1508:1:f000::1 icmp_seq=1 Destination unreachable: No route >From 2a00:1508:1:f000::1 icmp_seq=2 Destination unreachable: No route

10 years, 10 months

← Newer
1
...
24
25
26
27
28
29
30
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev