[....] > 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/a36b7a3b08f4cc7c41103aa4db176a11e965e068:/net/batman-adv/routing.c#l914 [3] https://git.open-mesh.org/batman-adv.git/blob/a36b7a3b08f4cc7c41103aa4db176a11e965e068:/net/batman-adv/soft-interface.c#l468 [4] https://github.com/freifunk-gluon/gluon/commit/93fe275000b65a4148d6a9713a030b0d30e6a9f1
signature.asc
Description: This is a digitally signed message part.
