[Olsr-dev] UUID plugin

[Henning Rogge]

On 06/05/2012 03:03 PM, Hans-Christoph Steiner wrote:
> On Jun 5, 2012, at 2:33 AM, Henning Rogge wrote:
>> Dependencies between plugins are a real pain in OLSRd at the
>> moment. And constantly changing the MAC sounds like a good way to
>> shoot yourself in the foot. ;)
>
> Depends on what you mean by "constantly".  I was thinking that before
> associating with a network, the device can randomize the MAC.  That
> way it should make it much harder to track a given device has it hops
> around from network to network and back.  I can't see anything there
> that would shoot my feet.  This would be primarily for mobile
> devices.
>
>> There is also the problem that generating an UUID is not trivial on
>> simple embedded hardware. If you cannot trust the MAC and the IP,
>> there is not much you can use to generate a good UUID.
>
> If it uses the MAC and IP on the first time it generates it, then the
> UUID is saved to a file, that seems like a workable method.

Generating one during boot sounds like a sane solution. Still, you need 
to be prepared to have a MAC collision.

> As for cross-plugin communications, now that I think about this, it
> doesn't really need to be a plugin at all, but perhaps just a feature
> of jsoninfo.  If the file exists, jsoninfo will use its info.  And
> this file would be generated outside of olsrd.

Which would mean you cannot access the UUID through the txtinfo.

Maybe in case of the UUID it might make sense to store it in the core, 
because it could be also used as a seed (in addition to time) for all 
kind of randomness some plugins need.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120605/fdb86ec8/attachment.bin>