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.