[PATCH] Fix a channel-to-frequency transformation in ieee80211_chan_to_freq()

Jouni Malinen j at w1.fi
Wed Mar 1 00:39:40 PST 2017


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



More information about the Hostap mailing list