Re: [B.A.T.M.A.N.] two-radio nodes and alternative next hop

[Axel Neumann <axel@open-mesh.net>]

Hi Jan,

On Montag 21 April 2008, Jan Hetges wrote:
> On Mon, Apr 21, 2008 at 02:57:44PM +0200, Benjamin Henrion wrote:
> > On Mon, Apr 21, 2008 at 2:39 PM, Jan Hetges <tran@ms20.net> wrote:
> > >  i'm running bmxd_rv972 for almost three months now, without
> > >  any mayor problems :-)... thanks.
> > >  what i recognized lately, on two nodes (the ones with more than
> > >  one bmx interface), show alternativeNextHops, which are *NO*
> > >  alternative. It seems there gets some 'information' lost between
> > >  the two IFs. I suppose that's a known issue ;-), 
It is NOT a known issue (at least not to me) and if its a bug it should be fixed.
> > >  fix/workaround ? iirc, i saw once or twice a node "on the other
> > >  interface" even listed as the bestNextHop.
> >
> > Can you describe a little more extensively your network configuration?
>
> sorry ;-):
>
>  
> x.x.0.0/24---x.x.0.1/x.x.3.1---x.x.3.0/24---x.x.3.160/x.x.4.1---x.x.4.0/24
One general questions: do all your interfaces operate on the same frequency?

Then, I am unsure about the netmasks you are using. The above line I 
understand that you are using x.x.3.0/24 and x.x.4.0/24 netmasks. 
Generally, It is strongly recommended to always use the same netmask 
on ALL batman interfaces !
In your case there is: x.x.3.160/24 for one interface on the 3.160 node 
which should result in a broadcast address of x.x.3.255. 
But according to the debug output there is a direct link to x.x.4.165/24 
(which I guess has broadcast address of x.x.4.255) and therefore the two 
interfaces should not see each other!!?? Can you verify that (note that the 
"ifconfig dev ip/netmask" command is buggy and does not always produce 
corresponding netmask and broadcast addresses and that the interfaces MUST be 
configured appropriately before the daemon is started. !!!)

> .0.1/.3.1 is one node with two radios, and .3.160/.4.1 the other one.
> and, .3.160/.4.1 lists .4.162 as alternativeNextHop to .3.128.
> where .3.1 and .3.137 can see .3.128, but .4.162 can not. 

An alternativeNextHop to a specific node must not necessarily be a direct neighbor of 
that node. For example in the following scenario:

A---B---D
|       |
+---E---+

From As' point of view B and E may both be potential next hops towards D. But only E 
can directly see D.

Is it possible to generate (almost simultaneously) -cbd8 logs from the involved 
nodes, especially 3.1, 3.160, 4.162, 3.128. 

> So, there is a 
> real alternativeNextHop to .3.128 ... .3.137, which is listed after .4.162
> on .3.160/.4.1. I attach the output of bmxd -cbd8.

The attached debug log shows:
172.19.3.128    wlan0:bmx       172.19.3.1  80 (  97  1:01:20:33 15813    0 100 1012  
18   2      1 )    172.19.4.162  67    172.19.3.140   2 

At least this line does not show 3.137 listed after .4.162 on .3.160/.4.1
Has it been truncated ??

Looking forward to solve this...
best regards,
axel