On Fri, Aug 11, 2023 at 3:11 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Fri, 2023-08-11 at 00:17 +0530, Krishna Chaitanya wrote: > > On Fri, Aug 11, 2023 at 12:05 AM Krishna Chaitanya > > <chaitanya.mgit@xxxxxxxxx> wrote: > > > > > > On Tue, Aug 8, 2023 at 4:43 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, 2023-07-20 at 01:10 +0530, Chaitanya Tata wrote: > > > > > When WNM is enabled, a station can send its preferred BSS maximum idle > > > > > period in the association request, add a new netlink attribute to get > > > > > this value from the supplicant and add BSS maximum idle IE in the > > > > > association request. > > > > > > > > > > > > > I don't see anything here that even requires all this code, rather than > > > > wpa_s just including the element itself in the association request extra > > > > IEs? > > > Yeah, WPA supplicant can prepare this, please ignore, thanks. > > > 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.