Re: [B.A.T.M.A.N.] Suggestion for routing improvement on poor links

whangarei & opua
2014-02-19T22:12:48Z

On 19.02.2014, at 22:27, Antonio Quartulli wrote:

> On 19/02/14 21:56, whangarei & opua wrote:
>> Hi all,
>>
>> have running batman-adv 2013.4.0 on a hamburg.freifunk.net
>> out-of-the-box router.
>> Have 3 uplinks over Wlan, with trees in the way and some rain at this
>> time... So not perfect conditions...
>>
>> Have seen via 'batctl o' 3 uplinks to the other side of the park.
>> (logging was unfortunately not compiled in)
>> Of cause, one was the best link based on the metric (or what you
>> called
>> it) at this time.
>>
>> But also seen that the metric was not changed during packet lost =>
>> increased last-seen time on this best link :-(
>>
>> So there was a entry with a last-seen of up to 180 sec while other
>> links
>> have had much better update times because of less packet lost, but
>> not
>> so good metric like the main link at his 'best time'.
>> So the 'old' best link was also active, at least by the metric
>> shown by
>> 'batctl o'. Expect the traffic will be sent to this way...
>>
>> Is it maybe a good idea to decrease the metric after a last seen
>> time of
>> a links has increased 15 or 20 sec, step by step on the best link (or
>> all links with increased last seen time) , so a more reliable link
>> ( at
>> this time) has a chance to be activated? I only think about the local
>> routing decision, not about to announce anything to a neighbor...
>
> If I got your question properly I'd say that batman-adv already
> performs
> (in a similar way) what you are suggesting.
>
> First of all I try to summarize your scenario. You have:
> - a source node S, where you are reading the output of "batctl o"
> - a destination node D, which you use to check the output of the
> command
> above
> - two neighbours of S, say N1 and N2
> - N1 is the best nexthop towards D
> - at some point the link between S and N1 becomes unusable and we have
> really high packet loss -> no OGMs are received via this neighbour
> anymore.
>
> At this point S still receives the OGMs generated by D via N2. Each
> time
> one of these packets is received the metric towards D "via N1"
> decreases
> a little bit.
> When this metric "via N1" reaches a value that is smaller then the
> metric "via N2" we have a route change: N2 becomes the bext nexthop.
> You can check this by monitoring the TQ (name of the batman-adv
> metric)
> towards D via N1 in "batctl o" (this command prints the "originator
> table").
>
> How many seconds you need to see this switch depends on the current
> metric values via N1 and via N2.
>
> I hope this clarifies.
>
> Cheers,
>
>
> --
> Antonio Quartulli
>

Hi Antonio,

have only a live environment, so only have access to my own router,
but anyway,
looks you aware of this issue...

But I have seen no change of the TQ over the time ( up to 180 sec) on
my side with my (maybe old) version of batman.
Is it an new feature, or it is maybe not working like expected, in my
old version? :(

Or I'm a little bit blind, sometimes, maybe? ;-)

Joe