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

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

Hi,

> ok, what happend: .4.165 (i386/prism2.5/hostap(-pci)) switched for some
> unknown reason to .3.x/channel/essid (which explains the poor link from
> .4.165 to ".4.1"(actually .3.160), and i thought it was a fast growing
> Guahumo tree :). So i fixed the bssids on both, .4.1 and .4.165. And it
> seems to not switch anymore... 
So lets hope that the prism2.5 behavior is more predictable than madwifi
> thanks for being so stubborn :-) 
> But that doesn't change the fact, that .4.1 still shows .4.162 as
> alternativeNextHop to .3.x, where, in fact, all alternative paths inside
> .4.x to .3.x lead back to .4.1 !

Yea, thats correct. Its not a bug, its a design thing of the batman protocol.
3.1 generates OGMs which are rebroadcasted via 4.1. Then, they are received 
by 4.162 and 4.160 which rebroadcast them again. Consequently, 4.162 and 
4.160 will both receive 3.1-OGMs from each other. 

3.x----4.1--+- - -4.162-+
            |           |
            +---4.160---+

Now assuming, for some reasons the link between 4.1 and 4.162 is weak, then 
4.162 might receive more OGMs via 4.160 then via 4.1. Consequently, 4.1 will 
receive the 3.x-OGMs broadcasted by 4.162 and consider 4.162 as an 
alternativeNextHop towards 3.x. 
The good thing is that the number of OGMs received via such a "wrong path" can 
NEVER become more (and faster) than those received via the "correct path" and 
therefore such path should never be chosen.

Theoretically, the same applies for a setup like this:
3.x----4.1---4.162 
where 4.1 receives the 3.x-OGMs rebroadcasted by 4.162. But for paranoid 
reasons we included a mechanism which allows 4.1 to identify OGMs that 
travelled via itself just one hop ago.

happy ruminating,

axel


>
> > > i'll make some more logs when .3.137 is back up
>
> still down, anyways, i attach -cbd8 from .4.1, .4.160, .4.162 and .4.165
>
>
> cheers
>
>     --Jan