Thanks Antonio, I appreciate the quick reply.

batctl -v returns: batctl debian-2012.1.0-1 [batman-adv: 2013.2.0]

Should I compile and install from the latest git? I see that the batctl command is from a much older release.. It doesn't support the dat or dc parameters. Should I compile that one as well?

Thanks again, Itamar

On Thu, Mar 13, 2014 at 1:00 PM, Antonio Quartulli antonio@meshcoding.com wrote:

On 13/03/14 10:24, Itamar Landsman wrote:

...

HI, I am running a project using Raspberry pi machines that create a batman-adv mesh. Each of the rpis has three wifi devices. each of the wifi devices hosts a separate ad-hoc network. This way I can get to work on three separate channels and let batman worry about paths.

My problem is that whenever I reboot a device, it comes back to life but IP connection is never regained until; I reboot all other devices.

I have tried to move the IP address from the bt0 interface to a bridge interface that hosts br0 with no success.

Any ideas?

I am using the "Out of the box" batman-adv modules and batctl that come with the most recent raspbian repo.

Unfortunately I don't know what version of batman-adv is shipped iwth raspbian. Can you check the exact version by typing "batctl -v" ?

This "issue" seems similar to something we already talked about in the past: it's a side effect of using DAT.

DAT caches ARP entries, therefore when you reboot your node and bat0 gets a "different" (randomly generated) MAC address, you should wait for all the other nodes in the network to drop their cached ARP entry and request the new one associated with your IP (this is a simplistic explanation of how ARP usually work).

I hop I made the "issue" clear. You can check if you are really using DAT by typing "batctl dat".

For more details about DAt, please check our wiki[1]

Cheers,

[1] http://www.open-mesh.org/projects/batman-adv/wiki/DistributedArpTable

-- Antonio Quartulli

Thanks, I see that 2004.1 had just been released.. I will compile and give it a go.

Cheers, Itamar

On Thu, Mar 13, 2014 at 3:42 PM, Antonio Quartulli antonio@meshcoding.com wrote:

On 13/03/14 13:20, Itamar Landsman wrote:

...

Thanks Antonio, I appreciate the quick reply.

batctl -v returns: batctl debian-2012.1.0-1 [batman-adv: 2013.2.0]

Should I compile and install from the latest git? I see that the batctl command is from a much older release.. It doesn't support the dat or dc parameters. Should I compile that one as well?

The recommendation is to always run the same version of batctl and batman-adv, exactly to avoid this kind of situations where you have a feature in the kernel module that cannot be used by batctl (I have to say that you can use every feature *without* batctl, but if you want to use the tool it is better to get the right version).

The batman-adv version you run is also rather old. I'd personally recommend to wait one or two days for the next release and then download it (yes, the developers are in the process of releasing it).

However, here[1] you have a description of the sysfs interface that you can use to quickly check the DAT status without doing any upgrade.

Cheers,

[1] http://www.open-mesh.org/projects/batman-adv/wiki/Tweaking

-- Antonio Quartulli

On Thu, Mar 13, 2014 at 05:21:28PM +0100, Harms, Hannes wrote:

Dear list, im wondering if it is possible to just compile the latest release of batman-adv and replace the existing kernel module on an Debian System. It is not necessary to have a propriate kernel version e.g. 3.13 ?

The batman-adv sources will compile against some older kernels. So as long as you have a recent Debian, e.g. Jessie or Wheezy, you should be able to install the kernel headers packages and then compile the kernel module.

Andrew,

Hi Itamar,

You should also consider a problem at your wifi driver level.

We've seen a behavior very similar to what you are describing using ath9k hardware a while ago.

Cheers, NicoEchániz

El 16/03/14 10:16, Itamar escribió:

I have compiled both the kernel module and batctl from source (2014.1.0). The problem remains. Whenever I reboot a node, its IP is never reachable from the network and the network can not be reached by it.

Things I have tried:

• DAT enabled
• DAT Disabled
• DAT not compiled (ticked "n" in the Makefile)

Of course, the tests were performed when all nodes in the mesh were with the consistent configuration and never mixed.

Another curious thing I have seen is that when looking at a tcpdump (via batctl) I could indeed see ARP requests to the pinged IP (the tcpdump running on the node hosting the pinged IP) but the node never replies.

What else should I try?

Thanks, Itamar

On 03/13/2014 04:51 PM, Itamar Landsman wrote:

...

Thanks, I see that 2004.1 had just been released.. I will compile and give it a go.

Cheers, Itamar

On Thu, Mar 13, 2014 at 3:42 PM, Antonio Quartulli antonio@meshcoding.com wrote:

...

On 13/03/14 13:20, Itamar Landsman wrote:

...

Thanks Antonio, I appreciate the quick reply.

batctl -v returns: batctl debian-2012.1.0-1 [batman-adv: 2013.2.0]

Should I compile and install from the latest git? I see that the batctl command is from a much older release.. It doesn't support the dat or dc parameters. Should I compile that one as well?

The recommendation is to always run the same version of batctl and batman-adv, exactly to avoid this kind of situations where you have a feature in the kernel module that cannot be used by batctl (I have to say that you can use every feature *without* batctl, but if you want to use the tool it is better to get the right version).

The batman-adv version you run is also rather old. I'd personally recommend to wait one or two days for the next release and then download it (yes, the developers are in the process of releasing it).

However, here[1] you have a description of the sysfs interface that you can use to quickly check the DAT status without doing any upgrade.

Cheers,

[1] http://www.open-mesh.org/projects/batman-adv/wiki/Tweaking

-- Antonio Quartulli

Thanks all for your support, U have figured out the issue. I is indeed related to a driver issue (so I now understand). grinding my teeth trying to debug I have realized that when I power cycle the raspberry-pi the link returns. Whereas I do a reboot via console, the link refuses to start. The issue is probably related to the wifi card not being initialized properly when the driver is loaded. What I did to resolve is simple. I have added some extra lines to to initialization script of the wireless device;

ifconfig ra0 up ifconfig ra0 down ifconfig ra0 up iwconfig ra0 mode monitor

And after this "morning sport activity" to the interface I continued as usual, setting it to ad-hoc and adding it to the bat0 device.

The interface I use is a cheap ralink 7601 chipset usb wifi (idVendor=148f, idProduct=7601). But maybe this may help whoever stumbles into something similar.

Thanks for the help! Itamar

On 14-03-17 06:18 AM, Antonio Quartulli wrote:

On 16/03/14 14:16, Itamar wrote:

...

I have compiled both the kernel module and batctl from source (2014.1.0). The problem remains. Whenever I reboot a node, its IP is never reachable from the network and the network can not be reached by it.

Things I have tried:

• DAT enabled
• DAT Disabled
• DAT not compiled (ticked "n" in the Makefile)

Of course, the tests were performed when all nodes in the mesh were with the consistent configuration and never mixed.

Another curious thing I have seen is that when looking at a tcpdump (via batctl) I could indeed see ARP requests to the pinged IP (the tcpdump running on the node hosting the pinged IP) but the node never replies.

Have you seen if the ARP request makes its way to the other host? (e.g. using tcpdump on bat0 to check that the packet is getting delivered).

Then check if the ARP reply is at least sent. If so, check where it gets lost.

Cheers,