On Tue, Jun 26, 2012 at 11:18:29PM +0200, Sven Eckelmann wrote:
I am not 100% sure because I haven't checked the code, but couldn't it be the case that we send random bits inside reserved at the moment? At least I cannot remember the part of the code that initialized reserver to any specific value. That would make the change incompatible with older batman-adv version.
Damn, that's true! It is not initialised anywhere.... What if I append a new field to the roam_adv_packet struct? Old version will ignore it and there is no size check to drop packets longer than expected.
Cheers,
On Wed, Jun 27, 2012 at 08:30:22AM +0200, Antonio Quartulli wrote:
On Tue, Jun 26, 2012 at 11:18:29PM +0200, Sven Eckelmann wrote:
I am not 100% sure because I haven't checked the code, but couldn't it be the case that we send random bits inside reserved at the moment? At least I cannot remember the part of the code that initialized reserver to any specific value. That would make the change incompatible with older batman-adv version.
Damn, that's true! It is not initialised anywhere.... What if I append a new field to the roam_adv_packet struct? Old version will ignore it and there is no size check to drop packets longer than expected.
Ok, after discussing with Sven on irc I got to the point that it is simply better to skip this patch. Appending a new field would make the new code much more complicated (and ugly) because we have to consider that we could receive old packets with a smaller size (and they should not be dropped).
I think that the best solution is to remove this patch.
The idea in this code was to send the new TT_CLIENT_TEMP flag within the roam_adv so that the receiver node can eventually purge this entry if not claimed anymore. However this is not needed because a roaming client is already marked as ROAM on the receiver side and so it will already be purged if not claimed within a fixed amount of time.
Cheers,
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli