>> Use the existing RSNE parsing and checks also for OSEN. > > Could you please provide more detailed commit message for this change, > i.e., why should this be done, does this fix something, how has this > been tested to confirm there are no regressions, etc.? I'm not at all > convinced that all OSEN AP implementations behave in a manner that is > consistent between RSN and OSEN and as such, some of these changes look > like high risk items for introducing interoperability issues. Some of > the changes might be safe to do for sharing same routines, but in > general, I'm not sure there is enough benefit from all these changes to > justify the increased risk for interoperability. > This only has been tested with the hostapd osen tests. While it's kind of a cleanup it could well cause regressions... The patch is the "fallout" from my attempts to get OSEN working with Extended Key ID. Without this patch the OSEN element is not parsed, so any data in it is inaccessible. (We never call wpa_sm_set_ap_rsn_ie() or a replacement for OSEN.) Now I finally figured out that the OSEN element can only be set by the AP, depriving it of any way to detect if a STA is compatible. (I still may be mistaken about that but I was sure enough to stop looking into it...) This of course killed the reason why I was trying to fix the OSEN parsing in the first place:-) The current code is kind of sitting between the chairs: Some functions have useless code considering OSEN but some central pieces are missing. Therefore I just wanted to share how far I got to fix that. I'm totally fine to not apply it due to risk of regressions. (I may think about preparing a patch to rip out the useless code in that case instead.) Alexander _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
