Despite what's addressed in the patches, I left some devices untouched which show strange setup:
onion,omega2 / onion,omega2p :
mtd-mac-address = <&factory 0x28>;
wan_mac=$(mtd_get_mac_binary factory 4)
lan_mac=$(mtd_get_mac_binary factory 46)

Three addresses are used (strange thing no. 1: why are lan AND wan different from &ethernet).
But the device is set up as one-port (strange thing no. 2):

		ucidef_add_switch "switch0"
		ucidef_add_switch_attr "switch0" "enable" "false"
		ucidef_set_interface_lan "eth0"

Multiple examples can be found for both cases.

Rebased.

@dangowrt
Hi, I'm currently reviewing the MAC address assignment on ramips target.
You added support for zbt-we1226 some while ago, and set &ethernet to <&factory 0x2e>, with WAN address just calculated by adding +1 to that.
However, there might be another MAC address stored on flash for the device in <&factory 0x28>.

Can you check that? If yes, I would also be interested in which of the two addresses should be "lan" and which "wan" then ...

@pepe2k
Hi, I'm currently reviewing the MAC address assignment on ramips target.
You added support for ALFA Network AC1200RM some while ago, and set &ethernet to <&factory 0x28>, with WAN address just calculated by adding +1 to that.
However, there might be another MAC address stored on flash for the device in <&factory 0x2e>.

Can you check that? If yes, I would also be interested in which of the two addresses should be "lan" and which "wan" then ...

@pepe2k Same question for u7628-01-xxx devices.

For later reference: Discussion about newifi devices can be found here: #2075 (comment)

Rebased.

@981213 @blocktrron
I do not think there will be a lot of additional feedback here, so have a look at this if you like.
It contains several fixes/improvements besides changing the default-case logic.

(Latest Update: Rebase and account for recently added devices)

@zorun
I'm currently looking into the MAC address assignment of several ramips devices (#2319).
Many of them just have the wan MAC address calculated although it is stored on flash.

As you happen to own a ZBT WE3526, can you check whether you have a MAC address in <&factory 0xe006> and whether it matches your wan (eth0.2) MAC address? If you could provide a hexdump of your factory partition, this would be even better ...

@zorun
I'm currently looking into the MAC address assignment of several ramips devices (#2319).
Many of them just have the wan MAC address calculated although it is stored on flash.

As you happen to own a ZBT WE3526, can you check whether you have a MAC address in <&factory 0xe006> and whether it matches your wan (eth0.2) MAC address? If you could provide a hexdump of your factory partition, this would be even better ...

So, here it is:

• MAC address on the label: 78:A3:51:30:18:F8
• MAC address on eth0.1 (LAN): 78:A3:51:30:18:FA (with OpenWrt r10865-c3a78955f3)
• MAC address on eth0.2 (WAN): 78:A3:51:30:18:FB (with OpenWrt r10865-c3a78955f3)

The data at 0xe000 is 78 a3 51 30 18 fa, and data at 0xe006 is 78 a3 51 30 18 fb.

Here are the MAC addresses I spotted in the factory partition:

• 0x0004: 78 a3 51 30 18 f8 (the one from the label)
• 0x8004: 78 a3 51 30 18 f9
• 0xe000: 78 a3 51 30 18 fa
• 0xe006: 78 a3 51 30 18 fb

So, either the label is wrong, or the current OpenWrt location is wrong.

Here is the full hexdump if you find it useful: https://paste.swordarmor.fr/Z3Xg

What happens when a device does not match any case? I.e. wan_mac / lan_mac is not defined?

@zorun

If set up at all, wan will be some ethY.2 and lan will be some ethX.1, where in most cases ethX and ethY will be eth0. So, ethX.1 will inherit the MAC address from ethX and ethY.2 will inherit the MAC address from ethY. If you set lan_mac or wan_mac, you overwrite this inherent MAC address.
That's why it makes no sense to set BOTH lan_mac and wan_mac, as then the address from eth0 will be completely unused. Also setting eth0.2 to eth0 address makes no sense here.
Note that you do only set the ethX.Z, not the lan/wan bridge/device directly ...

At the moment (without the patchset), if there is no specific definition for a device in 02_network, the default case will just set eth0 + 1 for it. This might be based on a frequent case, but I think it has several drawbacks, so my first patch here changes the default case to be what one would expect: no change to the MAC addresses if you do not set one.

The other patches then fix and enhance stuff. Note that some of those changes are only possible after the default case has been removed.

This patch is really hard to review because you bundle several changes together...

I have thought about that, but I doubt it will be easier with more patches after all. However, I think about giving more details in the commit message for the big patches ...

MAC address on eth0.2 (WAN): 78:A3:51:30:18:FB (with OpenWrt r10865-c3a78955f3)

0xe006: 78 a3 51 30 18 fb

Well, that's what I wanted to know. So, the wan address can actually be read from 0xe006 instead of calculating it.

So, either the label is wrong, or the current OpenWrt location is wrong.

0x0004 and 0x8004 are used for Wifi when reading caldata from 0x0000 and 0x8000, so everything looks correct there to me. Or are you referring to something else?

Thank you very much for the detailed information.

Added we1326.

Sent the following two patches to the list, as they are simple fixes and independent of the other changes here:

• ramips: remove duplicate case for MAC setup of freestation5
• ramips: fix duplicate network setup for dlink,dir-615-h1

Hi! I'm a bit skeptical about this: ramips: remove default case for MAC address assignment

This is not desirable, as many device supporters will just not
care or know about this definition, so another MAC address will be
introduced by accident. In some cases the wan_mac is assigned
although it is not needed, in other cases even addresses not
dedicated to the device will be used

Those developers who are aware of this problem will add correct definition, and those who don't care will just add their device into the largest case anyway. In the end we just bloat 02_network a bit and still have to explicitly ask PR/patch authors to check mac address assignments when they use wan_mac = lan_mac + 1

BTW I'd be happy to merge the rest of this PR if you could move this commit down to the last one :)

@981213 Thanks for the response.

In the end we just bloat 02_network a bit and still have to explicitly ask PR/patch authors to check mac address assignments when they use wan_mac = lan_mac + 1

Well, that's part of what I want to achieve, since I have the feeling that almost nobody really cares about the MAC assignment. In this situation, I prefer that the event leading to another MAC address occupied requires more work than the event where nothing is changed.

But despite that, note that especially patch 2 here is based on having the default case removed:
With the default changed, I can remove entire blocks that do not set anything in patch 2. If the "old" default case remained, I would have to introduce a "do nothing" case into 02_network, just to prevent devices falling into the default and having wan set to lan+1 although that's not correct.
While this "do nothing" case might be considerably smaller that the lan+1 case, it still feels wrong to me to have an "empty" case where the default case does something different.
As already mentioned, this will have the counter-intuitive effect that removing a case will not result in having no MAC address changes, but in having just different address changes (lan+1).

So I'm still deeply convinced that having the default case swapped is the proper solution here.

BTW I'd be happy to merge the rest of this PR if you could move this commit down to the last one :)

Since this won't hurt too much, I will try to do that during the day. This will then introduce the "do nothing" case which will be removed again in the final patch. Maybe by that it will also become a little more obvious what my desire is in this context.

@981213 I have changed patch order as requested (including the necessary adjustments).

Thanks for merge.
Rebased and updated the rest.

@981213 I've backported the most important fixes and sent them to the list...

Rebased.

Change for youhua,wr1200js has been sent to list as separate patch.

Rebased and adjusted due to unielec rename.

@981213 I personally still think that the wan MAC assignment patch here would be an improvement.
I've rebased the patch onto the base-files split, so it is now distributed on the 6 new 02_network files.

Since you have been skeptical about it and justified your view, I want to give you the chance to veto on merging this patch before I push it.

I will merge this today.