[PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[Seth Forshee]

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(+)

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);
-- 
1.8.1.2

Re: [PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[Johannes Berg]

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

Re: [PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[Seth Forshee]

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

Re: [PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[Seth Forshee]

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

Re: [PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames

[Johannes Berg]

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