Bug 200128 - [net80211] [patch]: exclude QoS Null frames from sequence number checking
Summary: [net80211] [patch]: exclude QoS Null frames from sequence number checking
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-05-11 13:00 UTC by Andriy Voskoboinyk
Modified: 2015-05-13 06:40 UTC (History)
1 user (show)

See Also:

Attachments
Do not check sequence number for QoS Null frames; set it for generated QoS Null frames to 0 (5.44 KB, patch)
2015-05-11 13:00 UTC, Andriy Voskoboinyk 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Voskoboinyk freebsd_committer freebsd_triage 2015-05-11 13:00:46 UTC 
Created attachment 156655 [details]
Do not check sequence number for QoS Null frames; set it for generated QoS Null frames to 0

From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513):
"The Sequence Control field for QoS (+)Null frames is ignored by the receiver upon reception."

At this moment, any <mode>_input() function interprets them as regular QoS data frames with TID = 0. As a result, stations, that use another TX sequence for QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the firmware), may experience significant packet loss with any other NIC in hostap mode.
Comment 1 commit-hook freebsd_committer freebsd_triage 2015-05-12 16:56:41 UTC 
A commit references this bug:

Author: adrian
Date: Tue May 12 16:55:52 UTC 2015
New revision: 282820
URL: https://svnweb.freebsd.org/changeset/base/282820

Log:
  Do not check sequence number for QoS Null frames; set it for generated QoS Null
  frames to 0

  From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513):
  "The Sequence Control field for QoS (+)Null frames is ignored by the receiver
  upon reception."

  At this moment, any <mode>_input() function interprets them as regular QoS data
  frames with TID = 0. As a result, stations, that use another TX sequence for
  QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the
  firmware), may experience significant packet loss with any other NIC in hostap
  mode.

  Tested:

  * wpi(4) (author)
  * iwn(4) - Intel 5100, STA mode (me)

  PR:		kern/200128
  Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>

Changes:
  head/sys/net80211/ieee80211.h
  head/sys/net80211/ieee80211_adhoc.c
  head/sys/net80211/ieee80211_hostap.c
  head/sys/net80211/ieee80211_input.h
  head/sys/net80211/ieee80211_output.c
  head/sys/net80211/ieee80211_sta.c
  head/sys/net80211/ieee80211_wds.c