Linux USB
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: Oliver Neukum <oneukum@suse.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>
Subject: Re: question on random MAC in usbnet
Date: Thu, 16 Nov 2023 12:31:43 +0100	[thread overview]
Message-ID: <87zfzeexy8.fsf@miraculix.mork.no> (raw)
In-Reply-To: <53b66aee-c4ad-4aec-b59f-94649323bcd6@suse.com> (Oliver Neukum's message of "Thu, 16 Nov 2023 11:14:49 +0100")

Oliver Neukum <oneukum@suse.com> writes:

> I am wondering about the MAC address usbnet is handing
> out. In particular why that is a singular address.

This has been the case since long long before I ever looked at usbnet.c.
The variable declaration is in fact still attributed to the initial git
commit:

 ^1da177e4c3f4 drivers/usb/net/usbnet.c (Linus Torvalds              2005-04-16 15:20:36 -0700   64) // randomly generated ethernet address
 ^1da177e4c3f4 drivers/usb/net/usbnet.c (Linus Torvalds              2005-04-16 15:20:36 -0700   65) static u8   node_id [ETH_ALEN];

Pretty impressive given the churn we've had since then :)

If I were to guess why it ended up like that, I'd say that it probably
was because it was considered an exceptional fallback only.

If you wrote a driver with the USB-IF communication class spec in mind,
then it was reasonable to expect a functional decriptor pointing to a
string descriptor with a globally unique mac address, assigned by the
device manufacturer.

A host using more than one usbnet device was also unlikely 20 years
ago.  So host unique was good enough in any case.

These factors have change a lot since then, obviously.

> Frankly that seems plainly wrong. A MAC is supposed
> to be unique, which is just fundamentally incompatible
> to using the same MAC for multiple devices, as usbnet
> currently potentially does.

Agreed.

> Do you think that behavior should be changed to using
> a separate random MAC for each device that requires it?

I'm in favour.

I could be wrong, but I don't expect anything to break if we did that.
The current static address comes from eth_random_addr() in any case, so
the end result as seen from the mini drivers should be identical.  The
difference will be seen in userspace and surrounding equipment, And
those should be for the better.


Bjørn

  reply	other threads:[~2023-11-16 11:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 10:14 question on random MAC in usbnet Oliver Neukum
2023-11-16 11:31 ` Bjørn Mork [this message]
2023-11-16 12:32   ` Oliver Neukum
2023-11-19 11:09   ` David Laight
2023-11-19 16:13     ` Andrew Lunn
2023-11-20 11:06     ` Oliver Neukum
2023-11-20 16:48     ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfzeexy8.fsf@miraculix.mork.no \
    --to=bjorn@mork.no \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox