From d42e84856743765959295a6bd864a2e8ddaf0bdc Mon Sep 17 00:00:00 2001 From: Andrew Zaborowski Date: Tue, 13 Feb 2018 18:43:56 +0100 Subject: [PATCH] device: Workaround for 0 oper class in Neighbor Report Some APs respond to Neighbor Report Requests with neighbor reports that have a zero operating class value and a non-zero channel number. This does not mean that the channel is in the same band that the reporting AP operates in. Try to guess the band that the channel refers to out of 2.4 and 5GHz -- the bands supported by those APs. wpa_supplicant also has this workaround in place. --- src/device.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/src/device.c b/src/device.c index 8fdd6faf..1b4603ed 100644 --- a/src/device.c +++ b/src/device.c @@ -1184,11 +1184,31 @@ static uint32_t device_freq_from_neighbor_report(const uint8_t *country, enum scan_band band; uint32_t freq; - band = scan_oper_class_to_band(country, info->oper_class); - if (!band) { - l_debug("Ignored: unsupported oper class"); + if (info->oper_class == 0) { + /* + * Some Cisco APs report all operating class values as 0 + * in the Neighbor Report Responses. Work around this by + * using the most likely operating class for the channel + * number as the 2.4GHz and 5GHz bands happen to mostly + * use channels in two disjoint ranges. + */ + if (info->channel_num >= 1 && info->channel_num <= 14) + band = SCAN_BAND_2_4_GHZ; + else if (info->channel_num >= 36 && info->channel_num <= 169) + band = SCAN_BAND_5_GHZ; + else { + l_debug("Ignored: 0 oper class with an unusual " + "channel number"); - return 0; + return 0; + } + } else { + band = scan_oper_class_to_band(country, info->oper_class); + if (!band) { + l_debug("Ignored: unsupported oper class"); + + return 0; + } } freq = scan_channel_to_freq(info->channel_num, band);