Bug 176201 - [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Summary: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ pa...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 9.1-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-17 00:10 UTC by PseudoCylon
Modified: 2015-05-10 06:59 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (1.03 KB, patch)
2013-02-17 00:10 UTC, PseudoCylon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description PseudoCylon 2013-02-17 00:10:01 UTC
When an 11n capable station try to associate with an AP, the station does not include maximum Rx size and ampdu density set by the driver into an association request packet. So that, the AP might generate ampdu packets bigger than the station can handle.

Detailed discussion can be found here.
http://lists.freebsd.org/pipermail/freebsd-wireless/2013-February/002878.html

Fix: In a brief testing, attached patch fixed the issue. But, need to be checked the patch doesn't break anything.


Patch attached with submission follows:
How-To-Repeat: 1) Set up an 11n station.
2) Capture an ASSOC_REQ packet sent by the station.
3) Read HT params in the packet.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-02-18 02:46:29 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Adrian Chadd freebsd_committer freebsd_triage 2014-12-27 03:03:07 UTC
Hm, this one slipped through. I'll go re-check the patch against what I have here and commit it if it looks good.

Sorry!
Comment 3 commit-hook freebsd_committer freebsd_triage 2015-05-10 06:58:02 UTC
A commit references this bug:

Author: adrian
Date: Sun May 10 06:57:53 UTC 2015
New revision: 282704
URL: https://svnweb.freebsd.org/changeset/base/282704

Log:
  Attempt to address Bug #176201 - don't advertise what the AP announced
  to us. Instead, advertise what we can do based on what the AP says and what
  we're capped at by the VAP settings.

  For non-STA modes we still advertise what our VAP settings are.

  It may be that I've over-complicated this and instead of capping things
  we can just always announce what we're capable of.  But this should at least
  stop the blatantly wrong handling of A-MPDU parameters.

  (I'll happily simplify things if someone can dig up a replacement, better
  compliant behaviour.)

  PR:		kern/176201

Changes:
  head/sys/net80211/ieee80211_ht.c