On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
> Currently the local link address of all links is random generated by
> eth_random_addr() in mac80211 while connecting to a MLO AP for station
> mode. The MAC address of link is not passed from NL command. The 1st
> link address is generated while authenticate with AP, the other links'
> addresses are generated after assoc success with AP.
>
> It is not convenient for some driver, reason is, for station mode,
> the interface with its mac address is already created in driver after
> wlan load, it is used for hw scan and non-MLO connection.
>
> When connecting to MLO AP, driver reuse the interface as the 1st link of
> MLO. If the mac address of the 1st link changed to a new value, then
> driver need to change the mac address and do many synchronous operation
> with firmware. Thus the operation become complex. After MLO disconnect,
> driver need to restore the old mac address, it is also another complex
> operation.
>
> The hw scan maybe happen through the MLO connection/disconnection. And
> the hw scan uses the 1st link address while MLO connected and uses the
> interface address while MLO is disconnected, this leads hw scan complex.
>
> Hence add this interface to allow driver to generate the address of each
> link while MLO connection. Then driver could provide the same mac address
> for the 1st link, thus hw scan/NON-MLO connection/1st link of MLO will use
> the same mac address, then operation become easy.
Maybe after all this explanation, all we need is a flag "reuse MLD
address for assoc link"?
> + ret = drv_generate_link_addr(sdata->local, sdata,
> + link_id, link->conf->addr);
> + if (ret)
> + eth_random_addr(link->conf->addr);
should probably refactor this into a separate function though.
I'm also not sure how the driver even knows that a link it's being asked
to get the address for *is* the assoc link? Do you want to rely on that
being the first address handed out?
johannes
On 9/13/2023 4:55 PM, Johannes Berg wrote:
> On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
[...]
> Maybe after all this explanation, all we need is a flag "reuse MLD
> address for assoc link"?
yes. It is similar as I said before here:
https://lore.kernel.org/linux-wireless/[email protected]/
>
>
>> + ret = drv_generate_link_addr(sdata->local, sdata,
>> + link_id, link->conf->addr);
>> + if (ret)
>> + eth_random_addr(link->conf->addr);
> should probably refactor this into a separate function though.
OK.
>
> I'm also not sure how the driver even knows that a link it's being asked
> to get the address for *is* the assoc link? Do you want to rely on that
> being the first address handed out?
Current I used (vif->valid_links==0) check for assoc link. When
drv_generate_link_addr() called for the assoc link, vif->valid_links
is 0, and it is not 0 for other links.
>
> johannes
>
On Fri, 2023-09-15 at 16:11 +0800, Wen Gong wrote:
> On 9/13/2023 4:55 PM, Johannes Berg wrote:
> > On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
> [...]
> > Maybe after all this explanation, all we need is a flag "reuse MLD
> > address for assoc link"?
>
> yes. It is similar as I said before here:
>
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> >
> >
> > > + ret = drv_generate_link_addr(sdata->local, sdata,
> > > + link_id, link->conf->addr);
> > > + if (ret)
> > > + eth_random_addr(link->conf->addr);
> > should probably refactor this into a separate function though.
> OK.
> >
> > I'm also not sure how the driver even knows that a link it's being asked
> > to get the address for *is* the assoc link? Do you want to rely on that
> > being the first address handed out?
> Current I used (vif->valid_links==0) check for assoc link. When
> drv_generate_link_addr() called for the assoc link, vif->valid_links
> is 0, and it is not 0 for other links.
That seems a bit questionable?
Well then again, what do you want for AP mode? Anyway you can still
distinguish, and if we later need to change an internal API that's not
the end of the world either ...
So OK, I guess we can live with this, just would like to see it wrapped
up into a single function.
johannes
On 9/26/2023 5:45 PM, Johannes Berg wrote:
> On Fri, 2023-09-15 at 16:11 +0800, Wen Gong wrote:
>> On 9/13/2023 4:55 PM, Johannes Berg wrote:
>>> On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
>> [...]
>>> Maybe after all this explanation, all we need is a flag "reuse MLD
>>> address for assoc link"?
>> yes. It is similar as I said before here:
>>
>> https://lore.kernel.org/linux-wireless/[email protected]/
>>
>>>
>>>> + ret = drv_generate_link_addr(sdata->local, sdata,
>>>> + link_id, link->conf->addr);
>>>> + if (ret)
>>>> + eth_random_addr(link->conf->addr);
>>> should probably refactor this into a separate function though.
>> OK.
>>> I'm also not sure how the driver even knows that a link it's being asked
>>> to get the address for *is* the assoc link? Do you want to rely on that
>>> being the first address handed out?
>> Current I used (vif->valid_links==0) check for assoc link. When
>> drv_generate_link_addr() called for the assoc link, vif->valid_links
>> is 0, and it is not 0 for other links.
> That seems a bit questionable?
Also we can change to indicate a new flag(e.g.
IEEE80211_HW_MLO_FIXED_ASSOC_LINK_ADDR) to
mac80211 from driver, if the flag is not set, then keep current logic.
If it is set, then copy vif->addr to the link->conf->addr for assoc link
in ieee80211_mgd_setup_link().
The logic keep not change for other links.
> Well then again, what do you want for AP mode? Anyway you can still
> distinguish, and if we later need to change an internal API that's not
> the end of the world either ...
I do not want any change for AP mode.
>
> So OK, I guess we can live with this, just would like to see it wrapped
> up into a single function.
>
> johannes