ipq40xx: ea8300, mr8300: DSA: Adjust MAC addresses

[jeffsf]

At present, all four Ethernet phys associated with the lan0-3 ports are assigned the same MAC address. This causes MAC collisions that become problematic with more complex network configurations.

This patch assigns the "label MAC" to "wan" and the next sequential to "lan1". The MAC assigned to lan1 was used by the OEM firmware. lan2-4 are assigned locally administered MAC addresses, sequential from lan1 with its LA bit set. "eth0" is assigned the next in sequence, pushing the generated MACs above the range already in use.

label_mac is also defined and now available in board.json

NB: If MAC assignments are already present in /etc/config/network
they take precedence. These assignments may already be present
from an eariler boot sequence that generated the local config.

Tested-on: ea8300

Signed-off-by: Jeff Kletsky git-commits@allycomm.com

Thanks for your contribution to OpenWrt!

To help keep the codebase consistent and readable,
and to help people review your contribution,
we ask you to follow the rules you find in the wiki at this link
https://openwrt.org/submitting-patches

Please remove this message before posting the pull request.

[Znevna]

You have to stick to how badly the OEM configured the MAC addresses, sadly.
https://openwrt.org/docs/guide-developer/device-support-policies#mac_addresses

[robimarko]

Does the stock FW assign unique MAC-s per interface or its uses 2 MAC-s?

[jeffsf]

The stock firmware, as I very vaguely recall, only supported "LAN" and "WAN" configurations and did not support VLANs. It used the "label MAC" and the next in sequence.

There were significant problems with the pre-DSA and VLANs with the "wrong" MAC answering arp requests, especially in trunked VLAN applications where one of the VLANs was also present on the LAN ports of the switch. Hopefully that has been resolved with DSA.

Problems occur when using the device in a configuration other than a single device directly hard-wired to a port. As one example, consider an intermediate, L2 switch connected to two or more ports of the EA8300 and IP addresses assigned to the EA8300 bridges on various VLANs. That L2 switch would see the same MAC on each of its ports and be unable to distinguish between them.

Will "Joe Average" hit this these days when Ethernet cables past the modem-to-router connection have become replaced by local wireless in many situations? Probably not.

This mainly impacts developers and advanced users who wish to be able to manage network connectivity and/or monitor specific ports with an off-board switch.

[robimarko]

I get your point, however, so far policy has been that MAC-s should be identical to whatever the vendor assigned and that's it.

It would be good for others to chime in as well.

[jeffsf]

Based on @Znevna linking https://openwrt.org/docs/guide-developer/device-support-policies#mac_addresses
I can close this (or one of the maintainers can do so) and retain the changes locally.

[robimarko]

Let's keep it open for a day or two, I am interested in what is the maintainer's view on this.
Personally, I am not for changing the vendor assignment, but I am not a maintainer.

[jeffsf]

Seems reasonable.

Switching to DSA makes the device inherently different than OEM, at least for the ipq40xx and probably for other devices as well.

As OEM, there are effectively only two independently addressable phys in the system. Moving to DSA means that there are now five independently addressable phys in the system, one for each physical port.

With DSA, a user can easily assign a different upper-layer address to each of these phys. This is not something that could be done with OEM firmware, at least in this case.

With security awareness rising, even if slowly, segregation of low, moderate, and high-risk devices on different subnets and with different "firewall" policies may become more of the norm rather than the exception, at least for those using OpenWrt on their devices. The availability of relatively inexpensive CAT6 and faster cable, either compact for interior use or jacketed for exterior use makes linking of routers with cable easier to configure than wireless-mesh approaches and much more robust to weather. (Right now we're in the middle of storms and the 5 GHz link is intermittent and the 2.4 GHz link is too slow to support the use cases.)

[rmilecki]

I find it a custom thing and I don't think we should include this in OpenWrt repo.

It's a specific case that you need custom MAC addresses for LAN ports. There is no good solution for picking individual MACs that will fit all devices. I don't even think it's wise to do that by default. Most users expect to see device's default MAC address when connecting to any LAN port.