Re: Managing interface with random MAC address

[Kay Sievers <kay sievers vrfy org>]

On Thu, Mar 5, 2009 at 15:48, Dan Williams <dcbw redhat com> wrote:
> On Thu, 2009-03-05 at 14:53 +0100, Kay Sievers wrote:
>> On Thu, Mar 5, 2009 at 13:33, Dan Williams <dcbw redhat com> wrote:
>> > On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
>> >> I have an embedded device known as a beagle board that draws power
>> >> from my USB port (shows up as usb0). When it boots, it presents itself
>> >> as a USB ethernet device. I want to share my connection with the
>> >> device from network manager.
>> >>
>> >> Two problems: The first is that network manager sees an unmanaged
>> >> device and tries to obtain an IP address, the second, I can't seem to
>> >> setup an automatic share my connection connection since every time the
>> >> board boots, it has a different hardware address. Any tips?
>> >
>> > What is the USB serial number of the device?  The core problem here is
>> > that if there's no unique identifier for the device, there's no way to
>> > lock a specific connection to that device, and thus any generic Wired
>> > connection will be used instead.
>> >
>> > Run "lsusb -v" and look for the iSerial field; is that field something
>> > other than 0?  Do other beagle boards present other serial numbers?
>> >
>> > Do you want to keep the wired device unmanaged and ignored by
>> > NetworkManager?  You said "sees an unmanaged device and tries to obtain
>> > an IP address", but NM should be ignoring unmanaged devices.  However,
>> > that mechanism depends on HAL UDIs and thus the random MAC address may
>> > well be confusing it.
>>
>> A random MAC address is defined by a bit in the MAC address itself.
>> Maybe these devices should be special handled. At least the MAC should
>> not be stored somewhere on the system.
>>
>> The udev persistent netif name rule generator does this:
>>   # do not use "locally administered" MAC address
>>   ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
>
> So if not using a MAC address, how does one uniquely identify the
> device?  Say I want to tie a connection to a specific device; it's
> certainly not possible with udev interface rename rules unless udev uses
> some magic UUID I don't know about...

Right, we currently depend on the MAC address, the "type" (netif
type), the "dev_id" (managed by the driver for multiple instances),
and handle only devices attached to a bus, virtual interfaces are
ignored.

Some subsystems like IBM's S390 use random MAC addresses, but have
special udev rules to manage persistent names based on properties of
the underlying bus.

> If you plug two of these into a
> system, is it simply up to kernel subsystem probing which of these
> devices gets eth0 and which gets eth1?

Yes, devices with random MAC addresses and without specific rules to
handle them, get random interface names. There is today no solution to
make them work properly with a stored system configuration. People
could write custom udev rules to accomplish persistent names, but that
does not happen automatically.

It's a network device specific problem, because you can only have a
single name for a device. Unlike device nodes, where we have a bunch
of symlinks to identify a device, and can choose the type of link
depending on the problem to solve. For serial devices we have
something like:

  $ tree /dev/serial/
  /dev/serial/
  |-- by-id
  |   |-- usb-067b_2303-if00-port0 -> ../../ttyUSB0
  |   |-- usb-FTDI_FT232R_USB_UART_A7005uBP-if00-port0 -> ../../ttyUSB5
  |   |-- usb-HUAWEI_Technology_HUAWEI_Mobile-if00-port0 -> ../../ttyUSB3
  |   |-- usb-HUAWEI_Technology_HUAWEI_Mobile-if01-port0 -> ../../ttyUSB4
  |   |-- usb-Palm_Computing__Inc._USB_Serial_Adaptor_00088798-if00-port0
-> ../../ttyUSB1
  |   `-- usb-Palm_Computing__Inc._USB_Serial_Adaptor_00088798-if00-port1
-> ../../ttyUSB2
  `-- by-path
      |-- pci-0000:00:1d.0-usb-0:1:1.0-port0 -> ../../ttyUSB1
      |-- pci-0000:00:1d.0-usb-0:1:1.0-port1 -> ../../ttyUSB2
      |-- pci-0000:00:1d.7-usb-0:2.2:1.0-port0 -> ../../ttyUSB3
      |-- pci-0000:00:1d.7-usb-0:2.2:1.1-port0 -> ../../ttyUSB4
      |-- pci-0000:00:1d.7-usb-0:2.3:1.0-port0 -> ../../ttyUSB5
      `-- pci-0000:00:1d.7-usb-0:2.4.2:1.0-port0 -> ../../ttyUSB0

where we can choose between the "by-path" which changes with the port
the device is plugged in, but handles multiple identical devices, and
the "by-id" which is independent of the port, but can not handle
completely identical devices.

Both are useful and can not replace the other type. For network
interfaces, we have only a single name, and therefore all these
problems, which can not be solved properly with the current network
interface infrastructure.

Kay