search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.03k stars 4.95k forks source link

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

Closed diveed closed 5 years ago

diveed commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I suspect I've found the cause: 03fc5d4ffb0da005f0dce02d7c015821681e260c

Author: Marcel Ziswiler <marcel.ziswiler@toradex.com>
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 <marcel.ziswiler@toradex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

pelwell commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

diveed commented 5 years ago

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 commented 5 years ago

Latest rpi-update should have the fix.

diveed commented 5 years ago

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