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

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

[whangarei & opua]

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...

Sorry, have not much experiences with Wlan links, also be not familiar  
with programming, but with some layer 3 routing protocols... Hope you  
understand my issue anyway :)

By, Joe

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

[Antonio Quartulli]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[whangarei & opua]

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

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

[Antonio Quartulli]

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

On 19/02/14 23:12, whangarei & opua wrote:
> 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? :(
> 

I think this is something that is part of batman-adv since the beginning
(somebody else can confirm this).

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

I have the feeling that you are not looking at the right entry in the
originator table :-)


You may want to report some output/real numbers (at different times) so
that we can comment on those.


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Andrew Lunn]

On Wed, Feb 19, 2014 at 11:30:36PM +0100, Antonio Quartulli wrote:
> On 19/02/14 23:12, whangarei & opua wrote:
> > 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? :(
> > 
> 
> I think this is something that is part of batman-adv since the beginning
> (somebody else can confirm this).

The routing protocol is known to have problems when a node suddenly
disappears. A received OGM is what triggers updates to the metric. If
you stop receiving OGMs the metric is no longer updated until the node
is purged as dead. This for example causes problems with
nomadic/mobile nodes. They can go around a corner, loss line of sight,
but still be considered the best route until purged as dead.

This design problem will be fixed with the BATMAN V. It has a second
protocol which is used between one hop peers and should quickly detect
if a peer has disappeared.

   Andrew

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

[Antonio Quartulli]

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

On 20/02/14 09:54, Andrew Lunn wrote:
> The routing protocol is known to have problems when a node suddenly
> disappears. A received OGM is what triggers updates to the metric. If
> you stop receiving OGMs the metric is no longer updated until the node
> is purged as dead. This for example causes problems with
> nomadic/mobile nodes. They can go around a corner, loss line of sight,
> but still be considered the best route until purged as dead.

But if you keep receiving OGMs via another neighbour you will have a
route switch *before* the old nexthop is considered as dead.


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Andrew Lunn]

On Thu, Feb 20, 2014 at 10:03:01AM +0100, Antonio Quartulli wrote:
> On 20/02/14 09:54, Andrew Lunn wrote:
> > The routing protocol is known to have problems when a node suddenly
> > disappears. A received OGM is what triggers updates to the metric. If
> > you stop receiving OGMs the metric is no longer updated until the node
> > is purged as dead. This for example causes problems with
> > nomadic/mobile nodes. They can go around a corner, loss line of sight,
> > but still be considered the best route until purged as dead.
> 
> But if you keep receiving OGMs via another neighbour you will have a
> route switch *before* the old nexthop is considered as dead.

Hi Antonio

That is not what i have seen in practice. Because the metric is good,
and does not degrade, it stays as the best route. That is one of the
reasons Linus developed NDP while at Ascom.

	  Andrew

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

[Antonio Quartulli]

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

On 20/02/14 10:09, Andrew Lunn wrote:
> On Thu, Feb 20, 2014 at 10:03:01AM +0100, Antonio Quartulli wrote:
>> On 20/02/14 09:54, Andrew Lunn wrote:
>>> The routing protocol is known to have problems when a node suddenly
>>> disappears. A received OGM is what triggers updates to the metric. If
>>> you stop receiving OGMs the metric is no longer updated until the node
>>> is purged as dead. This for example causes problems with
>>> nomadic/mobile nodes. They can go around a corner, loss line of sight,
>>> but still be considered the best route until purged as dead.
>>
>> But if you keep receiving OGMs via another neighbour you will have a
>> route switch *before* the old nexthop is considered as dead.
> 
> Hi Antonio

Hi Andrew,

> 
> That is not what i have seen in practice. Because the metric is good,
> and does not degrade, 

The missing degradation is the part where I don't agree.

Just to be sure we are understanding each other, I am talking about the
scenario depicted in this picture:

http://www.open-mesh.org/attachments/download/52/triangle.png

'A' is the source node and 'B' is our destination. B moves and breaks
the line-of-sight with A, thus making the A<->B link unusable at all (we
assume that now packet loss on A<->B is 100%).

At this point A still receives B's OGMs via N1.

According to batadv_iv_ogm_orig_update() (in bat_iv_ogm.c) each time a
packet with a _new_seqno_ is received the global window of _each_
neighbour for the given originator is shifted by one slot and the
averages are computed again.

This operation makes the average degrade because we are now averaging
N-1 old values and one 0 (with N being the size of the global window).
On the next OGM it will be worse: average on N-2 values and two 0s. And
so on..

Doesn't this mean that the metric is degrading (consider that the metric
is the average)?

Later in the same function, after having shifted all the windows and
recomputed all the averages, batman-adv checks if the route switch can
now happen:

1076   if (router_ifinfo->bat_iv.tq_avg > neigh_ifinfo->bat_iv.tq_avg)

(tq_avg of the current router is compared to tq_avg of the neighbour
from which we have received the OGM)

At some point this condition will evaluate to false.

> it stays as the best route. That is one of the
> reasons Linus developed NDP while at Ascom.
>

Of course the current mechanism is far from being "fast", therefore we
all wait for NDP/ELP to make the whole thing much more responsive :-)


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Andrew Lunn]

> Hi Andrew,
> 
> > 
> > That is not what i have seen in practice. Because the metric is good,
> > and does not degrade, 
> 
> The missing degradation is the part where I don't agree.
> 
> Just to be sure we are understanding each other, I am talking about the
> scenario depicted in this picture:
> 
> http://www.open-mesh.org/attachments/download/52/triangle.png

Thanks for the diagram. Yes, Linus and I had a somewhat similar setup.
We had more nodes involved, and B was walking around the inside of a
building.
 
> 'A' is the source node and 'B' is our destination. B moves and breaks
> the line-of-sight with A, thus making the A<->B link unusable at all (we
> assume that now packet loss on A<->B is 100%).
> 
> At this point A still receives B's OGMs via N1.
> 
> According to batadv_iv_ogm_orig_update() (in bat_iv_ogm.c) each time a
> packet with a _new_seqno_ is received the global window of _each_
> neighbour for the given originator is shifted by one slot and the
> averages are computed again.
 
It is a couple of years since Linus investigated this. So maybe things
have changed. If it does work like this, great, that helps solves a
problem we had. I don't currently have access to a system to test this
though.

	Andrew

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

[whangarei & opua]

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

On 20.02.2014, at 10:09, Antonio Quartulli wrote:

> Why don't you send this numbers to the ML as well? :)
>
> On 20/02/14 09:00, whangarei & opua wrote:
>> Hi Antonio,
>>
>> have found the output of such a case in my scrollback buffer of the
>> terminal.
>> Have also set hop_penalty to a high value, so don't worry about  
>> some 0
>> TQ values in alternative routes.
>> Please look at the TQ of 101, that will never change...
>
> You have to give these nodes a name: e.g. who is the destination you  
> are
> looking at? who are the direct neighbours you have towards this  
> destination?
>
> Otherwise I cannot understand.
>

The setup is like this:
whangarei is my router, it has one Wlan link to each of this 3  
neighbor router, MAC in the grep, hostname as comment.
This 3 routers are in one large building (across a park) but sometimes  
don't see each other. 2 of them have VPN connects.
I've looked only to the next hop, by grep the lines beginning with the  
MAC of this neighbor routers.
The intension was to get a better feeling of the link quality then  
with the 'iw dev wlan0-1 station dump' output.
So i have observed this behavior...

Have attached the router output as a file, it should be more readable.


[-- Attachment #2: whangarei.txt --]
[-- Type: text/plain, Size: 9338 bytes --]


root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed    3.070s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    5.810s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]: a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95   31.150s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed    7.510s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b   10.230s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]: a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95   35.580s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed    9.460s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b   12.190s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]: a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95   37.540s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   10.780s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b   13.500s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]: a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95   38.850s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   11.840s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b   14.560s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]: a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95   39.910s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   14.700s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    2.320s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    2.680s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   17.580s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    5.210s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    5.590s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   18.860s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    6.480s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    6.850s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   19.850s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    7.470s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    7.840s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   20.730s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    8.370s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    8.740s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   21.900s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    9.520s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    9.910s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]: 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   28.570s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    1.380s   ( 90) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 80) 76:ea:3a:d6:1d:6b ( 90)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    1.320s   ( 89) 66:66:b3:64:fe:95 [   wlan0-1]: a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95 ( 89)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   30.270s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    3.090s   ( 90) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 80) 76:ea:3a:d6:1d:6b ( 90)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    3.030s   ( 89) 66:66:b3:64:fe:95 [   wlan0-1]: a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95 ( 89)
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   32.680s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    0.310s   ( 91) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 83) 76:ea:3a:d6:1d:6b ( 91)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    0.640s   ( 93) 66:66:b3:64:fe:95 [   wlan0-1]: a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95 ( 93) 
root@whangarei:~#  
root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed # Black-Mesa-Research-Facility
a2:f3:c1:75:6a:ed   39.560s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]: 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed (101)
root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
76:ea:3a:d6:1d:6b    2.130s   ( 91) 76:ea:3a:d6:1d:6b [   wlan0-1]: a2:f3:c1:75:6a:ed ( 86) 76:ea:3a:d6:1d:6b ( 91)
root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 # Kuchenchef-3000
66:66:b3:64:fe:95    2.480s   ( 99) 66:66:b3:64:fe:95 [   wlan0-1]: a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95 ( 99)
root@whangarei:~#  

[-- Attachment #3: Type: text/plain, Size: 11015 bytes --]





>>
>> By,
>> Joe
>>
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed    3.070s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    5.810s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95   31.150s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed    7.510s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b   10.230s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95   35.580s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed    9.460s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b   12.190s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95   37.540s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   10.780s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b   13.500s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95   38.850s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   11.840s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b   14.560s   ( 78) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 78) 76:ea:3a:d6:1d:6b ( 75)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95   39.910s   ( 78) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 78)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   14.700s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    2.320s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    2.680s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   17.580s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    5.210s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    5.590s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   18.860s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    6.480s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    6.850s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   19.850s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    7.470s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    7.840s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   20.730s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    8.370s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    8.740s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   21.900s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    9.520s   ( 81) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 79) 76:ea:3a:d6:1d:6b ( 81)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    9.910s   ( 84) 66:66:b3:64:fe:95 [   wlan0-1]:
>> 76:ea:3a:d6:1d:6b (  1) 66:66:b3:64:fe:95 ( 84)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   28.570s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    1.380s   ( 90) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 80) 76:ea:3a:d6:1d:6b ( 90)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    1.320s   ( 89) 66:66:b3:64:fe:95 [   wlan0-1]:
>> a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95  
>> ( 89)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   30.270s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    3.090s   ( 90) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 80) 76:ea:3a:d6:1d:6b ( 90)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    3.030s   ( 89) 66:66:b3:64:fe:95 [   wlan0-1]:
>> a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95  
>> ( 89)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   32.680s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    0.310s   ( 91) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 83) 76:ea:3a:d6:1d:6b ( 91)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    0.640s   ( 93) 66:66:b3:64:fe:95 [   wlan0-1]:
>> a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95  
>> ( 93)
>> root@whangarei:~#
>> root@whangarei:~# batctl o | grep ^a2:f3:c1:75:6a:ed #
>> Black-Mesa-Research-Facility
>> a2:f3:c1:75:6a:ed   39.560s   (101) a2:f3:c1:75:6a:ed [   wlan0-1]:
>> 66:66:b3:64:fe:95 (  0) 76:ea:3a:d6:1d:6b (  0) a2:f3:c1:75:6a:ed  
>> (101)
>> root@whangarei:~# batctl o | grep ^76:ea:3a:d6:1d:6b # Kundenzentrum
>> 76:ea:3a:d6:1d:6b    2.130s   ( 91) 76:ea:3a:d6:1d:6b [   wlan0-1]:
>> a2:f3:c1:75:6a:ed ( 86) 76:ea:3a:d6:1d:6b ( 91)
>> root@whangarei:~# batctl o | grep ^66:66:b3:64:fe:95 #  
>> Kuchenchef-3000
>> 66:66:b3:64:fe:95    2.480s   ( 99) 66:66:b3:64:fe:95 [   wlan0-1]:
>> a2:f3:c1:75:6a:ed (  3) 76:ea:3a:d6:1d:6b (  2) 66:66:b3:64:fe:95  
>> ( 99)
>> root@whangarei:~#
>>
>> On 19.02.2014, at 23:30, Antonio Quartulli wrote:
>>
>>> On 19/02/14 23:12, whangarei & opua wrote:
>>>> 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? :(
>>>>
>>>
>>> I think this is something that is part of batman-adv since the  
>>> beginning
>>> (somebody else can confirm this).
>>>
>>>> Or I'm a little bit blind, sometimes, maybe? ;-)
>>>
>>> I have the feeling that you are not looking at the right entry in  
>>> the
>>> originator table :-)
>>>
>>>
>>> You may want to report some output/real numbers (at different  
>>> times) so
>>> that we can comment on those.
>>>
>>>
>>> Cheers,
>>>
>>> -- 
>>> Antonio Quartulli
>>>
>>
>
>
> -- 
> Antonio Quartulli
>

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

[Marek Lindner]

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

On Thursday 20 February 2014 10:44:37 Antonio Quartulli wrote:
> The missing degradation is the part where I don't agree.
> 
> Just to be sure we are understanding each other, I am talking about the
> scenario depicted in this picture:
> 
> http://www.open-mesh.org/attachments/download/52/triangle.png
> 
> 'A' is the source node and 'B' is our destination. B moves and breaks
> the line-of-sight with A, thus making the A<->B link unusable at all (we
> assume that now packet loss on A<->B is 100%).
> 
> At this point A still receives B's OGMs via N1.
> 
> According to batadv_iv_ogm_orig_update() (in bat_iv_ogm.c) each time a
> packet with a _new_seqno_ is received the global window of _each_
> neighbour for the given originator is shifted by one slot and the
> averages are computed again.
> 
> This operation makes the average degrade because we are now averaging
> N-1 old values and one 0 (with N being the size of the global window).
> On the next OGM it will be worse: average on N-2 values and two 0s. And
> so on..
> 
> Doesn't this mean that the metric is degrading (consider that the metric
> is the average)?

Your explanation is mostly correct - one minor objection though: Values of '0' 
are not considered when the global average is computed (bat_iv_ogm.c line 73). 
The idea being: The unilateral degradation of TQ values without any network 
event will eventually lead to loops.
Nonetheless, the general idea of your statement still holds true: Since new 
sequence numbers keep coming in via an alternative, albeit less optimal route, 
the stale route will be purged as soon as the global TQ window has elapsed 
(default: 5 seqnos). Long before the neighbor timeout has had the time to 
purge the neighbor entirely.

@Andrew: The algorithm always worked that way. In fact, it was your suggestion 
to reduce the global window to 5 seqnos in order to speed it up. 
Furthermore, ELP only improves reaction time on a local basis (single hop 
neighborhood). Network-wide route updates are as slow as before which is why 
we had to devise yet-another-improvement: RIP
http://www.open-mesh.org/projects/batman-adv/wiki/RIP

Cheers,
Marek

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

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

[Marek Lindner]

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

On Thursday 20 February 2014 11:20:01 whangarei & opua wrote:
> The setup is like this:
> whangarei is my router, it has one Wlan link to each of this 3  
> neighbor router, MAC in the grep, hostname as comment.
> This 3 routers are in one large building (across a park) but sometimes  
> don't see each other. 2 of them have VPN connects.
> I've looked only to the next hop, by grep the lines beginning with the  
> MAC of this neighbor routers.
> The intension was to get a better feeling of the link quality then  
> with the 'iw dev wlan0-1 station dump' output.
> So i have observed this behavior...
> 
> Have attached the router output as a file, it should be more readable.

Unfortunately, the information you provided isn't comprehensive enough to 
comment on your case. Please take a look at bat-hosts to have meaningful names 
in your originator table. Furthermore, we need a clear description of your 
setup for what the routing concerns. You can take a look at our routing 
scenarios page to get a feeling what we usually work with:
http://www.open-mesh.org/projects/open-mesh/wiki/Routing_scenarios

A diagram is no must but certainly helpful.

As soon as we have a clearer understanding of how your setup looks like, you 
can explain what behavior you see and what you would expect, plus originator 
tables from each node involved.

Cheers,
Marek

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

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

[whangarei & opua]

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


On 22.02.2014, at 14:20, Marek Lindner wrote:

> On Thursday 20 February 2014 11:20:01 whangarei & opua wrote:
>> The setup is like this:
>> whangarei is my router, it has one Wlan link to each of this 3
>> neighbor router, MAC in the grep, hostname as comment.
>> This 3 routers are in one large building (across a park) but  
>> sometimes
>> don't see each other. 2 of them have VPN connects.
>> I've looked only to the next hop, by grep the lines beginning with  
>> the
>> MAC of this neighbor routers.
>> The intension was to get a better feeling of the link quality then
>> with the 'iw dev wlan0-1 station dump' output.
>> So i have observed this behavior...
>>
>> Have attached the router output as a file, it should be more  
>> readable.
>
> Unfortunately, the information you provided isn't comprehensive  
> enough to
> comment on your case. Please take a look at bat-hosts to have  
> meaningful names

At the time I capture the output I was not aware about bat-hosts. :(

> in your originator table. Furthermore, we need a clear description  
> of your
> setup for what the routing concerns. You can take a look at our  
> routing
> scenarios page to get a feeling what we usually work with:
> http://www.open-mesh.org/projects/open-mesh/wiki/Routing_scenarios
>

Sorry, it's a little bit more complex setup, so I draw a diagram. Now  
my router mounted outside and the signal is much better, so only  
shorter times (<20 sec) without receiving update packets are  
displayed. Connection is good at the moment, but expect problems again  
after april, because of leaves on the trees, maybe together with rain.


> A diagram is no must but certainly helpful.
>
> As soon as we have a clearer understanding of how your setup looks  
> like, you
> can explain what behavior you see and what you would expect, plus  
> originator
> tables from each node involved.

Sorry, have no access to the neighbor router, it's a live environment.

>
> Cheers,
> Marek


Don't think there is any routing-protocol issue, what you maybe expect.
It's out of question, the WLan connection was very poor at this time.
Links #1 - #3 (on the drawing) are up for approx. 90% over a week,  
while #4 maybe 50% and #5 + #6 maybe 30%.
This means, my neighbors are only seeing each other sometimes  
directly, so I also expect there high packet loss, sometimes.

I have observed that a TQ entry from a direct neighbor will be  
present, also it has a last seen time of up to 180 sec, maybe more.
My suggestion is to reduce the TQ in such a case over the time,  
because this link can't be reliable, at least not bidirectional.
In my output you can see, it will not be happen now and there are very  
high last seen times.

Off cause, I have not monitored where traffic to outer (not directly  
connected) destinations go through...
Because it's layer 2 I don't expect to see something like a default  
gateway, which is easy to monitor.
As written earlier, I was not looking for routing issues.

It will be nice to be able to configure the dead timeout on the local  
router, maybe like it works with the hop_penalty.
Also I miss some possibilities to do some kind of traffic management,  
for example decrease / increase the TQ of incoming updates on a  
neighbor basis on the local router.
In my case I know, that one link is more reliable over the time than  
other ones, but have not found any way to priories it. (I don't talk  
about static routing.)

Have a nice day,
Joe




[-- Attachment #2: skitze.pdf --]
[-- Type: application/pdf, Size: 24601 bytes --]

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