`tp2bmc/board/tp2bmc/overlay/etc/setStaticNet.sh` hasn't been upgraded for 2.1.x interface renames

[srcshelton]

Describe the bug

tp2bmc/board/tp2bmc/overlay/etc/setStaticNet.sh still references eth0, even though it is executed (via S93startup) after S00dsa which renames eth0 to dsa.

I suspect that a simple edit of this script won't be sufficient, though, as in 2.1.x by the point it is executed the dsa interface will have had several links added to it, the additions of which would have to be repeated (or the ordering changed - I suspect that setStaticNet.sh needs to be called from S00dsa).

To Reproduce
Steps to reproduce the behavior:

1. Create /etc/tpi.cfg or /mnt/sdcard/tpi.ini with a MAC or IP override;
2. Reboot the BMC;
3. Neither the specified MAC (nor presumably IP, although I've not tested this) have been applied.

Expected behavior
The configured MAC or IP address should have been applied.

Versions
bmc version = v2024.05.1

[srcshelton]

N.B. Adding hwaddress ether yy:yy:yy:xx:xx:xx to /etc/network/interfaces doesn't seem to make any difference to the active MAC address either.

Also, /etc/collectd.conf also still references eth0 (albeit only in commented example stanzas).

[srcshelton]

(Following https://discord.com/channels/754950670175436841/754950670175436848/1337746606799192095)

To confirm you have an unprogrammed eeprom on your Turing Pi V2.4 board, ssh into the BMC and run tpi eeprom get. If the "factory serial", "product name" and "mac" fields have undefined values, the eeprom isn't programmed.

I'm a Kickstarter backer with a v2.4 board - I get:

$ tpi eeprom get
BoardInfo {
    reserved: "0xffff",
    crc32: "0xffffffff",
    header version: "65535",
    hardware version: "v31.31.63",
    factory date: "2202-10-05",
    factory serial: "����������������",
    product name: "����������������",
    mac: "ffffffffffff",
}
EEPROM checksum mismatch! read ffffffff, expected 9ac38e3d

... but my point is that there was a good (... or, at least, working!) solution to this right up to and including the v2.0.5 firmware release. I believe this to a regression in the new release - but I'm more than happy to manually hand-edit the BMC installation to fix this in the interim if necessary.

It currently looks as if I can set the desired MAC address in S00dsa, but this is lost by the time the boot-process hits S93startup - but if at that point I re-apply the new MAC to every interface which exists at this time (e.g. also ge0, ge1, node1-node4) then once the system has booted all of the interfaces show the new MAC address - but they all still show a permaddr of the Locally-Administrated default and, crucially, the DHCP request from the system comes from that LA address, rather than the specified one.

I can't see anywhere from which udhcpc is being called, so I'm rather stuck for how to proceed. If anyone would like to help figure this out, my two main questions right now are:

1. What is causing an override MAC address that in S00dsa is being applied to the eth0 interface (before being renamed) and then again to the dsa interface (post-rename) to have been lost by the time that S93startup is executed?

2. Where in the boot process is udhcpc invoked, and can this can perhaps be altered to ensure the intended MAC address is used instead?