[B.A.T.M.A.N.] FW: using Batman-adv

[B.A.T.M.A.N.] FW: using Batman-adv

[Joseph Zimmer]

Hello,
 
I am working with BATMAN-ADV and have successfully setup a mesh. In my
implementation of the mesh, the network requires BATMAN to operate in a
linear topology and ideally have node 1 hop to node 2 then through node 3
and finally node 4.
 
        Node1…………………….Node2……………………………..Node3…………………………Node4
 
In this network hops are preferred rather than distant links with low RSSI
values(-70).  The problem that I’m seeing is that the protocol chooses
routes that have the least hops but have RSSI values at about -78 to -90
rather than routing through the closest node with RSSI values in the -50
range.
 
We adjusted the hop penalty to a low value (we used 1 and 0) and we did see
improvement with the hop selection but the throughput is very low due to an
RSSI of -64 or less.
 
Questions:
 
1)       Is there a way to adjust BATMAN using batctl to select routes based
on the RSSI value?
a.       That is, choose to hop through a node with an RSSI of -50 and never
select a node that has a lower RSSI
2)       Does the algorithm for route selection use RSSI in the calculation
and if so can we modify the algorithm to increase the importance of RSSI in
the selection?
3)       How do we gain access to the code to make these modifications?
a.       Can you give me a little guidance on how to modify BATMAN-adv to
suite my situation?
 
Your help is greatly appreciated.
 
Regards,     
 
 
Joseph Zimmer
Telegrid Technology Inc.
19 Microlab Road
Livingston, NJ 07039
Email:  j.zimmer@telegrid.com
Phone: 973.994.4440 X319
 

Re: [B.A.T.M.A.N.] FW: using Batman-adv

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Hi Joseph,

On Thursday 07 May 2015 13:00:52 Joseph Zimmer wrote:
> Hello,
>  
> I am working with BATMAN-ADV and have successfully setup a mesh. In my
> implementation of the mesh, the network requires BATMAN to operate in a
> linear topology and ideally have node 1 hop to node 2 then through node 3
> and finally node 4.
>  
>         Node1…………………….Node2……………………………..Node3…………………………Node4
>  
> In this network hops are preferred rather than distant links with low RSSI
> values(-70).  The problem that I’m seeing is that the protocol chooses
> routes that have the least hops but have RSSI values at about -78 to -90
> rather than routing through the closest node with RSSI values in the -50
> range.
>  
> We adjusted the hop penalty to a low value (we used 1 and 0) and we did see
> improvement with the hop selection but the throughput is very low due to an
> RSSI of -64 or less.
>  
> Questions:
>  
> 1)       Is there a way to adjust BATMAN using batctl to select routes based
> on the RSSI value?
> a.       That is, choose to hop through a node with an RSSI of -50 and never
> select a node that has a lower RSSI

Nope, BATMAN only uses packet loss as a metric. It could be possibly adjusted 
to do so or low signal links could be filtered otherwise, but we would consider 
that a bad hack.

There is another suggestion: You could increase the multicast rate to a high 
value, e.g. 36 MBit/s or even higher. Higher rates only work with good 
signals, and since batman-adv uses broadcasts (which is multicast for WiFi), 
this will have a direct effect on your network.

> 2)       Does the algorithm for route selection use RSSI in the calculation
> and if so can we modify the algorithm to increase the importance of RSSI in
> the selection?

It currently doesn't use RSSI

> 3)       How do we gain access to the code to make these modifications?

Batman-adv is open source, and so is mac80211 and hopefully the WiFi driver 
you use. However, it'd really suggest to start with tuning the multicast rate. 
:)

Cheers,
    Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [B.A.T.M.A.N.] FW: using Batman-adv

[Sven Eckelmann]

On Thursday 07 May 2015 13:00:52 Joseph Zimmer wrote:
> 1)       Is there a way to adjust BATMAN using batctl to select routes based
> on the RSSI value?

No

> 2)       Does the algorithm for route selection use RSSI in the calculation
> and if so can we modify the algorithm to increase the importance of RSSI in
> the selection?

No.

> 3)       How do we gain access to the code to make these modifications?
> a.       Can you give me a little guidance on how to modify BATMAN-adv to
> suite my situation?

But you could patch your wifi driver/framework (for example mac80211) to 
provide an exported function which returns the rssi for a specific net_device 
(net_dev of the if_incoming) + the mac address of the other station (mac orig 
in orig_neigh_node). This function has to basically get the sinfo->signal_avg 
when the sta exists for this bss.

You have to make sure that this device is really a compatible ieee80211 device 
- otherwise your kernel might just crash when accessing the private data of 
the net_device. Maybe this is always true in your situation but I don't know 
your setup well enough. If it is a mixed setup then you can try the 
ieee80211_ptr trick from netdev_notify in net/mac80211/iface.c. This has to be 
done before you are using IEEE80211_DEV_TO_SUB_IF. You can check to 
ieee80211_get_station see a function which already does parts of what you want 
(but it has not yet this check). And also keep in mind that sinfo->signal_avg 
may not be set with correct data. You must check (sinfo->filled & 
STATION_INFO_SIGNAL_AVG) when you are creating a function similar to 
ieee80211_get_station for RSSI.


This code would have to be called when the neighbor tq is calculated in 
batadv_iv_ogm_calc_tq. It basically has to adjust batadv_ogm_packet->tq 
somewhere at the end of the function. The percentage of reduction would have 
to be chosen by you based on how "bad" the rssi value is. I don't have a good 
metric for that.


I am not sure if Antonio/Marek have some proof of concept in their BATMAN V 
branch. But I think they wanted to use the bandwidth based approach which is 
queries the mac80211 rate control information [1].

Kind regards,
	Sven

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/123514

Re: [B.A.T.M.A.N.] FW: using Batman-adv

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Thursday 07 May 2015 19:25:11 Simon Wunderlich wrote:
[....]
> There is another suggestion: You could increase the multicast rate to a high
> value, e.g. 36 MBit/s or even higher. Higher rates only work with good
> signals, and since batman-adv uses broadcasts (which is multicast for
> WiFi), this will have a direct effect on your network.
[...]
> Batman-adv is open source, and so is mac80211 and hopefully the WiFi driver
> you use. However, it'd really suggest to start with tuning the multicast
> rate.
> :)

I definitely agree here. This should tested before trying to hack the TQ
calculation with some own RSSI based submetric.

The mcast_rate trick is currently only shown in an old OpenWrt wiki page [1].
Maybe it should also be mentioned in the main OpenWrt configuration page [2].
I will leave this to the interested reader... or I will change it when I
have some time to confirm it with a current OpenWrt.

Kind regards,
	Sven


[1] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config-sophisticated
[2] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [B.A.T.M.A.N.] FW: using Batman-adv

[Ray Gibson]

On Thu, May 7, 2015 at 10:00 AM, Joseph Zimmer <j.zimmer@telegrid.com> wrote:
>         Node1…………………….Node2……………………………..Node3…………………………Node4

Joseph, the only way I've been able to be truly successful with this
in the past is by selecting different channels for alternating links.
It required additional "nodes" but works fantastic and doesn't have a
speed reduction due to distance.

Node1......(ch a)............Node2--hardwire--Node3..........(ch
b)..........Node4--hardwire--Node5................(ch
c)...........Node6

Once the distance is far enough you can start repeating channels.
Also, you maximize your end to end throughput if your adjacent nodes
use non-adjacent channels.  I've had great success hopping buildings
in urban environments with this method.  This could also be done with
two radios in a single node, I suppose, but how you do it depends on
what your hardware is.

Good luck,

Ray

Re: [B.A.T.M.A.N.] FW: using Batman-adv

[Joseph Zimmer]

> There is another suggestion: You could increase the multicast rate to a
high
> value, e.g. 36 MBit/s or even higher. Higher rates only work with good
> signals, and since batman-adv uses broadcasts (which is multicast for
> WiFi), this will have a direct effect on your network.

I received input mentioning the multicast rate.  
Since the mcast_rate modification looked straight forward I choose to try it
out right away.
 
I did see an improvement in the behavior of our network. By improvement I
mean that I see the network routing through adjacent nodes using hops,
verified by trace route, and achieved higher throughput values.  A value of
36000 was used for the mcast_rate but anything higher broke the system (Not
sure why). I used that value since my research indicated that the value was
in Kbps and Simon pointed out 36 Mbits.

Thanks for the help,

Joseph 

-----Original Message-----
From: B.A.T.M.A.N [mailto:b.a.t.m.a.n-bounces@lists.open-mesh.org] On Behalf
Of Sven Eckelmann
Sent: Friday, May 08, 2015 2:34 AM
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] FW: using Batman-adv

On Thursday 07 May 2015 19:25:11 Simon Wunderlich wrote:
[....]
> There is another suggestion: You could increase the multicast rate to a
high
> value, e.g. 36 MBit/s or even higher. Higher rates only work with good
> signals, and since batman-adv uses broadcasts (which is multicast for
> WiFi), this will have a direct effect on your network.
[...]
> Batman-adv is open source, and so is mac80211 and hopefully the WiFi
driver
> you use. However, it'd really suggest to start with tuning the multicast
> rate.
> :)

I definitely agree here. This should tested before trying to hack the TQ
calculation with some own RSSI based submetric.

The mcast_rate trick is currently only shown in an old OpenWrt wiki page
[1].
Maybe it should also be mentioned in the main OpenWrt configuration page
[2].
I will leave this to the interested reader... or I will change it when I
have some time to confirm it with a current OpenWrt.

Kind regards,
	Sven


[1]
http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config-
sophisticated
[2]
http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config