Issue with DM200 and MAC Address on Boot

For Developers
1

Hi All,

I was wondering if someone could help me, you will have to excuse my ignorance!

I am trying to build a custom image for the Netgear DM200 which is based on the lantiq chips. I have managed this find and everything appeared to be ok but I noticed that every time I rebooted the MAC address was changing.

Digging further:

[    0.964611] libphy: lantiq,xrx200-mdio: probed
[    0.968743] net-xrx200: invalid MAC, using random

I spent all day trying to find the reason for this but I am really struggling. I found various patches from 2014 and earlier that suggest they fix this but I have no idea if they are part of the stable release or not?

Does anyone know where to begin looking at this? Can I some how change something as part of the build environment to point to the correct mtd location?

I know the MAC address is there it just can't seem to read it?

root@OpenWrt:~# hexdump -C /dev/mtd8 -s 0x1fe00 | head -n 1
00000000  3c 37 86 09 ce d4 3c 37  86 09 ce d5 ff ff ff ff

Thanks in advance
Andy

2

The DTS file is target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts and some devices' drivers can extract the MAC address directly.

For examples, fgrep mac target/linux/lantiq/files/arch/mips/boot/dts/* might provide further clues.

3

Thanks for the response Jeff, I guess this would mean I would need to compile from source rather than using imagebuilder?

Sorry I'm pretty new to this, surprised I managed to get a working image and didn't brick the device entirely!

4

Correct, the image builder assembles pre-compiled packages (including the kernel). Building from source would be required to make any changes to the packages themselves.

5

Thanks, I thought so! I was trying to avoid having to setup a full cross compiler? if thats the correct term

&eth0 {
	lantiq,phys = <&gphy1>;

	lan: interface@0 {
		compatible = "lantiq,xrx200-pdi";
		#address-cells = <1>;
		#size-cells = <0>;
		reg = <0>;

I guess I could do something bodgy once its booted and grep the hexdump to apply this but would rather not do that if I can avoid it...

6

You can't really change the DTB (compiled DTS) with raw editing.

The first-time build of the tool chain will take 15-40 minutes, depending on your CPU (the latter numbers are for a US$150-class SBC with a J4105 CPU). It seldom needs to be rebuilt. The first-time build of a full image (with, for example LuCI, nginx, OpenSSL) around 10-30 minutes. If you enable ccache under developer options (do this before your first build), subsequent rebuilds typically run 4-8 minutes, even adding a few packages.

7

Could it not be as simple as adding something along the lines of:

	reg = <0>;
		mtd-mac-address = <&romfile 0xf100>;

But obviously referencing the correct partitions etc and locations relevant to the DM200? Once thats done, recompile?

Again forgive my ignorance

8

fwiw, I'm not a developer, but I thought this issue has existed for years certainly for HH5A. I would presume other Lantiq devices have the same 'feature'.

Extract from my HH5A kernel log for LEDE 17.01.6 fyi:

[    1.064900] libphy: lantiq,xrx200-mdio: probed
[    1.077221] net-xrx200: invalid MAC, using random

[    1.143380] eth0: attached PHY [Lantiq XWAY PEF7071] (phy_addr=0:00, irq=-1)
[    1.211351] eth0: attached PHY [Lantiq XWAY PEF7071] (phy_addr=0:01, irq=-1)
[    1.279337] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1)

The simple workaround seems to be to include a macaddr entry for device 'wan_dev' in the /etc/config/network file which you will find included in stable and snapshot builds certainly for the HH5A :

config device 'wan_dev'
        option name 'ptm0'   # LEDE 17, dsl0 for 18.x
        option macaddr '90:4d:4a:3e:1b:6a'  #  Example

(I don't know how 'wan_dev' is created and populated with macaddr, but macaddr is different for every HH5A I've installed with LEDE/openwrt)

9

No "ignorance" on your part, I only know of this kind of thing from porting a couple of devices. That's the kind of thing I'd try myself. I don't know about the Lantiq drivers (or if reg = <0>; is required), but that would be the first thing I'd try.

The next would be to go with extracting and setting the MAC address in

target/linux/lantiq/base-files/etc/board.d/02_network
10

So a bit of background. I’m trying to build an image that will potentially be used by hundreds of these devices in an ISP environment rather than a single device otherwise I would go with that work around. I’m a network engineer rather than a coder, hence all the questions :joy:

I guess I could write something that set this on first boot in the config but would rather something persistent / more permanent if that makes sense. Something that actually is native to the OS/kernel rather than a script written by me.

I guess I’ll try editing those files / understand how device trees work and see if I can get it to map to the correct MAC in the MTD if no one else chimes in

Failing that, I’ll write something that does it on first boot and then kills itself. At least then I don’t have to manually configure the MAC on every device I build!

Cheers

Andy

12

02_network is pretty much the "OpenWrt-standard" way of handling network-device drivers that can't read directly from flash to get their MACs.

13

Thanks Jeff will take a look

Found this which is for the same chip I think:

That seems to have :

mtd-mac-address = <&boardconfig 0x16>;

Referenced under the LAN section.

I will try get a build environment set up, I'll be very surprised if just adding that works but worth a shot! Is there any documentation on how the DTS works, what is mtd-mac-address is this just a variable or something that is standard and known? I guess something must hook into that to actually use it?

14

So I've managed to get a build environment working. I've made the changes to the DTS faile and 02_Network to no avail.

Trawling through some of the files / scripts I have seen some includes to some libraries which include the functions I think the DTS is referring to, such as mtd_get_mac_binary(), they seem to be in /lib/functions/system.sh

I have gone through these and it looks like ultimately it calls hexdump. I have manually done this using the same syntax as whats in these functions and passed in the offset 00 rather than 0x16 and specified /dev/mtd8 which is the ART partition and it appears to work perfectly:

hexdump -v -n 6 -s 00 -e '5/1 "%02x:" 1/1 "%02x"' /dev/mtd8
3c:37:86:09:ce:d4root@OpenWrt:/lib/functions#

When I pass in 0x16 I get all FFs.

Does anyone know how this is called and what gets passed to these functions? I can only think the wrong offset is being passed through. I am just in the middle of recompiling now I have updated mtd-mac-address = <&boardconfig 0x16>; to mtd-mac-address = <&boardconfig 0x0>; But not sure if this will achieve what I am looking for.

I could be barking up the wrong tree entirely. Does anyone know how to debug the dts on boot? For example rather than saying invalid mac address in dmesg can I somehow dump what it has parsed to come to that conclusion?

Determined to crack this :smiley:

Cheers
Andy

15

Ha! Don't believe it! That's fixed it! Just tested the latest compile.

Adding in the mtd-mac-address and changing the offset to 0 worked perfectly! Now I guess, how does that get added / fixed permanently in the stable builds, or is it not something that would get included?

Cheers
Andy