On Thu, 2022-04-28 at 20:07 +0300, Jouni Malinen wrote: > There are use cases where over-the-air Link ID is used and other cases > where it is more appropriate to identify the local link based on the > band (or subband, etc.) in a manner that is valid over one or multiple > associations. Do you have an example for the latter? I haven't really come up with one yet. > It might actually make more sense to come up with two > nl80211 attributes for identifying a link based on either the > over-the-air Link ID (which is valid only during an association and can > change whenever roaming occurs) or the internal identifier for a link. That makes a lot of sense. > This would allow nl80211 commands to use only one of the possible ways > of identifying link so that user space components would not need to know > or care about the mapping and would just use the variant that is easier > for the particular case. > Right. Though in many cases that would have to get pushed down to the driver, and that'd mean drivers have to be aware of all those possible ways too? I'm not sure cfg80211 always has enough information to resolve to one particular way of identifying, especially with roaming offload etc. where you might actually need to push some identifying attribute like the BSSID down to firmware? Anyway, I guess that means we can put the link ID into a small struct or something for the APIs, so we can extend it more easily later. I'm not sure I can reasonably come up with all the possible ways to do this in the initial work here. In fact, I'm wondering if I shouldn't just focus on client with AUTH/ASSOC (not CONNECT) and AP for now, so we can get something started... > For nl80211 event messages, both attributes > could be included since the driver and/or cfg80211 would know the > mapping and could fill in both options so that the user space components > would not need to be aware of the full mapping. Assuming we have all the data, yes. > In addition, there seems to still be some open discussion on how various > Management frames are targeting specific links and that might even > result in there being a protocol mechanism for targeting a subset of the > available links, i.e., not all of MLD but one or more links. I'm not > sure whether this would need anything particular in nl80211 since we > could always send multiple copies of the command/event (one per link), > but it might also be convenient to be able to use an array of the > over-the-air and/or internal identifiers for the links. Indeed. I'm not sure using multiple commands would be OK since in the case of multiple, it might require them having the same seqno just like multicast data frames? But I'm not sure what the spec is doing here now :) johannes
