IPv6 on Ben Nanonote

[EdorFaus]

On 06/18/2012 03:59 AM, David Kuehling wrote:
> WRT uniqueness of MAC addresses, I though about the same, but then came
> to realize that it'd still break: the user could use a bridge device to
> connect usb0 to eth0 on the ethernet level.  Then, if you have multiple
> nanonotes on the resulting bridged network, MAC addresses could collide.
>
> Unfortunately the same argument also applies to IPv6: if you configure
> the same, static IPv6 link-local address for multiple NanoNotes, then in
> a bridging configuration, where multiple NanoNotes are on the same link,
> you'd have a IPv6 address collision :/

Ooh, good point. I hadn't thought about that (and/or didn't realize that 
a bridged network still uses the original MAC addresses instead of that 
of the bridge)...

This is a pretty good reason to not use the same address for all of 
them, especially by default.

> The problem is, that NanoNote is not a NIC and doesn't have a dedicated
> EEPROM to save a unique MAC-address.  Once you flash two nanonotes with
> the same firmware, they'd be equal down to the MAC-address, possibly
> causing problems as described above.

Well, it's (sometimes) a virtual NIC... :P

Hmm. Is the bootargs area of the flash memory reset too, whenever the 
root/kernel is flashed? If not, that area can be used similarly to an 
EEPROM for this purpose.

IIRC this is how the OpenMoko Freerunner did it - it had a separate 
partition in the flash that included the assigned MAC address (and some 
other device specific settings maybe, not sure). (Though not all distros 
actually used it, at least at first.)

On 06/18/2012 04:55 AM, Xiangfu Liu wrote:
> All recently image included 'mtd.nn', and 'mtd.nn fw_setenv_default' run
> once after reflash.

This seems to indicate that, yes, the bootargs area will be reset - but 
maybe only by software, not by the flashing itself?

If so, the software could perhaps be modified to keep this setting if it 
is already set?


Either way, I'm now leaning more and more towards agreeing that Qi 
should not assign any "real" (OUI-based) MAC addresses to the NN at all.


However, like kyak suggested, we might still want to make it the default 
(or at least easier) to persist the randomly generated MAC address 
between boots, even if not across flashings - though maybe with an 
option to regenerate a new one in case the randomization managed to 
create a collision anyway... That last bit should be rare enough to not 
really be a priority though...

-- 
Regards,
Frode