Larry Finger wrote :
Michael,
I'm switching this discussion from the kernel Bugzilla to the lists.
As you know, but I'm restating for anyone that has not read our previous
discussions, the b43 driver needs to be changed to handle some of the newer
devices do not have an on-board SPROM. It would be trivial to incorporate the
data except for the need to have a unique, reproducible MAC.
I am proposing to solve this problem using the following steps:
(1) Modify b43-fwcutter to take data from an existing SPROM, modify the MAC by
replacing the last 3 octets with random numbers, and write the resulting file to
/lib/firmware/b43. Fortunately, all affected devices seem to have Revision 8
SPROMS, which makes preparation easier. All such devices will need to use the
calibration parameters of the device from which the prototype SPROM was copied,
but that should not be a serious problem. I have chosen to implement this in
fwcutter rather than ssb_sprom because the ordinary user will not have access to
ssb_sprom; however, they do have a version of fwcutter supplied by the distro.
Unconditionally writing an additional small file to the firmware directory when
extracting firmware is small overhead and it will be transparent to the user of
whatever mechanism the distro uses. The routines needed to calculate the CRC,
etc. have been copied into fwcutter from ssb_sprom. A version of this code is
already running.
(2) Use the steps in http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable to
determine if the device has an SPROM. If not, then use the kernel's firmware
loading mechanism to get the contents of the file prepared in step 1. This file
has an 8-bit CRC, thus the validity of the file can be tested even though the
test is not very robust.
It it reasonable to keep the vendor portion of the MAC and only replace the
"serial number", or would it be better to randomize all 6 octants?
We know that there exist a risk (arguably low) for two devices in the same LAN to have the same
random part of the MAC. The risk might be higher if, for any reason, the random number generator
lack good entropy at the time fwcutter is run.
Also, keeping the same MAC prefix (one from Broadcom) will lead to a risk of having the same MAC for
a randomly generated device and for a legitimate MAC from Broadcom.
To reduce the risk, we can chose two different ways :
1/ Using a "private" MAC (having bit 0x02 of the lowest byte of the MAC set to 1). This will provide
a random area of 46 bits, far better than 24 bits if we keep the Broadcom prefix.
2/ Registering a public MAC prefix for this usage.
Anyway, I think we should add a duplicate MAC detection system, that would at least issue a warning
if the NIC lacking an SPROM (and so knowing the MAC address was randomized) receive a packet with
its MAC as the source MAC.
Of course, in some network topologies, several NIC may share the same MAC, leading to some of them
receiving packets with their own MAC as source MAC. A bonding configuration is one such situation.
For this reason, it might be also desirable to have the ability to report to an upper layer that the
MAC is possibly "unsafe" (subject to a risk of duplicate MAC) and probably not suitable to become
the shared MAC for a bonding configuration. That way, at the time such configuration are setup, the
tool used to setup the configuration would have the ability to report the situation to the user.
Also, in order to keep the same MAC if one run fwcutter again, we should provide fwcutter with an
option to decide whether we want to keep the previously randomized MAC or whether fwcutter should
provide a new one (in particular if the current one hit a duplicate MAC).
Nicolas.
Is there a better way to load a file into the kernel?
Thanks,
Larry
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
