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.