History log of /freebsd-10-stable/sys/net80211/ieee80211_output.c
Revision Date Author Comments
# 283855 31-May-2015 ae

MFC r283313:
Properly update TX statistics for wlan(4).
ieee80211_pwrsave() can fail due to queue overflow, check its return code
and increment oerrors counter when it fails. Also handle more error cases
and update oerrors counter when we don't send mbuf due to some errors.
Return ENETDOWN when parent interface isn't ready. Update obytes and omcasts
counters in corresponding places.

PR: 184626
Differential Revision: https://reviews.freebsd.org/D2621


# 262007 16-Feb-2014 kevlo

MFC r260444:

Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.

The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by: adrian, rpaulo


# 259175 10-Dec-2013 gavin

Merge r257065 (by adrian) from head:

Fix a use-after-free node reference issue when waiting for a return
from a management frame transmission.

This bug is a bit loopy, so here goes.

The underlying cause is pretty easy to understand - the node isn't
referenced before passing into the callout, so if the node is deleted
before the callout fires, it'll dereference free'd memory.

The code path however is slightly more convoluted.

The functions _say_ mgt_tx - ie management transmit - which is partially
true. Yes, that callback is attached to the mbuf for some management
frames. However, it's only for frames relating to scanning and
authentication attempts. It helpfully drives the VAP state back to
"SCAN" if the transmission fails _OR_ (as I subsequently found out!)
if the transmission succeeds but the state machine doesn't make progress
towards being authenticated and active.

Now, the code itself isn't terribly clear about this.

It _looks_ like it's just handling the transmit failure case.

However, when you look at what goes on in the transmit success case, it's
moving the VAP state back to SCAN if it hasn't changed state since
the time the callback was scheduled. Ie, if it's in ASSOC or AUTH still,
it'll go back to SCAN. But if it has transitioned to the RUN state,
the comparison will fail and it'll not transition things back to the
SCAN state.

So, to fix this, I decided to leave everything the way it is and merely
fix the locking and remove the node reference.

The _better_ fix would be to turn this callout into a "assoc/auth request"
timeout callback and make the callout locked, thus eliminating all races.
However, until all the drivers have been fixed so that transmit completions
occur outside of any locking that's going on, it's going to be impossible
to do this without introducing LORs. So, I leave some of the evilness
in there.

Candidate for 10.0.


# 259172 10-Dec-2013 gavin

Merge r257754 (by adrian) from head:

Don't return ENOBUFS if the transmit path handles the frame but queues
it (eg in power save.)

10.0 candidate.

PR: kern/183727


# 283855 31-May-2015 ae

MFC r283313:
Properly update TX statistics for wlan(4).
ieee80211_pwrsave() can fail due to queue overflow, check its return code
and increment oerrors counter when it fails. Also handle more error cases
and update oerrors counter when we don't send mbuf due to some errors.
Return ENETDOWN when parent interface isn't ready. Update obytes and omcasts
counters in corresponding places.

PR: 184626
Differential Revision: https://reviews.freebsd.org/D2621


# 262007 16-Feb-2014 kevlo

MFC r260444:

Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.

The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by: adrian, rpaulo


# 259175 10-Dec-2013 gavin

Merge r257065 (by adrian) from head:

Fix a use-after-free node reference issue when waiting for a return
from a management frame transmission.

This bug is a bit loopy, so here goes.

The underlying cause is pretty easy to understand - the node isn't
referenced before passing into the callout, so if the node is deleted
before the callout fires, it'll dereference free'd memory.

The code path however is slightly more convoluted.

The functions _say_ mgt_tx - ie management transmit - which is partially
true. Yes, that callback is attached to the mbuf for some management
frames. However, it's only for frames relating to scanning and
authentication attempts. It helpfully drives the VAP state back to
"SCAN" if the transmission fails _OR_ (as I subsequently found out!)
if the transmission succeeds but the state machine doesn't make progress
towards being authenticated and active.

Now, the code itself isn't terribly clear about this.

It _looks_ like it's just handling the transmit failure case.

However, when you look at what goes on in the transmit success case, it's
moving the VAP state back to SCAN if it hasn't changed state since
the time the callback was scheduled. Ie, if it's in ASSOC or AUTH still,
it'll go back to SCAN. But if it has transitioned to the RUN state,
the comparison will fail and it'll not transition things back to the
SCAN state.

So, to fix this, I decided to leave everything the way it is and merely
fix the locking and remove the node reference.

The _better_ fix would be to turn this callout into a "assoc/auth request"
timeout callback and make the callout locked, thus eliminating all races.
However, until all the drivers have been fixed so that transmit completions
occur outside of any locking that's going on, it's going to be impossible
to do this without introducing LORs. So, I leave some of the evilness
in there.

Candidate for 10.0.


# 259172 10-Dec-2013 gavin

Merge r257754 (by adrian) from head:

Don't return ENOBUFS if the transmit path handles the frame but queues
it (eg in power save.)

10.0 candidate.

PR: kern/183727