IPv6 on Ben Nanonote
edorfaus at xepher.net
Mon Jun 18 15:06:22 EDT 2012
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...
More information about the discussion