Hook for MAC address (802.15.4, maybe others)

[schlatterbeck]

It is sometimes useful to have a board-specific routine that can set the MAC address of a network interface. In our use-case it is for a board by Dresden Electronic that comes with a unique MAC for its 802.15.4 radio. But other use-cases (like using an EEPROM which you can buy with a unique mac address) are useful.

Link to our Dresden-Electronic module (which includes an ATMEGA RFR-2 with a 802.15.4 radio on chip):
https://www.dresden-elektronik.de/funktechnik/products/radio-modules/oem-derfmega/

When I mention an EEPROM with a pre-programmed MAC I mean something like this (available from different manufacturers, I've seen those used on cheap ARM boards (mostly running Linux) but they may end up in HW running RIOT, too:
https://www.microchip.com/design-centers/memory/serial-eeprom/mac-address-and-unique-id-eeproms

Of course other sources of MAC addresses are possible (configurable storage in an EEPROM, serial-number chip like one-wire, etc).

[miri64]

Welcome to the RIOT community @schlatterbeck. From #12592 (comment) I know, that you already are aware about the luid module as a potential MAC address source. This was mainly introduced because back then we did not really have any chip with a pre-set MAC address (or for those we had, like the samr21-xpro it did not really seem worth the effort of fetching it via proprietary protocols). There is nothing that speaks against introducing a hook that you ask for, the luid module (or an alternative) should however stay a fallback if there is no other source.

[schlatterbeck]

Thanks @miri64 for the welcome.
We're maintaining an experimental branch of riot on the osd-merkur-256 branch (with the intention to get this upstream when we've cleaned up a bit) at
https://github.com/osdomotics/RIOT/tree/osd-merkur-256
The board is based on the atmel atmega rfr2

There is an experimental commit
osdomotics@704c0ed
that factors out the mac-address generation and overrides it in a board-specific way.
This patch currently has the following shortcomings:

• Currently the mac generation is factored out only for drivers/at86rf2xx/at86rf2xx.c -- this would have to be done for all other drivers using this mechanism for MAC generation
• If a board has several network interfaces we need a way to find out for which interface the MAC is requested. We have found no good way (yet) how to find out which driver and which device is involved. There seems to be no info identifying a device, e.g., in netdev. So the interface for the mac computation probably must have some way to tell the board for which network interface a MAC is requested.

Comments very welcome!
Ralf + Marcus

[miri64]

(btw e.g. native's netdev_tap already uses a different source for the MAC address: the tap-device's MAC address)

[miri64]

Great to hear! The best approach to gather comments is either to advertise your fork on our devel mailing list and discuss it there or to provide a PR.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benpicco]

EUI provider is merged and configured for the board in question, so this can be closed. #14634 (comment)