[off-list ref] writes:
quoted
quoted
2) Track whether this is the first or second USB NIC plugged in. Only offer it
on the first NIC detected by r8152. When the second NIC is plugged in don't
match from ACPI.
quoted
There would be a question of what to do if the first NIC is removed and
added back if it should get the persistent system MAC or not.
quoted
I'd say yes, just make sure that only one NIC can have it at a time.
You are going to get things very complex very quickly if you try to do this.
It's really not that hard, track a module wide static variable whether
the feature is in use. Track in each device whether the feature was
in use. If it in use, don't assign the next device plugged in via the
ACPI string. If a device is removed that has the feature activated,
change the module wide static variable.
Having the mac address jump around in an arbitrary way like this is
going to confuse the hell out of your users. Consider what happens if
the user docks a laptop with an r8152 usb dongle already plugged in...
How are you going to explain that the dock gets some other mac address
in this case? How are you going to explain the difference between using
an r8152 based dongle and some other ethernet usb dongle with your
systems?
Make it behave consistently if you're going to add this. Which can be
done by specifically matching the Dell dock (doesn't it have an unique
Dell device ID?) and ignoring any other r8152 device. You could also
choose to set the same mac for all r8152 devices. Which is fine, but
will probably confuse many users.
What you definitely should not do is to change the mac for some
arbitrary "first" device. Then you are better off with the userspace
proposal where you and your users have some chance to implement a
sensible policy based on e.g. usb port numbers.
Bjørn
-----Original Message-----
From: Bjørn Mork [mailto:bjorn@mork.no]
Sent: Thursday, June 2, 2016 1:04 PM
To: Limonciello, Mario <redacted>
Cc: gregkh@linuxfoundation.org; hayeswang@realtek.com; linux-
kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
usb@vger.kernel.org; pali.rohar@gmail.com; anthony.wong@canonical.com
Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
Auxiliary MAC address
[off-list ref] writes:
quoted
quoted
quoted
2) Track whether this is the first or second USB NIC plugged in. Only
offer it
quoted
quoted
on the first NIC detected by r8152. When the second NIC is plugged in
don't
quoted
quoted
match from ACPI.
quoted
There would be a question of what to do if the first NIC is removed and
added back if it should get the persistent system MAC or not.
quoted
I'd say yes, just make sure that only one NIC can have it at a time.
You are going to get things very complex very quickly if you try to do this.
It's really not that hard, track a module wide static variable whether
the feature is in use. Track in each device whether the feature was
in use. If it in use, don't assign the next device plugged in via the
ACPI string. If a device is removed that has the feature activated,
change the module wide static variable.
Having the mac address jump around in an arbitrary way like this is
going to confuse the hell out of your users. Consider what happens if
the user docks a laptop with an r8152 usb dongle already plugged in...
How are you going to explain that the dock gets some other mac address
in this case? How are you going to explain the difference between using
an r8152 based dongle and some other ethernet usb dongle with your
systems?
Yeah I understand the concern. I agree that would be very confusing
to a user. This does need to match only on Dell docks then.
Make it behave consistently if you're going to add this. Which can be
done by specifically matching the Dell dock (doesn't it have an unique
Dell device ID?) and ignoring any other r8152 device. You could also
choose to set the same mac for all r8152 devices. Which is fine, but
will probably confuse many users.
Unfortunately there is no Dell specific VID/PID. I checked a no-name dongle
that used r8152 and it was the same (0bda:8153). Maybe Hayes Wang can
check with his Windows driver colleagues if there was anything else to key
off when this was implemented on the Windows Realtek driver. If there
is something else to key off of, I'm not aware what it is. I'll check with
some of my colleagues too.
I do have a way to query if a dock is plugged in via SMM, but I doubt that's
what Realtek is using on the Windows side. I'd leave that as a second to
last resort (last resort being move back to userspace again).
What you definitely should not do is to change the mac for some
arbitrary "first" device. Then you are better off with the userspace
proposal where you and your users have some chance to implement a
sensible policy based on e.g. usb port numbers.
OK, if I can't come up with a way to key on the device being a Dell dock
I'll scrap this entirely kernel approach.
On Thursday 02 June 2016 20:04:02 Bjørn Mork wrote:
[off-list ref] writes:
quoted
quoted
quoted
2) Track whether this is the first or second USB NIC plugged in.
Only offer it
on the first NIC detected by r8152. When the second NIC is
plugged in don't match from ACPI.
quoted
There would be a question of what to do if the first NIC is
removed and
added back if it should get the persistent system MAC or not.
quoted
I'd say yes, just make sure that only one NIC can have it at a
time.
You are going to get things very complex very quickly if you try
to do this.
It's really not that hard, track a module wide static variable
whether the feature is in use. Track in each device whether the
feature was in use. If it in use, don't assign the next device
plugged in via the ACPI string. If a device is removed that has
the feature activated, change the module wide static variable.
Having the mac address jump around in an arbitrary way like this is
going to confuse the hell out of your users. Consider what happens
if the user docks a laptop with an r8152 usb dongle already plugged
in... How are you going to explain that the dock gets some other mac
address in this case? How are you going to explain the difference
between using an r8152 based dongle and some other ethernet usb
dongle with your systems?
Make it behave consistently if you're going to add this. Which can
be done by specifically matching the Dell dock (doesn't it have an
unique Dell device ID?) and ignoring any other r8152 device. You
could also choose to set the same mac for all r8152 devices. Which
is fine, but will probably confuse many users.
What you definitely should not do is to change the mac for some
arbitrary "first" device. Then you are better off with the userspace
proposal where you and your users have some chance to implement a
sensible policy based on e.g. usb port numbers.
This is exactly what I wanted to write, but you were faster :-)
You can connect more Dell docks (with r8152 devices) and more non-Dell
r8152 devices in random order into Dell laptop. In any case dependent on
connect and disconnect order, devices always must have exactly same MAC
addresses. Otherwise there will be problems! It confuse users and also
admins of networks...
So if kernel approach is chosen then I think there are only two solution
those satisfy above conditions:
First one is:
* all non-Dell devices have own MAC address
* all Dell devices have (one, same) AUX MAC address
Second one is:
* all devices (Dell and also non-Dell) have own address
* AUX MAC address is never used
So what do you (netdev maintainers) think about it?
--
Pali Rohár
pali.rohar@gmail.com
On Thursday 02 June 2016 20:28:33 Mario_Limonciello@dell.com wrote:
quoted
-----Original Message-----
From: Bjørn Mork [mailto:bjorn@mork.no]
Sent: Thursday, June 2, 2016 1:04 PM
To: Limonciello, Mario <redacted>
Cc: gregkh@linuxfoundation.org; hayeswang@realtek.com; linux-
kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
usb@vger.kernel.org; pali.rohar@gmail.com;
anthony.wong@canonical.com Subject: Re: [PATCH] r8152: Add support
for setting MAC to system's Auxiliary MAC address
[off-list ref] writes:
quoted
quoted
quoted
2) Track whether this is the first or second USB NIC plugged
in. Only
offer it
quoted
quoted
on the first NIC detected by r8152. When the second NIC is
plugged in
don't
quoted
quoted
match from ACPI.
quoted
There would be a question of what to do if the first NIC is
removed and
added back if it should get the persistent system MAC or not.
quoted
I'd say yes, just make sure that only one NIC can have it at a
time.
You are going to get things very complex very quickly if you try
to do this.
It's really not that hard, track a module wide static variable
whether the feature is in use. Track in each device whether the
feature was in use. If it in use, don't assign the next device
plugged in via the ACPI string. If a device is removed that has
the feature activated, change the module wide static variable.
Having the mac address jump around in an arbitrary way like this is
going to confuse the hell out of your users. Consider what happens
if the user docks a laptop with an r8152 usb dongle already
plugged in... How are you going to explain that the dock gets some
other mac address in this case? How are you going to explain the
difference between using an r8152 based dongle and some other
ethernet usb dongle with your systems?
Yeah I understand the concern. I agree that would be very confusing
to a user. This does need to match only on Dell docks then.
quoted
Make it behave consistently if you're going to add this. Which can
be done by specifically matching the Dell dock (doesn't it have an
unique Dell device ID?) and ignoring any other r8152 device. You
could also choose to set the same mac for all r8152 devices.
Which is fine, but will probably confuse many users.
Unfortunately there is no Dell specific VID/PID. I checked a no-name
dongle that used r8152 and it was the same (0bda:8153). Maybe Hayes
Wang can check with his Windows driver colleagues if there was
anything else to key off when this was implemented on the Windows
Realtek driver. If there is something else to key off of, I'm not
aware what it is. I'll check with some of my colleagues too.
I have some other questions which answers should we know:
1) Is that AUX MAC address implemented only in customized windows Dell
driver? Or also in "upstream" windows Realtek driver and all users of
Realtek hw can install it (or update via next driver update)?
2) Can you share pseudo code or description of algorithm which decide
MAC address for newly connected r8152 device on windows? This could help
us to decide if something similar/same cannot be implemented also on
linux (either in kernel or userspace). What I would like to know are
those situations when you connect more r8152 devices (some Dell and some
non-Dell).
I do have a way to query if a dock is plugged in via SMM, but I doubt
that's what Realtek is using on the Windows side.
So there is some way to check if Dell dock is plugged, right? But what
happen if you connect Dell dock and also non-Dell r8152 device? Can you
distinguish which device is Dell and which non-Dell?
Anyway, I think that by SMM you mean dell smbios API call. Cannot you
guys in Dell release documentation of all smbios calls to community?
Time to time you release some small parts in libsmbios project which
then we can use for implementing useful parts in kernel (e.g. LED driver
for controlling keyboard backlight). But there are couple of
undocumented APIs and maybe some can also help with this problem...
I'd leave that as
a second to last resort (last resort being move back to userspace
again).
quoted
What you definitely should not do is to change the mac for some
arbitrary "first" device. Then you are better off with the
userspace proposal where you and your users have some chance to
implement a sensible policy based on e.g. usb port numbers.
OK, if I can't come up with a way to key on the device being a Dell
dock I'll scrap this entirely kernel approach.
E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell
specific subsystem IDs. And via subsystem IDs we can distinguish between
Intel graphics card on Dell laptop and on non-Dell laptop.
Does not you have some special/modified firmware in those Dell realtek
docks (and ability to check from OS some registers)?
--
Pali Rohár
pali.rohar@gmail.com
I have some other questions which answers should we know:
1) Is that AUX MAC address implemented only in customized windows Dell
driver? Or also in "upstream" windows Realtek driver and all users of
Realtek hw can install it (or update via next driver update)?
I don't have the information on this. Realtek will have to comment here as this
part is a black box to me. I'm asking my internal colleagues about this too.
2) Can you share pseudo code or description of algorithm which decide
MAC address for newly connected r8152 device on windows? This could help
us to decide if something similar/same cannot be implemented also on
linux (either in kernel or userspace). What I would like to know are
those situations when you connect more r8152 devices (some Dell and some
non-Dell).
This is another thing I don't have the information for right now.
I can install Windows on a laptop, install the Realtek driver and experiment,
but it would be better to get this directly from Realtek if at all possible.
quoted
I do have a way to query if a dock is plugged in via SMM, but I doubt
that's what Realtek is using on the Windows side.
So there is some way to check if Dell dock is plugged, right? But what
happen if you connect Dell dock and also non-Dell r8152 device? Can you
distinguish which device is Dell and which non-Dell?
Yes, when querying if a Dell dock is plugged in, a "location" and "count"
parameter is returned. I'd have to figure out how to translate that into
what the Linux kernel sees. Actually the information for how to do this
is already public too. It's in a pull request for Dock FW updating in the
fwupd project.
https://github.com/hughsie/fwupd/pull/49/files#diff-81b55c87ce1542a18b0a4b2b228b9129R189
Anyway, I think that by SMM you mean dell smbios API call. Cannot you
guys in Dell release documentation of all smbios calls to community?
Well dell SMBIOS API call really means to use dcdbas kernel module which
does SMM..
Time to time you release some small parts in libsmbios project which
then we can use for implementing useful parts in kernel (e.g. LED driver
for controlling keyboard backlight). But there are couple of
undocumented APIs and maybe some can also help with this problem...
Releasing different bits of our SMBIOS document requires approvals.
We can't just release the whole thing as there are lots of interfaces that
aren't intended for the OS to be using. They're used only by Dell tools.
For example we just had approval for information about querying TPM
and dock information and those are present in the fwupd pull request
for dock and TPM FW updates you see above.
If you have some API's in particular you would like more information on,
I'm happy to have internal discussion to see if we can release information
on those.
quoted
I'd leave that as
a second to last resort (last resort being move back to userspace
again).
quoted
What you definitely should not do is to change the mac for some
arbitrary "first" device. Then you are better off with the
userspace proposal where you and your users have some chance to
implement a sensible policy based on e.g. usb port numbers.
OK, if I can't come up with a way to key on the device being a Dell
dock I'll scrap this entirely kernel approach.
E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell
specific subsystem IDs. And via subsystem IDs we can distinguish between
Intel graphics card on Dell laptop and on non-Dell laptop.
Does not you have some special/modified firmware in those Dell realtek
docks (and ability to check from OS some registers)?
I think so. Otherwise there would be all the same concerns you have outlined
with generic devices. Like I said this part is currently a black box to me.
I hope Realtek can publicly comment on this, or I can get some information
from my colleagues.