CHROMIUMOS: mac80211: Filter duplicate IE ids
authorPaul Stewart <pstew@chromium.org>
Wed, 7 Mar 2012 05:02:11 +0000 (21:02 -0800)
committerOlof Johansson <olof@lixom.net>
Fri, 1 Jun 2012 07:02:35 +0000 (00:02 -0700)
commitd70145c268c09795605f5eac38fc56bf7bb0427a
tree0ea78cbf12576109a66d5c1cfcd50980265ebe96
parentb90f4450c2d6b8fa08543563726b56001074d966
CHROMIUMOS: mac80211: Filter duplicate IE ids

mac80211 is lenient with respect to reception of corrupted beacons.
Even if the frame is corrupted as a whole, the available IE elements
are still passed back and accepted, sometimes replacing legitimate
data.  It is unknown to what extent this "feature" is made use of,
but it is clear that in some cases, this is detrimental.  One such
case is reported in http://crosbug.com/26832 where an AP corrupts
its beacons but not its probe responses.

One approach would be to completely reject frames with invaid data
(for example, if the last tag extends beyond the end of the enclosing
PDU).  The enclosed approach is much more conservative: we simply
prevent later IEs from overwriting the state from previous ones.
This approach hopes that there might be some salient data in the
IE stream before the corruption, and seeks to at least prevent that
data from being overwritten.  This approach will fix the case above.

Further, we flag element structures that contain data we think might
be corrupted, so that as we fill the mac80211 BSS structure, we try
not to replace data from an un-corrupted probe response with that
of a corrupted beacon, for example.

Short of any statistics gathering in the various forms of AP breakage,
it's not possible to ascertain the side effects of more stringent
discarding of data.

BUG=chromium-os:26832
TEST=Rerun and ensure association is unhindered for non-broken APs.
[chromeos-3.2 compile only]

Change-Id: I79742107a935590ec29e2c049b4658d36133ec55
Signed-off-by: Paul Stewart <pstew@chromium.org>
[REBASE-3.3: put parse_error into existing struct]
net/wireless/util.c