On Mon, Feb 20, 2017 at 12:35:08AM +0900, Siwon Kang wrote: > The externally observable malfunction is the set provided in the patch as > an example. As you know well, the US regulatory does not allow ch 12 > and 13 so this function shall return -1 if the country code is explicitly > given as 'US' just like that -1 is returned for channel 14 when CC is in the > set of 'us' or 'eu'. However, it currently returns 2467 or 2472 for the input > 12 or 13 + US so that it looks those channels are allowed. The header > comments says the return must be -1 if the specified channel is unknown. > Since the channel 12, 13 are unknown in US, it shall return -1. > As well as it shouldn't use global table as a backup path because, as > stated in a doxygen format description, the function uses global op_class > only if the country code is unknown. In above case it specifies the known > country code - US so it should not use global op_class. I'd like to understand what actual hostapd or wpa_supplicant functionality this patch would fix. I cannot really see it fixing anything in the current functionality. Can you identify a specific caller of ieee80211_chan_to_freq() that gets fixed if this patch gets applied? On the other hand, this would seem to break functionality in one of the callers, i.e., the one in wnm_nei_get_chan() (wpa_supplicant/wnm_sta.c). That code fetches the Country element to see which country is in use and then expect ieee80211_chan_to_freq() to have the fallback option to the global table if none of the country-specific operating classes matched. In theory, wnm_nei_get_chan() could be modified to clear the country pointer back to NULL if the third octet of the country string has 0x04 in it. That said, I'm not convinced that all AP vendors will implement this correctly and as such, want to have the fallback option to look up the global table regardless. I guess this function could try to check for that 0x04 first and then if the country specific lookup fails, fall back to trying without a country code in this function. In any case, without addressing all the existing callers (of which I could identify this wnm_nei_get_chan() being the only problematic one) in the same patch, I cannot apply this patch since it could result in regressions to existing functionality. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
