raspberypi-kernel update of 2019-05-18 spoofed my mac address

[diveed]

After installing the update to the raspberrypi-kernel version 1.20190517-1 from version 1.20190401-1 my pi Zero started spoofing the mac address of my adapter.

To test that this update was the issue I did a clean install with the 2019-04-08 Rasbian-Stretch image. Put a hold on the raspberrypi-kernel update and install all the other updates.

I then ran ifconfig with the following results

pi@piz1-1:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.245 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 2601:987:8101:c3b::c6b7 prefixlen 128 scopeid 0x0
inet6 2601:987:8101:c3b:7d53:34ba:eea2:7ec2 prefixlen 64 scopeid 0x0
inet6 fe80::39e6:32af:8a1f:1035 prefixlen 64 scopeid 0x20
ether 00:0e:ba:01:89:2f txqueuelen 1000 (Ethernet)
RX packets 331 bytes 58111 (56.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 70 bytes 9935 (9.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I then installed the update and again ran ifconfig with the following results

pi@piz1-1:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.123 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 2601:987:8101:c3b::bce7 prefixlen 128 scopeid 0x0
inet6 2601:987:8101:c3b:66db:53af:1fd8:a480 prefixlen 64 scopeid 0x0
inet6 fe80::3f1c:4727:9446:907a prefixlen 64 scopeid 0x20
ether b8:27:eb:29:78:18 txqueuelen 1000 (Ethernet)
RX packets 156 bytes 22011 (21.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 267 bytes 40604 (39.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Note the change in MAC address from 00:0e:ba:01:89:2f to b8:27:eb:29:78:18
since b8:27:eb is an OUI of the Raspberry Pi Foundation I don't think this is a Debian issue
I have another Pi Zero and the issue seems to only occur with USB device I am using in this one. lsusb gives following report

pi@piz1-1:~ $ lsusb
Bus 001 Device 006: ID 1a2c:2124 China Resource Semico Co., Ltd
Bus 001 Device 008: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch
Bus 001 Device 007: ID 0557:8021 ATEN International Co., Ltd CS1764A [CubiQ DVI KVMP Switch]
Bus 001 Device 005: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0b95:772a ASIX Electronics Corp. AX88772A Fast Ethernet
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

My router shows it connected as
Host On piz1-1-20 B8:27:EB:29:78:18 Ethernet
note -20 appended to network name. This number increments by 1 every time the Zero is rebooted.

[diveed]

I now think my router is appending the counter. Since it has been receiving connections from devices with the same name but different mac addresses, it is adding the number to show a different device with the same name.

[pelwell]

I can't see an obvious reason why the MAC address handling would have changed between the two releases. If you have some time to investigate this, could you, for both releases:

1. Post the content of /proc/cmdline.

2. Run tar zcf dt.tgz -C /proc/device-tree . and upload the files somewhere I can download them.

[diveed]

before update
pi@piz1-1:~ $ cat /proc/cmdline
bcm2708_fb.fbwidth=1600 bcm2708_fb.fbheight=900 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=f696b84d-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

[pelwell]

I suspect I've found the cause: 03fc5d4

Author: Marcel Ziswiler <[email protected]>
Date:   Tue Jul 3 17:06:49 2018 +0200

net: usb: asix: allow optionally getting mac address from device tree

    For Embedded use where e.g. AX88772B chips may be used without external
    EEPROMs the boot loader may choose to pass the MAC address to be used
    via device tree. Therefore, allow for optionally getting the MAC
    address from device tree data e.g. as follows (excerpt from a T30 based
    board, local-mac-address to be filled in by boot loader):
    
    /* EHCI instance 1: USB2_DP/N -> AX88772B */
    usb@7d004000 {
        status = "okay";
        #address-cells = <1>;
        #size-cells = <0>;
        asix@1 {
                reg = <1>;
                local-mac-address = [00 00 00 00 00 00];
        };
    };
    
    Signed-off-by: Marcel Ziswiler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

This patch prefers a MAC address in the Device Tree to that in the EEPROM. Fortunately, an all-zeroes MAC address is ignored by Linux; try adding "force_mac_address=00:00:00:00:00:00" to config.txt.

[diveed]

Adding "force_mac_address=00:00:00:00:00:00" works. Problem was isolated to this one Ethernet device I am using. I had tried two other USB to Ethernet adapters and they worked. The other two were Ethernet only, while the one with the problem has a three port hub built in. I will let you decide when to close this bug report.

[pelwell]

I'm happy that you have a solution, although it's not ideal. The real problem is caused by the fact that Pi Zero still doesn't have a dedicated .dtb file, instead borrowing that of the B+ with which it has a lot in common. Unfortunately the commonality doesn't include an unprogrammed SMSC Ethernet device in that position in the USB hierarchy.

The firmware has been looking for bcm2708-rpi-zero.dtb for over a year now, with the b-plus version as a fallback. I'll close this issue when the omission is remedied (shaving a few microseconds off the boot time...).

[pelwell]

Can you download and test this new Pi Zero dtb file? https://drive.google.com/file/d/1NzwRtYV4qzse0ucuJGj4YpgQXAT5fqEt/view?usp=sharing

Just copy it into /boot and reboot. You should find that nothing is broken, and that you no longer need the force_mac_address setting. If there are any issues, you can confirm which dtb is being loaded with:

$ sudo vcdbg log msg |& grep dtb

[diveed]

The file seems to totally disable the USB port. No communication through port at all. Even tried another USB hub with only a keyboard attached and couldn't log in. No response to keyboard. Applied power to hub and still no response. Removed file and USB port started working again.

[pelwell]

Thanks - I've obviously overlooked something. I'll get you a more functional version tomorrow.

[pelwell]

That's odd - bcm2708-rpi-zero.dtb works on the two Zeros I've tried, but they are both rev 1.3 boards. Using a working image, what does grep Revision /proc/cpuinfo report? The output from raspi-gpio get might also be useful.

[diveed]

Perhaps the file I'm downloading is corrupted. I also have two Zeros rev. 1.3 and tried it in both with same error. Noticed during boot I see an Exception stack error followed by three lines filled with 0's. this is occurring about 10 lines after a line containing the text "DWC_SPINLOCK_IRQREQUEST".

[pelwell]

Let's try again. Here's a freshly built, freshly uploaded version: https://drive.google.com/file/d/1pwEh4vUC01XIlyCavPANJVGO6po5Kikg/view?usp=sharing

Note that the link probably won't work with curl/wget etc. - you'll need a browser. The resulting file is 22947 bytes long with an md5sum of 6de19f2fe229f81b2b1629fed62c15d1.

[diveed]

Problem persists, Carefully watching the boot screen I can tell that the point I get the three lines of zero's should be listing USB input. On good boot without the file the first line has input usb keyboard in it.
I'm using the 2019-04-08 Raspbian-Stretch.img and the firmware date is Mar-27-2019

[pelwell]

Thanks again - I've been able to reproduce your findings. The problem is an incompatible change in the kernel & DTB (ironically, introduced to improve compatibility) that breaks the USB interrupt if only the DTB is updated.

I'm satisfied that updating the kernel with the DTB will work, so the necessary changes and the new DTB will be in the next release.

[diveed]

Glad to have been of some assistance. I'll let you close this issue when you are ready.

[diveed]

Just received a report of this happening on a Pi3B+. I had a trouble shooting message going on the Pi Forums ( https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=241423&p=1475585#p1475585 ). This might indicate the problem is bigger than I thought. Will try to get more information from person with the issue.

[popcornmix]

Latest rpi-update should have the fix.

[diveed]

Latest rpi-update fixed it for me. I did remove the work around from the config.txt file.