Commit Graph

985 Commits

Author SHA1 Message Date
Ian Lepore
6ef6968de5 Use SYSCTL_OUT_STR() to return strings.
PR:		195668
2015-03-14 21:41:00 +00:00
Adrian Chadd
b83391bf44 Fix kern/196290 - don't announce 11n HTINFO rates if the channel is
configured as 11b.

This came up when debugging other issues surrounding scanning and
channel modes.

What's going on:

* The VAP comes up as an 11b VAP, but on an 11n capable NIC;
* .. it announces HTINFO and MCS rates;
* The AP thinks it's an 11n capable device and transmits 11n frames
  to the STA;
* But the STA is in 11b mode, and thus doesn't receive/ACK the frames.

It didn't happen for the ath(4) devices as the AR5416/AR9300 HALs
unconditionally enable MCS frame reception, even if the channel
mode is not 11n.  But the Intel NICs are configured in 11b/11a/11g
modes when doing those, even if 11n is enabled and available.

So, don't announce 11n capabilities if the VAP isn't on an 11n
channel when sending management assocation request / reassociation
request frames.

TODO:

* Lots more testing - 11n should be "upgraded" after association,
  and I just want to make sure I haven't broken 11n upgrade.
  I shouldn't have - this is only happening for /sending/ association
  requests, which APs aren't doing.

Tested:

* ath(4) APs (AR9331, AR7161+AR9280, AR934x)
* AR5416, STA mode
* Intel 5100, STA mode

PR:		kern/196290
2015-02-27 04:45:47 +00:00
Adrian Chadd
21969c6c24 Switch around the order of static inline to be in line with how it's
used elsewhere, and to keep gcc-4.7 happy.

This is a request from the DragonflyBSD project.
2015-01-11 18:43:45 +00:00
Adrian Chadd
a1cbd04334 Global-ify channel_type() - this fixes non-debug net80211 builds. 2015-01-06 18:25:10 +00:00
Adrian Chadd
cc6dd788c6 Refactor and split out the net80211 software scan engine from the rest
of the scan API.

The eventual aim is to have 'ieee80211_scan.c' have the net80211 and
driver facing scan API to start, finish and continue doing scanning
while 'ieee80211_swscan.c' implements the software scanner that
runs the scan task, handles probe request/reply bits, configures
the VAP off-channel, changes channel and does the scanning bits.

For NICs that do no scanning at all, the existing code is needed.
ath(4) and most of the other NICs (dumb USB ones in particular)
do little to no scan offload - it's all done in software.

Some NICs may do single channel at a time scanning; I haven't really
checked them out in detail.

iwn(4), the upcoming 7260 driver stuff, the new Qualcomm Atheros
11ac chipsets and the Atheros mobile/USB full-offload chips all
have complete scan engines in firmware.  We don't have to drive
any of it at all - the firmware just needs to be told what to scan,
when to scan, how long to scan.  It'll take care of going off
channel, pausing TX/RX appropriately, sending sleep notification
to the AP, sending probe requests and handling probe responses.
It'll do passive/active scan itself.  It's almost completely
transparent to the network stack - all we see are scan notifications
when it finishes scanning each channel and beacons/probe responses
when it does its thing.  Once it's done we get a final notification
that the scan is complete, with some scan results in the message.
The iwn(4) NICs handle doing active scanning too as an option
and will handle waiting appropriately on 5GHz passive channels
before active scanning.

There's some more refactoring, tidying up and lock assertions to
sprinkle around to tidy this whole thing up before I turn swscan.c
into another set of ic methods to override by the driver or
alternate scan module.  So in theory this is all one big no-op
commit.  In theory.

Tested:

* iwn(4) 5200, STA mode
* ath(4) 6205, STA mode
* ath(4) - various NICs, AP mode
2015-01-06 02:08:45 +00:00
Robert Watson
ed6a66ca6c To ease changes to underlying mbuf structure and the mbuf allocator, reduce
the knowledge of mbuf layout, and in particular constants such as M_EXT,
MLEN, MHLEN, and so on, in mbuf consumers by unifying various alignment
utility functions (M_ALIGN(), MH_ALIGN(), MEXT_ALIGN() in a single
M_ALIGN() macro, implemented by a now-inlined m_align() function:

- Move m_align() from uipc_mbuf.c to mbuf.h; mark as __inline.
- Reimplement M_ALIGN(), MH_ALIGN(), and MEXT_ALIGN() using m_align().
- Update consumers around the tree to simply use M_ALIGN().

This change eliminates a number of cases where mbuf consumers must be aware
of whether or not mbufs returned by the allocator use external storage, but
also assumptions about the size of the returned mbuf. This will make it
easier to introduce changes in how we use external storage, as well as
features such as variable-size mbufs.

Differential Revision:	https://reviews.freebsd.org/D1436
Reviewed by:	glebius, trasz, gnn, bz
Sponsored by:	EMC / Isilon Storage Division
2015-01-05 09:58:32 +00:00
Adrian Chadd
1de34f860e Update ieee80211_sta_tim_notify() to do double duty - handle STA sleep
to awake transition as well as handle waking up a VAP in STA powersave
mode if it's in bgscan.

This was a reasonably hairy bug to try and figure out and it became
more obvious because of stuff I've done.

Specifically:

* a NIC would go into bgscan mode - either because of a bgscan timer
  or wpa_supplicant asked it to;
* the AP would indicate there's traffic for the STA by setting the TIM
  bitmap bit for it;
* mindwell would be met during scan, so it'd wake up and break out of
  the scan loop in scan_task(), but
* because the scan wasn't completed, it wouldn't bring the VAP out of
  STA mode powersave (so it wouldn't tell the AP about it and it would
  block VAP TX);
* .. but because we kept seeing the TIM bit set, ic->ic_lastdata was
  being constantly updated, and ..
* bgscancont() would thus never say "yes we can continue a bgscan"
  so the bgscan would hang and never make progress.

Now, I do see this particular state occur on iwn(4) - /however/ -
this NIC has the firmware call ieee80211_scan_next() once the firmware
scan for that channel has completed.  This has the effect of moving
the scan along to the next channel.  I do see the debug that I'm adding
where we see a beacon with a TIM bit set whilst we're in bgscan, so
the condition about waking up to receive traffic is triggering.
It just won't cause a hang.

For other NICs - all of the USB ones and at least ath(4) -
ieee80211_scan_next() / ieee80211_scan_done() isn't called.
So it relies upon the mindwell timer, the beacon receive and the
beacon / probe response -> ieee80211_add_scan() to move along
the scan state.

In the above case, mindwell triggered, there's no beacons triggering
the scan_add code to move things along, and we weren't waking things
up when seeing the TIM set for us.  So it just hung until the interface
was dropped.

So, the short-term fix here is to do what the comment in scan_task()
says - if we are in bgscan mode and we see our TIM bit set, just wake
up the VAP.  If it's already awake then it's a nop.  If we're awake
then we transition to awake and handle the traffic.  Once there's no
TX or RX traffic going on, ic->ic_lastdata won't be updated anymore
and bgscancont() will continue.

This was triggered more often after my initial SLEEP state handling
for software sleep states - because now I update ic->ic_lastdata
upon seeing a TIM bit set, not just the RX of the subsequent traffic.
That's needed so the thing doesn't ping-pong up and down between
seeing the TIM bit set, sending the "I'm awake" NULL data frame, and
starting to receive data from the AP.

I'd like to subsequently split ic_lastdata into two - one for TX and
one for RX - so it becomes easier to use the correct one (or both!)
when making decisions like whether to scan, go to sleep, etc.

I'd appreciate this getting some further testing.

Tested:

* rsu(4), STA mode, bgscan on
* iwn(4), STA mode, bgscan on
2014-12-21 04:58:45 +00:00
Adrian Chadd
3b00b9a60a Break out the unicast/multicast TIM bit setting into "set something
that indicates we have traffic" bit and a "do something if we have
traffic bit."

I'm going to be fleshing out this stuff more over time and it'll make
more sense to have it broken out into two pieces here.
2014-12-21 04:48:54 +00:00
Adrian Chadd
2c6179401b Add more debugging to try and track down this scan hang nonsense. 2014-12-21 01:15:55 +00:00
Adrian Chadd
f13a4d33ef Add some more debugging to the scan cancel methods - I'd like to see
what situations would cause the scan cancel's to not complete.
2014-12-20 23:41:37 +00:00
Adrian Chadd
92c59ab94f Document where in scan_task the scan state can change, and potentially
deal/log a warning if the scan flags change during one of those race
windows.

It's highly likely that I need to actually sit down and replace this
scan infrastructure at some point.  It has some other side effects too -
the scan task is a blocking task scheduled in the net80211 taskqueue;
so drivers that use this taskqueue have other things not run.  Eek.

If you see this printf happen then please let me know!
2014-12-20 19:41:31 +00:00
Adrian Chadd
de981aecde Make ieee80211_add_ssid() public.
Some drivers use private copies of this.

PR:		kern/196116
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2014-12-19 01:39:58 +00:00
Adrian Chadd
9c75c3d4ba Fix the scan handling for 11b->11g upgrades in a world where, well,
it's not just 11b/11g.

The following was happening, and it's quite .. annoyingly grr-y.

* create vap, setup wpa_supplicant with no bgscanning, etc - there's
  no call to ieee80211_media_change, so vap->iv_des_mode is
  IEEE80211_MODE_AUTO;
* do ifconfig wlan0 scan - same thing, media_change doesn't get called,
  iv_des_mode stays as auto.
* But then, run wpa_cli and do 'scan' - it'll do a media change.
* if you're on 11ng, vap->iv_des_mode gets changed to IEEE80211_MODE_11NG
* Then makescanlist() is called.  There's a block of code that gets
  called if iv_des_mode != IEEE80211_MODE_AUTO, and it does this:

		if (vap->iv_des_mode != IEEE80211_MODE_11G ||
			    mode != IEEE80211_MODE_11B)
			continue;
		mode = IEEE80211_MODE_11G;	/* upgrade */

* .. now, iv_des_mode is not IEEE80211_MODE_11G, so it always runs
  'continue'
* .. and thus the scan list stays empty and no further channel
  scans occur. Ever.(1)

If you then disassociate and try associating to something, your
scan table has likely been purged / aged out and you'll never
see anything in the scan list.

(1) You need to do 'ifconfig wlan0 mode auto' or just destroy/re-create
    the VAP to get working wireless again.

Tested:

* iwn(4) - intel 5300 wifi; STA mode; using wpa_supplicant; bgscan
  enabled -and- wpa_supplicant scanning.

Thanks to:

* Everyone who kept poking me about this and wondering why the hell
  their wifi would eventually stop seeing scan lists.  Grr.
  I eventually snapped this evening and dug back into this code.
2014-12-18 05:17:18 +00:00
Hans Petter Selasky
f0188618f2 Fix multiple incorrect SYSCTL arguments in the kernel:
- Wrong integer type was specified.

- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.

- Logical OR where binary OR was expected.

- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.

- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.

- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.

- Updated "EXAMPLES" section in SYSCTL manual page.

MFC after:	3 days
Sponsored by:	Mellanox Technologies
2014-10-21 07:31:21 +00:00
Gleb Smirnoff
dea4512157 Mechanically convert to if_inc_counter(). 2014-09-19 09:20:55 +00:00
Adrian Chadd
ebb1240823 After much toying around with this AMRR initial rate stuff,
I've decided that for 11n rates it's best to start (very) low and work
our way up.

So, from now on, the initial rate for AMRR 11n is MCS4.
It doesn't try MCS12 or MCS20 - at low signal strengths those don't
work very well at all.

AMRR will step the rate control up over time if things work out better.

Tested:

* Intel 5100
* Intel 5300 (using local diffs to test out 3x3 stream support)
2014-08-20 09:10:03 +00:00
Adrian Chadd
31f92dec23 Undo r195846 for now - allow raw frame transmit in monitor mode.
The original commit was supposed to stop the ability to do raw frame
injection in monitor mode to arbitrary channels (whether supported
by regulatory or not) however it doesn't seem to have been followed
by any useful way of doing it.

Apparently AHDEMO is supposed to be that way, but it seems to require
too much fiddly things (disable scanning, set a garbage SSID, etc)
for it to actually be useful for spoofing things.

So for now let's just disable it and instead look to filter transmit
in the output path if the channel isn't allowed by regulatory.
That way monitor RX works fine but TX will be blocked.

I don't plan on MFC'ing this to -10 until the regulatory enforcement
bits are written.
2014-08-10 08:35:42 +00:00
Ian Lepore
daa963252e Use logical rather than bitwise OR in if() expression. 2014-04-26 23:22:49 +00:00
Adrian Chadd
f3b04ec629 Add a SLEEP->SCAN transition. Without this a disassociate or scan
request during SLEEP results in a hang.

Whilst I'm here, add in some disabled code that will transition to RUN
if there's multicast traffic.  It's not needed for Atheros hardware but
it may be for other hardware.

Tested:

* AR5416, STA mode (powersave)
* AR5212, STA mode (powersave)
2014-04-25 01:20:10 +00:00
Adrian Chadd
1b74d2a4ad Modify the ioctl path to support querying things if the vap state is
SLEEP rather than RUN.

Without this things like 'ifconfig wlan0 list sta' don't work when the
NIC is power save.

Tested:

* AR5212, STA mode (with powersave)
* AR5416, STA mode (with powersave)
2014-04-24 23:12:40 +00:00
Adrian Chadd
902840a5db Begin fleshing out support for net80211 provided (legacy) sleep management.
This transitions the VAP in and out of SLEEP state based on:

* whether there's been an active transmission in the last (hardcoded) 500ms;
* whether the TIM from the AP indicates there is data available.

It uses the beacon reception to trigger the active traffic check.
This way there's no further timer running to wake up the CPU
from its own sleep states.

Right now the VAP isn't woken up for multicast traffic - mostly because
the only NIC I plan on doing this for right will auto wakeup and stay
awake for multicast traffic indicated in the TIM.  So I don't have
to manually keep the hardware awake.

This doesn't do anything if the NIC doesn't advertise it implements
the new SWSLEEP capability AND if the VAP doesn't have powersave
enabled.

It also doesn't do much with ath(4) as it doesn't currently implement
the SLEEP state.

Tested:

* AR5416, STA mode (with local ath(4) changes)
2014-04-24 01:39:53 +00:00
Adrian Chadd
3914f0881e Add a capability to indicate that the net80211 stack should be doing
RUN->SLEEP->RUN transitions for station mode sleep management.
2014-04-24 01:28:39 +00:00
Adrian Chadd
ddd9ebbcec Allow frames to be transmitted in either RUN or SLEEP state
Frames transmitted during SLEEP state should be queued in the
power save queue before waking the unit up.  Otherwise DHCP
requests and such will be dropped if the NIC is asleep - the
NIC will wake up but not transmit the frame.
2014-04-23 22:44:49 +00:00
Adrian Chadd
9f098ac76f Allow the state of the interface to be "up" if the VAP is in SLEEP state.
Without this, the carrier will drop when the NIC transitions to SLEEP
and nothing will ever transmit.
2014-04-23 22:43:39 +00:00
Gleb Smirnoff
2c284d9395 Remove IPX support.
IPX was a network transport protocol in Novell's NetWare network operating
system from late 80s and then 90s. The NetWare itself switched to TCP/IP
as default transport in 1998. Later, in this century the Novell Open
Enterprise Server became successor of Novell NetWare. The last release
that claimed to still support IPX was OES 2 in 2007. Routing equipment
vendors (e.g. Cisco) discontinued support for IPX in 2011.

Thus, IPX won't be supported in FreeBSD 11.0-RELEASE.
2014-03-14 02:58:48 +00:00
Gleb Smirnoff
b8c83a1957 Another round of removing historical mbuf(9) allocator flags.
They are breeding! New ones arouse since last round.

Sponsored by:	Nginx, Inc.
2014-01-16 13:44:47 +00:00
Kevin Lo
5945b5f5ab 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
2014-01-08 08:06:56 +00:00
Adrian Chadd
1db2772f43 Make sure any waiters on the scan results get notified if the scan task
decides to do nothing.

If this isn't done, then a scan request whilst a scan occurs in an active
channel set or a completed channel set will hang.

Tested:

* Intel 5100, STA mode
2013-11-29 22:24:57 +00:00
Rui Paulo
1a707877c1 Fix typo in comment. 2013-11-29 07:55:44 +00:00
Adrian Chadd
5140f9e6ae Fix AMRR to correctly select the initial rate.
There were two bugs:

* If the initial lowest rate didn't go through the loop at least once,
  the AMRR rate index would be the highest rate in the table
  (eg the rix mapping to MCS15) but rate would stay at the default
  value, namely 0.

  This meant that the initial rate selection would be MCS15 _but_ the
  node ni_txrate value would be MCS0.

* If the node is 11n, then break out of the loop correctly.  Beforehand,
  my initial 11n AMRR commit would immediately exit out as it would
  fail the 11n check, then it would always fall through to the non-11n
  rate which would then see if it was < 36mbit (ie, "72"), which would
  always match.  Hence, it'd always return MCS15.

Tested:

* Intel Centrino 2230 STA (local changes), STA mode
* Intel Wifi 5100, STA
2013-11-09 07:30:13 +00:00
Adrian Chadd
c6d5b60008 Don't return ENOBUFS if the transmit path handles the frame but queues it (eg in power save.)
This is definitely an MFC candidate for 10.0-REL.

MFC after:	1 week
2013-11-06 17:20:49 +00:00
Adrian Chadd
7f0660a04b Don't treat the node as an 11n node if 11n rates are disabled.
For now, the AMRR code only knows about _either_ MCS or non-MCS rates.
It doesn't know how to downgrade (ie, doing 11b CCK rates if MCS0 isn't
reliable.)

PR:		kern/183428
2013-10-31 02:04:53 +00:00
Gleb Smirnoff
104dc21415 - Provide necessary includes, that before came via if.h pollution.
- Remove unnecessary ones.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 22:26:03 +00:00
Gleb Smirnoff
c3322cb91c Include necessary headers that now are available due to pollution
via if_var.h.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 07:29:16 +00:00
Gleb Smirnoff
eedc7fd9e8 Provide includes that are needed in these files, and before were read
in implicitly via if.h -> if_var.h pollution.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 18:18:50 +00:00
Gleb Smirnoff
76039bc84f The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 17:58:36 +00:00
Adrian Chadd
e94527beaf 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.

Tested:

* AR5212, ath(4), STA mode
* 5100 and 4965 wifi, iwn(4), STA mode
2013-10-24 17:04:16 +00:00
Adrian Chadd
fce9c39777 Fix the "am I a net80211 vap" check for bpf listeners.
I changed it to use if_transmit a while ago but apparently with monitor
mode the if_transmit method is overridden.

This is (mostly) a workaround until a more permanent solution can be
found.

Submitted by:	Patrick Kelsey <kelsey@ieee.org>
Approved by:	re@ (gjb)
2013-10-10 19:56:31 +00:00
Adrian Chadd
36ee7775f4 Create a new function to complete 802.11 mbuf transmission.
The aim of this function is to eventually be the completion entry point
for all 802.11 encapsulated mbufs.  All the wifi drivers end up doing
what is in this function so it's an easy win to turn it into a net80211
method and abstract out this code.

Ideally the drivers will all eventually be modified to queue up completed
mbufs and call this function with all the driver locks not held.
This will allow for some much more interesting software queue handling
in the future (like net80211 based A-MSDU, fast-frames, A-MPDU aggregation
and retransmission.)

Tested:

* ath(4), iwn(4)
2013-08-27 14:37:13 +00:00
Adrian Chadd
74b4c76e4e Migrate the ff_encap1() routine out into the normal output code.
This will eventually be used by the A-MSDU encapsulation code that
I'm writing - the sub-frame encapsulation requirement is the same.
2013-08-26 09:52:05 +00:00
Adrian Chadd
b105165323 Add in some backwards compatability hacks to make -HEAD net80211 compile
on -9.
2013-08-22 05:53:47 +00:00
Andre Oppermann
5fc98a7895 Reorder the mbuf defines to make more sense and group related flags
together.

Add M_FLAG_PRINTF for use with printf(9) %b indentifier.

Use the generic mbuf flags print names in the net80211 code and adjust
the protocol specific bits for their new positions.

Change SCTP M_PROTO mapping from 5 to 1 to fit within the 16bit field
they use internally to store some additional information.

Discussed with:	trociny, glebius
2013-08-19 14:25:11 +00:00
Andre Oppermann
7100b4d04a Migrate the net80211 protocol specific use of M_FRAG, M_FIRSTFRAG and
M_LASTFRAG flags to protocol specific flags.

Remove the now unused M_FRAG, M_FIRSTFRAG and M_LASTFRAG mbuf flags.

Discussed with:	trociny, glebius, adrian
2013-08-19 14:07:31 +00:00
Andre Oppermann
86bd049144 Add m_clrprotoflags() to clear protocol specific mbuf flags at up and
downwards layer crossings.

Consistently use it within IP, IPv6 and ethernet protocols.

Discussed with:	trociny, glebius
2013-08-19 13:27:32 +00:00
Adrian Chadd
bfd3bbdb11 Don't return ENOTSUPP here - the net80211 pluggable ioctl API will treat
this as the final item in the linker set and not try others.

This stopped the fast frames IOCTLs from being called.
2013-08-18 23:40:30 +00:00
Adrian Chadd
11e0ddb146 Return the correct status if ieee80211_ff_check() consumes the mbuf.
I broke this when converting the net80211 TX path to use if_transmit.
2013-08-18 20:40:13 +00:00
Rui Paulo
a3e08d6f4c Replace the homegrown implementation of nitems() with calls to nitems()
(param.h).

Operating systems that don't have nitems() can easily define it on their own
net80211 OS-specific header file.

Discussed with:		adrian
2013-08-14 04:24:25 +00:00
Adrian Chadd
57b5fc5f3d Blank m_nextpkt before passing it up. 2013-08-12 22:27:53 +00:00
Adrian Chadd
4bd57e1078 When flushing packets from the powersave queue, make sure that
m_nextpkt is NULL before passing it up to the parent transmit
method.
2013-08-12 02:21:44 +00:00
Adrian Chadd
1df885c863 Add in missing m_free()'s during error conditions. 2013-08-10 21:46:58 +00:00