[B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Robert Bates]

Hello,

Is it possible to have b.a.t.m.a.n. ARP if packets are received at bat0 for a client which has been removed/deleted due to timeout, and is therefore no longer in the translation tables?

In one customer application of a product of ours (a mesh AP we've licensed from another vendor/developer, which is based on openWRT/b.a.t.m.a.n.), we are being adversely affected by the 10 minute inactivity timer on transtable_local.   The clients in this customer's network/application are stationary devices which basically do not speak unless spoken to (e.g. when they are polled for data).  They are periodically polled by a management platform, using an upper layer protocol running over TCP.  The problem is that this customer's polling cycle time is variable, and occasionally it is taking longer than 10 minutes between successive polls of a given client/device.  When this happens, that client is of course removed from transtable_local, and transtable_global on the other nodes in the mesh.  Meanwhile, the polling/management platform has a very long ARP cache life, so it never ARPs (and apparently it is not possible on this platform to have the customer implement dynamic, rather than static ARP table entries, in which it would ARP upon polling failure).  So once we get into this state, polls to this client device which has dropped out of the mesh are not possible, and their management platform throws alarms, etc.  To bring it back in service at that point requires an ARP, which the customer is manually triggering with a ping, whenever one of these "outages" occurs.

We know that the transtable_local inactivity/removal timer value can be extended, and we will probably do that, but we would also like to know if it is possible to have b.a.t.m.a.n. ARP for the removed client in this case.  We prefer this approach, rather than arbitrarily changing the tt_local timer to some value which may not work well in some other customer's network/application.  I know that there is a statistically valid underlying assumption with this 10 minute inactivity timer on transtable_local, that clients will typically be "chatty".  But again, that is not the case in this application, which is a very common one in the industry in which we operate, where clients are very often fixed devices which only respond to explicit queries or commands.  This is a new product and protocol for us, and this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application.  We believe it can be; it would just be helpful if we can configure it to ARP in this type of scenario.

Can you please comment on how this might be possible (config or otherwise)?

Thanks very much,
Robert Bates

IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[dan]

> We know that the transtable_local inactivity/removal timer value can be extended, and we will probably do that, but we would also like to know if it is possible to have b.a.t.m.a.n. ARP for the removed client in this case.  We prefer this approach, rather than arbitrarily changing the tt_local timer to some value which may not work well in some other customer's network/application.  I know that there is a statistically valid underlying assumption with this 10 minute inactivity timer on transtable_local, that clients will typically be "chatty".  But again, that is not the case in this application, which is a very common one in the industry in which we operate, where clients are very often fixed devices which only respond to explicit queries or commands.  This is a new product and protocol for us, and this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application.  We believe it can be; it would just be helpful if we can configure it to ARP in this type of scenario.
>
> Can you please comment on how this might be possible (config or otherwise)?
>
> Thanks very much,
> Robert Bates


just a note, devices based on arduino with wifi or ethernet
shields/interfaces often behave this way, and MANY IoT devices do
based on other microcontrollers as a means to save battery.  So this
is going to be an increasingly common situation.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Simon Wunderlich]

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

On Friday, December 29, 2017 5:01:23 PM CET Robert Bates wrote:
> Hello,
> 
> Is it possible to have b.a.t.m.a.n. ARP if packets are received at bat0 for
> a client which has been removed/deleted due to timeout, and is therefore no
> longer in the translation tables?
> 
> In one customer application of a product of ours (a mesh AP we've licensed
> from another vendor/developer, which is based on openWRT/b.a.t.m.a.n.), we
> are being adversely affected by the 10 minute inactivity timer on
> transtable_local.   The clients in this customer's network/application are
> stationary devices which basically do not speak unless spoken to (e.g. when
> they are polled for data).  They are periodically polled by a management
> platform, using an upper layer protocol running over TCP.  The problem is
> that this customer's polling cycle time is variable, and occasionally it is
> taking longer than 10 minutes between successive polls of a given
> client/device.  When this happens, that client is of course removed from
> transtable_local, and transtable_global on the other nodes in the mesh. 
> Meanwhile, the polling/management platform has a very long ARP cache life,
> so it never ARPs (and apparently it is not possible on this platform to
> have the customer implement dynamic, rather than static ARP table entries,
> in which it would ARP upon polling failure).  So once we get into this
> state, polls to this client device which has dropped out of the mesh are
> not possible, and their management platform throws alarms, etc.  To bring
> it back in service at that point requires an ARP, which the customer is
> manually triggering with a ping, whenever one of these "outages" occurs.
> 
> We know that the transtable_local inactivity/removal timer value can be
> extended, and we will probably do that, but we would also like to know if
> it is possible to have b.a.t.m.a.n. ARP for the removed client in this
> case.  We prefer this approach, rather than arbitrarily changing the
> tt_local timer to some value which may not work well in some other
> customer's network/application.  I know that there is a statistically valid
> underlying assumption with this 10 minute inactivity timer on
> transtable_local, that clients will typically be "chatty".  But again, that
> is not the case in this application, which is a very common one in the
> industry in which we operate, where clients are very often fixed devices
> which only respond to explicit queries or commands.  This is a new product
> and protocol for us, and this could beg the question of whether or not
> b.a.t.man.-based meshing is the right solution in this type of application.
>  We believe it can be; it would just be helpful if we can configure it to
> ARP in this type of scenario.
> 
> Can you please comment on how this might be possible (config or otherwise)?

Hi Robert,

batman-adv does not ARP on its own, so there is no way to configure this.

You should either increase the timer from 10 minutes to something (reasonably) 
high, or have another program sending some frames to refresh the ARP on behalf 
of the client - e.g. every 5 minutes, read the transtable local, send a packet 
for each MAC. However, in my opinion, this is just a more round-abot way with 
possibly more pitfalls on its own.

A general way to handle this would be to send those unicasts unknown to 
batman-adv  as broadcasts. However, this would be problematic for networks 
with big broadcasts domains which already suffer from too high broadcast load, 
but have a sane ARP mechanism in place otherwise.

So long story short, increasing the timeout seems to be the most easy and 
effective solution to me.

Cheers,
     Simon

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

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Linus Lüssing]

Hi,

If I understood correctly then the ARP cache life on the
polling/management platform is larger than 10min. Would it
be an option for you to lower that one to some value below the
10min. translation table timeout? (the default for the
ARP/neighbor in Linux is a random value between 30-90 seconds
if I remember correctly)

Would that solve your issue?

Regards, Linus


On Fri, Dec 29, 2017 at 05:01:23PM +0000, Robert Bates wrote:
> Hello,
> 
> Is it possible to have b.a.t.m.a.n. ARP if packets are received at bat0 for a client which has been removed/deleted due to timeout, and is therefore no longer in the translation tables?
> 
> In one customer application of a product of ours (a mesh AP we've licensed from another vendor/developer, which is based on openWRT/b.a.t.m.a.n.), we are being adversely affected by the 10 minute inactivity timer on transtable_local.   The clients in this customer's network/application are stationary devices which basically do not speak unless spoken to (e.g. when they are polled for data).  They are periodically polled by a management platform, using an upper layer protocol running over TCP.  The problem is that this customer's polling cycle time is variable, and occasionally it is taking longer than 10 minutes between successive polls of a given client/device.  When this happens, that client is of course removed from transtable_local, and transtable_global on the other nodes in the mesh.  Meanwhile, the polling/management platform has a very long ARP cache life, so it never ARPs (and apparently it is not possible on this platform to have the customer implement dynamic, rather than static ARP table entries, in which it would ARP upon polling failure).  So once we get into this state, polls to this client device which has dropped out of the mesh are not possible, and their management platform throws alarms, etc.  To bring it back in service at that point requires an ARP, which the customer is manually triggering with a ping, whenever one of these "outages" occurs.
> 
> We know that the transtable_local inactivity/removal timer value can be extended, and we will probably do that, but we would also like to know if it is possible to have b.a.t.m.a.n. ARP for the removed client in this case.  We prefer this approach, rather than arbitrarily changing the tt_local timer to some value which may not work well in some other customer's network/application.  I know that there is a statistically valid underlying assumption with this 10 minute inactivity timer on transtable_local, that clients will typically be "chatty".  But again, that is not the case in this application, which is a very common one in the industry in which we operate, where clients are very often fixed devices which only respond to explicit queries or commands.  This is a new product and protocol for us, and this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application.  We believe it can be; it would just be helpful if we can configure it to ARP in this type of scenario.
> 
> Can you please comment on how this might be possible (config or otherwise)?
> 
> Thanks very much,
> Robert Bates
> 
> IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Linus Lüssing]

And one more question: How are the IPv4 addresses assigned? Static
configuration or via DHCP? If the latter, what is your current
lease timeout and would it be an option to lower it?

Regards, Linus


On Fri, Dec 29, 2017 at 05:01:23PM +0000, Robert Bates wrote:
> Hello,
> 
> Is it possible to have b.a.t.m.a.n. ARP if packets are received at bat0 for a client which has been removed/deleted due to timeout, and is therefore no longer in the translation tables?
> 
> In one customer application of a product of ours (a mesh AP we've licensed from another vendor/developer, which is based on openWRT/b.a.t.m.a.n.), we are being adversely affected by the 10 minute inactivity timer on transtable_local.   The clients in this customer's network/application are stationary devices which basically do not speak unless spoken to (e.g. when they are polled for data).  They are periodically polled by a management platform, using an upper layer protocol running over TCP.  The problem is that this customer's polling cycle time is variable, and occasionally it is taking longer than 10 minutes between successive polls of a given client/device.  When this happens, that client is of course removed from transtable_local, and transtable_global on the other nodes in the mesh.  Meanwhile, the polling/management platform has a very long ARP cache life, so it never ARPs (and apparently it is not possible on this platform to have the customer implement dynamic, rather than static ARP table entries, in which it would ARP upon polling failure).  So once we get into this state, polls to this client device which has dropped out of the mesh are not possible, and their management platform throws alarms, etc.  To bring it back in service at that point requires an ARP, which the customer is manually triggering with a ping, whenever one of these "outages" occurs.
> 
> We know that the transtable_local inactivity/removal timer value can be extended, and we will probably do that, but we would also like to know if it is possible to have b.a.t.m.a.n. ARP for the removed client in this case.  We prefer this approach, rather than arbitrarily changing the tt_local timer to some value which may not work well in some other customer's network/application.  I know that there is a statistically valid underlying assumption with this 10 minute inactivity timer on transtable_local, that clients will typically be "chatty".  But again, that is not the case in this application, which is a very common one in the industry in which we operate, where clients are very often fixed devices which only respond to explicit queries or commands.  This is a new product and protocol for us, and this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application.  We believe it can be; it would just be helpful if we can configure it to ARP in this type of scenario.
> 
> Can you please comment on how this might be possible (config or otherwise)?
> 
> Thanks very much,
> Robert Bates
> 
> IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Robert Bates]

Hi Simon,

Thanks for the reply.  I'd already proposed changing the timer value to my team (e.g., to 1 hour), and we're likely going to get that done (again, we license this product from another developer, and don't even have direct access to the code under our current arrangement).  I agree that it seems to be the most straight-forward solution, but others in the team feel that the desired fix will involve either some type of "ARP if unknown", or timer-based ARP mechanism on the part of some other component/piece of software.  I like your idea of periodically reading tt_local and pinging the clients.  I'm going to bring that up when we have the next in-person discussion about a fix (a few people are still out on holiday vacation).  I like the fact that with that approach, the additional traffic introduced is only toward locally connected clients, and not over the mesh.  Each node is doing this with its locally connected clients, circumventing timeout and removal.  I like it.  You mentioned some potential pitfalls.  We will talk through what those might look like in our customer environments, but my sense is that there is no significant downside.  I could wrong.

Thanks again.

Robert



-----Original Message-----
From: Simon Wunderlich [mailto:sw@simonwunderlich.de]
Sent: Sunday, December 31, 2017 6:19 AM
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: Robert Bates <rbates@freewave.com>
Subject: Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

On Friday, December 29, 2017 5:01:23 PM CET Robert Bates wrote:
> Hello,
>
> Is it possible to have b.a.t.m.a.n. ARP if packets are received at
> bat0 for a client which has been removed/deleted due to timeout, and
> is therefore no longer in the translation tables?
>
> In one customer application of a product of ours (a mesh AP we've
> licensed from another vendor/developer, which is based on
> openWRT/b.a.t.m.a.n.), we are being adversely affected by the 10 minute inactivity timer on
> transtable_local.   The clients in this customer's network/application are
> stationary devices which basically do not speak unless spoken to (e.g.
> when they are polled for data).  They are periodically polled by a
> management platform, using an upper layer protocol running over TCP.
> The problem is that this customer's polling cycle time is variable,
> and occasionally it is taking longer than 10 minutes between
> successive polls of a given client/device.  When this happens, that
> client is of course removed from transtable_local, and transtable_global on the other nodes in the mesh.
> Meanwhile, the polling/management platform has a very long ARP cache
> life, so it never ARPs (and apparently it is not possible on this
> platform to have the customer implement dynamic, rather than static
> ARP table entries, in which it would ARP upon polling failure).  So
> once we get into this state, polls to this client device which has
> dropped out of the mesh are not possible, and their management
> platform throws alarms, etc.  To bring it back in service at that
> point requires an ARP, which the customer is manually triggering with a ping, whenever one of these "outages" occurs.
>
> We know that the transtable_local inactivity/removal timer value can
> be extended, and we will probably do that, but we would also like to
> know if it is possible to have b.a.t.m.a.n. ARP for the removed client
> in this case.  We prefer this approach, rather than arbitrarily
> changing the tt_local timer to some value which may not work well in
> some other customer's network/application.  I know that there is a
> statistically valid underlying assumption with this 10 minute
> inactivity timer on transtable_local, that clients will typically be
> "chatty".  But again, that is not the case in this application, which
> is a very common one in the industry in which we operate, where
> clients are very often fixed devices which only respond to explicit
> queries or commands.  This is a new product and protocol for us, and
> this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application.
>  We believe it can be; it would just be helpful if we can configure it
> to ARP in this type of scenario.
>
> Can you please comment on how this might be possible (config or otherwise)?

Hi Robert,

batman-adv does not ARP on its own, so there is no way to configure this.

You should either increase the timer from 10 minutes to something (reasonably) high, or have another program sending some frames to refresh the ARP on behalf of the client - e.g. every 5 minutes, read the transtable local, send a packet for each MAC. However, in my opinion, this is just a more round-abot way with possibly more pitfalls on its own.

A general way to handle this would be to send those unicasts unknown to batman-adv  as broadcasts. However, this would be problematic for networks with big broadcasts domains which already suffer from too high broadcast load, but have a sane ARP mechanism in place otherwise.

So long story short, increasing the timeout seems to be the most easy and effective solution to me.

Cheers,
     Simon
IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Antonio Quartulli]

[-- Attachment #1.1: Type: text/plain, Size: 2067 bytes --]

Hi Robert,

On 05/01/18 09:16, Robert Bates wrote:
> Hi Simon,
> 
> Thanks for the reply.  I'd already proposed changing the timer value to my team (e.g., to 1 hour), and we're likely going to get that done (again, we license this product from another developer, and don't even have direct access to the code under our current arrangement).  I agree that it seems to be the most straight-forward solution, but others in the team feel that the desired fix will involve either some type of "ARP if unknown", or timer-based ARP mechanism on the part of some other component/piece of software.  

what do you exactly mean with "ARP if unknown"?
In theory the ARP packet should be sent exactly by that client that now
is unknown. Are you proposing some reactive discovery of unknown clients?

> I like your idea of periodically reading tt_local and pinging the clients.  I'm going to bring that up when we have the next in-person discussion about a fix (a few people are still out on holiday vacation).  I like the fact that with that approach, the additional traffic introduced is only toward locally connected clients, and not over the mesh.  Each node is doing this with its locally connected clients, circumventing timeout and removal.  I like it.  You mentioned some potential pitfalls.  We will talk through what those might look like in our customer environments, but my sense is that there is no significant downside.  I could wrong.

don't forget that this can get racy: when you iterate over the local
table, clients of your interest may have already disappeared (unless you
make the probe reliable and with interval shorter than the TT timeout).

At the same time, how do you distinguish between clients that have to be
pinged and clients that do not need that?

Another thing: consider that performing a simple ICMP ping from the mesh
node to the local client won't be enough, because no packet generated by
the client will enter the bat0 interface, thus it won't be detected by
batman-adv.


Cheers,



-- 
Antonio Quartulli


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

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Robert Bates]

Hi Antonio,

This "ARP if unknown" idea has been suggested within the group, and it was referring to the notion of seeing if it was possible to have batman ARP if it receives a packet on bat0 destined for a client which is not in tt_global.  I should not have mentioned that one, since Simon already confirmed that is not possible.  Another idea I have heard mentioned is to implement a timer-based ARP mechanism - again, by some other component in the path on our AP.   I'm not clear on exactly what the idea is there, or how it might work (need to sync up with that person once he's back from holiday).

Thanks for your other points.  Regarding the potential for it to become racy to periodically read tt_local and probe clients, yes, the idea is to do so every 5 minutes, for example.   We haven't discussed this much yet (for the same reasons - people are still out on holiday), but we would probably not attempt to distinguish between clients which need it, and those which do not.  Though I suppose we could implement some logic to do it only if last seen time is greater than some value.

Very interesting point about an ICMP ping to the local client not generating packets which will come back through the bat0 interface.  Hadn't considered that, thanks.  Would you have a suggestion for a different type of probe?

Thank you,
Robert


-----Original Message-----
From: Antonio Quartulli [mailto:a@unstable.cc]
Sent: Friday, January 5, 2018 12:39 AM
To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org>; Robert Bates <rbates@freewave.com>; Simon Wunderlich <sw@simonwunderlich.de>
Subject: Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

Hi Robert,

On 05/01/18 09:16, Robert Bates wrote:
> Hi Simon,
>
> Thanks for the reply.  I'd already proposed changing the timer value to my team (e.g., to 1 hour), and we're likely going to get that done (again, we license this product from another developer, and don't even have direct access to the code under our current arrangement).  I agree that it seems to be the most straight-forward solution, but others in the team feel that the desired fix will involve either some type of "ARP if unknown", or timer-based ARP mechanism on the part of some other component/piece of software.

what do you exactly mean with "ARP if unknown"?
In theory the ARP packet should be sent exactly by that client that now is unknown. Are you proposing some reactive discovery of unknown clients?

> I like your idea of periodically reading tt_local and pinging the clients.  I'm going to bring that up when we have the next in-person discussion about a fix (a few people are still out on holiday vacation).  I like the fact that with that approach, the additional traffic introduced is only toward locally connected clients, and not over the mesh.  Each node is doing this with its locally connected clients, circumventing timeout and removal.  I like it.  You mentioned some potential pitfalls.  We will talk through what those might look like in our customer environments, but my sense is that there is no significant downside.  I could wrong.

don't forget that this can get racy: when you iterate over the local table, clients of your interest may have already disappeared (unless you make the probe reliable and with interval shorter than the TT timeout).

At the same time, how do you distinguish between clients that have to be pinged and clients that do not need that?

Another thing: consider that performing a simple ICMP ping from the mesh node to the local client won't be enough, because no packet generated by the client will enter the bat0 interface, thus it won't be detected by batman-adv.


Cheers,



--
Antonio Quartulli

IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?

[Antonio Quartulli]

[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]

Hi Robert,

On 06/01/18 01:23, Robert Bates wrote:
> Hi Antonio,
> 
> This "ARP if unknown" idea has been suggested within the group, and it was referring to the notion of seeing if it was possible to have batman ARP if it receives a packet on bat0 destined for a client which is not in tt_global.  I should not have mentioned that one, since Simon already confirmed that is not possible.  Another idea I have heard mentioned is to implement a timer-based ARP mechanism - again, by some other component in the path on our AP.   I'm not clear on exactly what the idea is there, or how it might work (need to sync up with that person once he's back from holiday).
> 
> Thanks for your other points.  Regarding the potential for it to become racy to periodically read tt_local and probe clients, yes, the idea is to do so every 5 minutes, for example.   We haven't discussed this much yet (for the same reasons - people are still out on holiday), but we would probably not attempt to distinguish between clients which need it, and those which do not.  Though I suppose we could implement some logic to do it only if last seen time is greater than some value.
> 
> Very interesting point about an ICMP ping to the local client not generating packets which will come back through the bat0 interface.  Hadn't considered that, thanks.  Would you have a suggestion for a different type of probe?

If the "probing" software will be installed on each of your devices,
then they could periodically ping some kind of central GW in the
network. This would force a few unicast (and maybe broadcast) packets to
cross the mesh and thus refresh the tt_local entry.

I would imagine this probe as some sort of "client keep alive" that tell
the mesh "hey, I am still here".

Cheers,


-- 
Antonio Quartulli


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