| Message ID | 1377179613-26591-1-git-send-email-seth.forshee@canonical.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, 2013-08-22 at 08:53 -0500, Seth Forshee wrote: > The Netgear WNDAP360 sends invalid ECSA IEs in probe response > frames I think we shouldn't be checking probe response frames at all. That seems like a mistake. Can you try this? http://p.sipsolutions.net/015f7b799f19426a.txt johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 22, 2013 at 04:01:03PM +0200, Johannes Berg wrote: > On Thu, 2013-08-22 at 08:53 -0500, Seth Forshee wrote: > > The Netgear WNDAP360 sends invalid ECSA IEs in probe response > > frames > > I think we shouldn't be checking probe response frames at all. That > seems like a mistake. Can you try this? I had considered this, but the spec says that it's at least valid for the AP to be sending ECSAs in probe responses. IEEE 802.11-2012 section 10.3.3.2: ...an AP shall inform associated STAs that the AP is moving to a new channel and/or operating class and maintain the association by advertising the switch using Extended Channel Switch Announcement elements in any transmitted Beacon frames, Probe Response frames, and Extended Channel Switch Announcement frames until the intended channel switch time. Perhaps we can still ignore them though? I suppose we'd expect to receive some other frame with the ECSA before it actually happens. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 22, 2013 at 09:10:11AM -0500, Seth Forshee wrote: > On Thu, Aug 22, 2013 at 04:01:03PM +0200, Johannes Berg wrote: > > On Thu, 2013-08-22 at 08:53 -0500, Seth Forshee wrote: > > > The Netgear WNDAP360 sends invalid ECSA IEs in probe response > > > frames > > > > I think we shouldn't be checking probe response frames at all. That > > seems like a mistake. Can you try this? > > I had considered this, but the spec says that it's at least valid for > the AP to be sending ECSAs in probe responses. IEEE 802.11-2012 section > 10.3.3.2: > > ...an AP shall inform associated STAs that the AP is moving to a new > channel and/or operating class and maintain the association by > advertising the switch using Extended Channel Switch Announcement > elements in any transmitted Beacon frames, Probe Response frames, and > Extended Channel Switch Announcement frames until the intended channel > switch time. > > Perhaps we can still ignore them though? I suppose we'd expect to > receive some other frame with the ECSA before it actually happens. Anyway, your fix also eliminates the disconnects, so whichever solution you think best is fine. There is a build failure though. + ieee80211_sta_process_chanswitch(sdata, rx_status->mactime, + elems, true); Needs to be &elems here. Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2013-08-22 at 09:10 -0500, Seth Forshee wrote: > On Thu, Aug 22, 2013 at 04:01:03PM +0200, Johannes Berg wrote: > > On Thu, 2013-08-22 at 08:53 -0500, Seth Forshee wrote: > > > The Netgear WNDAP360 sends invalid ECSA IEs in probe response > > > frames > > > > I think we shouldn't be checking probe response frames at all. That > > seems like a mistake. Can you try this? > > I had considered this, but the spec says that it's at least valid for > the AP to be sending ECSAs in probe responses. IEEE 802.11-2012 section > 10.3.3.2: > > ...an AP shall inform associated STAs that the AP is moving to a new > channel and/or operating class and maintain the association by > advertising the switch using Extended Channel Switch Announcement > elements in any transmitted Beacon frames, Probe Response frames, and > Extended Channel Switch Announcement frames until the intended channel > switch time. > > Perhaps we can still ignore them though? I suppose we'd expect to > receive some other frame with the ECSA before it actually happens. I suppose that's to avoid clients connecting to it when they find the AP, I don't see any reason to actually react to that in our code - we should have picked up a beacon already anyway. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index cc9e02d..f921b67 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -1054,6 +1054,13 @@ ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata, if (!ieee80211_operating_class_to_band( elems->ext_chansw_ie->new_operating_class, &new_band)) { + /* + * Some APs send invalid ECSA IEs in probe response + * frames, so check for these and ignore them. + */ + if (beacon && elems->ext_chansw_ie->new_ch_num == 0 && + elems->ext_chansw_ie->new_operating_class == 0) + return; sdata_info(sdata, "cannot understand ECSA IE operating class %d, disconnecting\n", elems->ext_chansw_ie->new_operating_class);
The Netgear WNDAP360 sends invalid ECSA IEs in probe response frames which have the operating class and channel number fields set to 0, even when no channel switch is pending. mac80211 responds to invalid ECSAs by disconnecting. The result is that every scan when associated to one of these APs triggers a disconnect. Since these ECSAs are obviously bogus, ignore them in probe response and beacon frames. Do not disconnect. Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Seth Forshee <seth.forshee@canonical.com> --- net/mac80211/mlme.c | 7 +++++++ 1 file changed, 7 insertions(+)