[....]
Hm, I'm wondering what kind of overhead implications this could have in larger mesh networks.
Didn't TT support temporary entries? Could the gateway server inject them into its global translation table after parsing an incoming DHCP packet?
Right now we have the problem that DHCP requests (broadcasts by the user) are encapsulated by the gateway code in the wrong type of packet [1,2,3]. These are the unicast packets (non-4addr) which cannot be used to create temporary TT entries. This should be addressed by the first patch.
The second patch is currently only my bandaid (because I cannot patch all APs) and I would be more than happy when this patch is not required. So I would not object when this patch is rejected because it causes noise on the network.
For example gluon already accepted the first patch [4] and thus will hopefully not require the second patch anymore with 2016.2.0 for clients doing their DHCP Discover as broadcast.
Btw. the non-RFC version of the patch is here:
https://patchwork.open-mesh.org/patch/16377/
I have taken the freedom to move the reply to this patch.
Kind regards, Sven
[1] https://patchwork.open-mesh.org/patch/16376/ [2] https://git.open-mesh.org/batman-adv.git/blob/a36b7a3b08f4cc7c41103aa4db176a... [3] https://git.open-mesh.org/batman-adv.git/blob/a36b7a3b08f4cc7c41103aa4db176a... [4] https://github.com/freifunk-gluon/gluon/commit/93fe275000b65a4148d6a9713a030...