Guidelines - device MAC address assignment scheme

Background

I have an open PR for the Cudy M1800.
There are unique addresses for all interfaces (ethernet ports + both phys), so I just used those.
My reviewer made me aware that the stock firmware might be using a different assignment - and have the MAC address for the 5 GHz phy have a bit flipped in the fourth byte. Both are the case.
There's a precedent for sticking to the vendor assigment (even?) in such a case with the D-Link DIR-853-R1.
Assuming that this address is not reserved for the device by the vendor, I find myself having trouble to apply the "MAC address" policy in the wiki.

I want to propose a change of strategy (updating the guidelines).

MAC assigment instructions

From the wiki page about device support policies:

In general, it is safest to define MAC addresses the same way as the vendor does it on it's device. Don't invent your own MAC address assignment scheme.

This may produce overlapping MAC addresses e.g. for LAN and one WiFi interface for several vendors, but that's still better than having overlapping MAC addresses with another device when using OpenWrt in a network afterwards (consecutive addresses in real world networks do happen).

Re-phrasing that:

  1. Don't assign MAC addresses arbritarily. The vendor assignment scheme is a good reference, in general.

  2. Overlap of MAC addresses between devices is less desirable than overlap between interfaces (on one device).

The only real imperative is to use the vendor assignment.
"In general" implies there can be exemptions but there's no indication as to what they are.

Now, in my PR, the stock firmware assignment 1. feels pretty arbitrary (using the LAN address for one phy and flipping the fourth bit of the fourth byte for the other) and 2. it's definitely violating cross-device uniqueness of UAAs - despite every device having a block of eight MACs + two from wifi calibration.

In their current form, the guidelines don't put using the existing assignment scheme and avoiding cross-interface overlap in relation. It's only implied that avoiding cross-device overlap is the reason for the imperative.

I would prefer using the MACs from wifi calibration data for both phys but it hard to argue for or against it using the guidelines.

Proposal

I propose the following alteration to the section:

In general, try to define MAC addresses the same way they are defined in the pre-installed firmware. Try not inventing your own MAC address assignment scheme.
Avoid mapping MAC addresses that might be used by other devices. It's only a matter of time until two devices with consecutive addresses appear on the same network, so make sure they don't overlap.

To reduce MAC address overlap, identify which addresses are available:

  • For wifi interfaces, check if there are addresses in the wifi calibration data. Warning: They aren't necessarily unique to a single device!
  • Some boards have more than one MAC address assigned. Check the MTD, look for labels on the device, or compare MAC addresses of boards from the same batch. Some vendors also answer questions, so it can be worth asking them.
  • Overlapping MAC addresses e.g. for LAN and one WiFi interface is preferable to cross-device overlap. Again, look at how the vendor did it in their firmware.
    (If there are suitable addresses left, maybe try to reduce overlap between interfaces).

This way, the goals are clearer and there are more hints on how to proceed.

A more concise alternative:

  1. Preserve the uniqueness of MAC addresses
  2. Try to use existing paradigms to assign addresses

I would be happy to see Openwrt have stronger guidelines regarding the assingment of MAC addresses :slight_smile:
What do you think?

Maybe even port assignment.
Imho, with each device added to Openwrt, any vendor assignment scheme becomes less and less relevant.
Being an active user of 9 different devices from 3 different vendors, I much prefer consistency. I don't really care at all about the stock firmware. Compex, for example, has incosistent lan/lan and wan/lan assignments in one lineup. Cudy just asks the user how the ports should be used.