On Fri, Oct 04, 2024 at 04:15:32PM -0700, Brian Norris wrote: > On Wed, Sep 18, 2024 at 01:10:27PM +0200, Sascha Hauer wrote: > > Furthermore the driver doesn't use the permanent address to add the > > bss_num to, but instead the current MAC address increases each time > > we do a change_virtual_intf. > > > > Fix this by initializing the MAC address once from the permanent MAC > > address during creation of the virtual interface and never touch it > > again. This also means that userspace can set a different MAC address > > which then stays like this forever and is not unexpectedly changed > > by the driver. > > > > It is not clear how many (if any) MAC addresses after the permanent MAC > > address are reserved for a device, so set the locally admistered > > bit for all MAC addresses derived from the permanent address. > > I think I'm generally supportive of the direction this changes things, > but I'm a bit hesitant about two things: FTR, I am hesitant for similar reasons. In addition there is my comment from the previous version on a specific use case potentially broken. > And I see that you rightly don't know how many addresses are actually > reserved, but I have an educated guess that it's not just 1. For one, > this driver used to default-create 3 interfaces: The MAC addresses on the module are not allocated by the Wi-Fi chip vendor (NXP, and before Marvell), but by whom is integrating the chip. I can try to ask a couple of vendors what they are doing on this regard, and if this is somehow suggested by NXP or they are just doing whatever they believe is right. Just to add a couple of more data points to this discussion. Francesco
