Bug 178378 - [net80211] crypto state isn't reset during a reassociation
Summary: [net80211] crypto state isn't reset during a reassociation
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 1.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: Adrian Chadd
URL:
Keywords:
Depends on:
Blocks: 283171
  Show dependency tree / graph
 
Reported: 2013-05-06 23:00 UTC by Adrian Chadd
Modified: 2024-12-07 01:00 UTC (History)
1 user (show)

See Also:

Attachments
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 Adrian Chadd freebsd_committer freebsd_triage 2013-05-06 23:00:01 UTC 
When a station reassociates, the crypto state (eg CCMP RSC/TSC counters) may not be reset "right".

How-To-Repeat: What I see:

* doing lots of UDP TX from FreeBSD STA -> FreeBSD AP;
* the station reassociates;
* .. lots of CCMP replay attack complaints on the AP side.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-05-07 02:37:33 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:46 UTC 
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 3 Bjoern A. Zeeb freebsd_committer freebsd_triage 2024-03-05 21:27:47 UTC 
Adrian, did you ever fix this or is it still assumed an issue?
Comment 4 Adrian Chadd freebsd_committer freebsd_triage 2024-03-06 16:14:30 UTC 
oh good question! want me to go re-test it against -HEAD?

I think this bug was partially due to some race and partially due to full TX queues. It should be easy to reproduce again with a variety of hardware!
Comment 5 Bjoern A. Zeeb freebsd_committer freebsd_triage 2024-06-08 01:27:59 UTC 
(In reply to Adrian Chadd from comment #4)

Yes why not?
I'll assign it to you given you are working in that area currently anyway.