On 4/18/2023 5:11 PM, Johannes Berg wrote:
On Tue, 2023-04-18 at 16:59 +0800, Wen Gong wrote:
On 4/18/2023 4:15 PM, Johannes Berg wrote:
On Mon, 2023-04-17 at 22:07 +0800, Wen Gong wrote:
OK. So I will try to put this in mac80211 layer, is it OK?
I guess? I'm still not really sure why you even want it, but hey, that's
up to you in a way. I really didn't like the suggestion with
wiphy_iftype_ext_capab (or any other capability for that matter), it
feels like it should be more dynamic, like maybe a new "add link"
callback or something? At least then you can't blame mac80211 for when
it breaks when you have two 5 GHz links ...
ok, so I would like to add callback such as
"add_link(struct ieee80211_hw *hw, struct ieee80211_vif vif, struct
ieee80211_bss_conf *link_conf, unsigned int link_id)"
in struct ieee80211_ops, and mac80211 call it in
ieee80211_mgd_setup_link()/ieee80211_vif_update_links,
then lower-drvier could dynamic set the local addr of assoc
link_conf(also for 2nd link_conf), is it OK?
Seems OK, but I'm not sure that _works_?
After all, we first set the addresses in assoc_data, when we don't have
a link_conf yet, no? Just what we were discussing in the other thread
about the leak.
johannes
It should work, I will test it later.
For the 1st assoc link, the data->u.mgd.assoc_data is empty in
ieee80211_mgd_setup_link(),
because ieee80211_mgd_setup_link() is called from nl80211_authenticate()
for the 1st assoc link.
So ieee80211_mgd_setup_link() use eth_random_addr() for the 1st assoc link.
For the 2nd link, ieee80211_mgd_setup_link() is called from
nl80211_associate(),
the sdata->u.mgd.assoc_data is NOT empty,
and the sdata->u.mgd.assoc_data->link[link_id].addr is valid,
it is addr by eth_random_addr(assoc_data->link[i].addr) in
ieee80211_mgd_assoc().
