0

I hope you can really help me. I am using a Raspberry Pi and a common USB ethernet adapter. At first you can see as example this:

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 0a:b9:0c:6a:45:90  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.218  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::a688:4108:6d20:3972  prefixlen 64  scopeid 0x20<link>
        ether 62:cd:56:ee:d9:9c  txqueuelen 1000  (Ethernet)
        RX packets 6690  bytes 948260 (926.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 486  bytes 54512 (53.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 490  bytes 275253 (268.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 490  bytes 275253 (268.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.230  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::b90f:6e76:4b78:26fb  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:04:97:d1  txqueuelen 1000  (Ethernet)
        RX packets 3876  bytes 493255 (481.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 78  bytes 10802 (10.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I changed eth0 to 0a:b9:0c:6a:45:90. But it is not the needed ethernet adapter. It is of course from the Raspberry Pi itself. I do not explain it further. This Ethernet port cannot even be reached and used because of a housing. That is why the USB ethernet adapter is used.

The eth1 will change on every boot.

If I edit /boot/config.txt or /boot/cmdline.txt I only can change the static MAC address of eth0. As example I have following line:

smsc95xx.macaddr=0a:b9:0c:6a:45:89

I can match and link this as example in /etc/systemd/network/00-default.link with:

[Match]
MACAddress=0a:b9:0c:6a:45:89

[Link]
MACAddress=0a:b9:0c:6a:45:90

As you can see it works fine. But this is not the solution of course. Inside /boot/config.txt or /boot/cmdline.txt I can not change the MAC address of eth1 because it is on the USB ethernet adapter, right? The MAC address will always change and the USB adapter is loaded after the network card on the Raspberry Pi, right?

As I said, the MAC address of eth1 changes constantly during booting. Of course, match and link cannot work because I never know what I have to match. So I can throw away the two conventional solutions for eth0 for the new eth1.

Does anyone have a corresponding solution? A static IP address is not the solution I am looking for. If you're going to go to the trouble of assembling a device, then you might want to use it in other networks. In other words, an IP should be permanently assigned via DHCP and the MAC address. In other words, a DHCP server takes over the address allocation and not each device independently. It will rarely happen that I pull the LAN cable, but the Raspberry Pi should not determine its IP address. For the DHCP to work, I need a static MAC address, of course.

Thanks in advance.

3
  • At first glance this looks like an XY problem but it is unclear what Y is.
    – Milliways
    Jul 5, 2021 at 11:39
  • What operating system with what version do you use?
    – Ingo
    Jul 5, 2021 at 18:01
  • The eth1 will change on every boot. are you saying that the mac address on the USB device is random?
    – Bravo
    Jul 5, 2021 at 23:07

1 Answer 1

1

This Ethernet port cannot even be reached and used because of a housing.

Patch-cord that goes through the housing, with a socket on one end and a normal jack on the other.

I can not change the MAC address of eth1 because it is on the USB ethernet adapter, right? The MAC address will always change and the USB adapter is loaded after the network card on the Raspberry Pi, right?

It depends on how the USB ethernet adapter behaves. I'm actually surprised that it changes every time – I would only expect this from e.g. Android USB tethering, but not from actual USB-Ethernet dongles.

Yes, the Raspberry Pi boot options do not influence other devices.

However, systemd's .link files have other ways for matching devices than just the MAC – you can use any udev property, such as the USB "manufacturer" + "product" IDs, or the USB serial number.

  1. Run udevadm info /sys/class/net/eth1 to find the properties that you want (hopefully the serial number is static).
  2. Use them in the .link file as [Match] Property=ID_THIS=something.

For example, for my ASIX USB Ethernet adapter (which does have a static burned-in MAC address), I could use:

  • ID_PATH=pci-0000:00:14.0-usb-0:1:1.0 (matches anything connected to this specific physical USB port)
  • ID_VENDOR_ID=0b95 + ID_MODEL_ID=1790 (matches all adapters of this model; the numbers are the same as in 'lsusb')
  • ID_SERIAL_SHORT=008CAE4CE9E48D (matches this device by its USB serial number; should be used together with ID_VENDOR_ID)
  • ID_USB_DRIVER=ax88179_178a (matches all adapters of this type)

For the DHCP to work, I need a static MAC address, of course.

DHCP primarily uses the Client-ID, which does not need to be a MAC address – for example, systemd-networkd will actually use a Client-ID that is based on /etc/machine-id and not on the MAC. You can even use a text string (typically a domain name) as the Client-ID. For example, one of my computers has two Wi-Fi adapters (one USB, one PCMCIA) and it uses the same Client-ID on both, thus getting the same IP address no matter which adapter I connect.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.