svn commit: r346052 - head/sys/dev/usb/net
John Baldwin
jhb at FreeBSD.org
Tue Sep 3 14:07:12 UTC 2019
On 4/9/19 9:59 AM, Ian Lepore wrote:
> On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote:
>> On 4/9/19 9:17 AM, Ian Lepore wrote:
>>> On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote:
>>>> On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote:
>>>>> Author: ganbold
>>>>> Date: Tue Apr 9 13:54:08 2019
>>>>> New Revision: 346052
>>>>> URL: https://svnweb.freebsd.org/changeset/base/346052
>>>>>
>>>>> Log:
>>>>> In some cases like NanoPI R1, its second USB ethernet
>>>>> RTL8152 (chip version URE_CHIP_VER_4C10) doesn't
>>>>> have hardwired MAC address, in other words, it is all zeros.
>>>>> This commit fixes it by setting random MAC address
>>>>> when MAC address is all zeros.
>>>>>
>>>>> Reviewed by: kevlo
>>>>> Differential Revision:
>>>>> https://reviews.freebsd.org/D19856
>>>>
>>>> It would be best to not use a purely random mac address and to
>>>> use
>>>> the
>>>> function kevans@ added recently. That function generates a MAC
>>>> address
>>>> from the FreeBSD OUI using a cryptographic hash so you get a
>>>> stable address across boots on a given host.
>>>>
>>>
>>> How could that possibly work? If it's not random, you can't have
>>> two
>>> such devices on the same network. If it is random, it's not stable
>>> from one boot to the next.
>>
>> It uses the UUID and interface name as input into the hash.
>
>> The UUID is per-host.
>
> Oh, so it only works on x86 (or I guess any system that has something
> like a bios that can provide you with a uuid that doesn't change from
> one boot to the next).
The function is in one centralized place where you are free to add other
data as input into the hash. We do always generate a uuid that we save
on boot if we aren't seeded with one by firmware, though that is probably
too late for this driver (so +1 may in fact be a better route). It should
be fine for psuedo interfaces created post-boot though even on non-x86 due
to /etc/rc.d/hostid. Pure random MAC's are not really great either.
--
John Baldwin
More information about the svn-src-all
mailing list