On Mon, Aug 14, 2023 at 2:28 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2023-08-14 at 01:56 +0530, Krishna Chaitanya wrote: > > > > > > > Just remembered why I had to implement this in kernel, the associate/connect > > > > data structure in wpa_s `wpa_driver_associate_params` doesn't have any > > > > ies/extra_ies, it only gives wpa_ie and rest all are parameters for mac80211 > > > > to use. So, had just extended this as well, do you think we should add > > > > this ies/extra_ies > > > > to the association like we do for scan? Or as MLME is in mac80211, > > > > just use this patch as is? > > > > > > Not sure I follow all that reasoning - is that something internal to > > > wpa_supplicant? Fundamentally with my cfg/mac hat on I'm not sure I care > > > so much about wpa_s internal data structures? > > > > > > Things like extended capabilities are also added to the "extra IEs" by > > > wpa_s, so surely this would work too? > > > > I was only pointing out that AFAIK there is no mechanism to pass "ies" in > > the associate command from userspace, except for WPA IE. > > Oh you're talking about the associate command? You never mentioned that, > and in fact most of your patch is concerned with mac80211 ... > > Would it kill the implementation you have to add "extra elements" rather > than all these individual settings? Does this thing affect the local > firmware implementation? I guess in a sense it must? > > I don't know ... and I have no way of ever finding out! So again this is > one of those things where we're never going to see an upstream driver > using it, right? I'm getting really close to just giving up on that. > Since Jouni is happy to add vendor commands for settings left and right > in wpa_supplicant, I pretty much think this stuff has failed. We're > littering the nl80211 API with things that don't really get used > upstream, or like here, do get used but in a way that's > (a) pretty useless since it doesn't do anything but add an element > wpa_s could have added itself, and > (b) looks like just a fig-leaf for this exact reason? Shouldn't > something be configured here to the NIC too? NIC should support > it, etc.? What's even the purpose of this in mac80211? I agree that this IE should be populated by wpa_s as it needs user input, I had looked at other information in cmd_associate where it's passed to mac80211 using nl80211, so, had followed this approach. I will try and add this to wpa_s itself, thanks. NIC isn't involved here directly (unless keepalive for connection is offloaded), this is about conveying a user preference to AP to avoid AP prematurely disassociating the client.
