summaryrefslogtreecommitdiffstats
path: root/sys/net80211
Commit message (Collapse)AuthorAgeFilesLines
* Fix multiple incorrect SYSCTL arguments in the kernel:hselasky2014-10-214-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* Mechanically convert to if_inc_counter().glebius2014-09-1910-32/+33
|
* After much toying around with this AMRR initial rate stuff,adrian2014-08-201-2/+3
| | | | | | | | | | | | | | | | 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)
* Undo r195846 for now - allow raw frame transmit in monitor mode.adrian2014-08-101-9/+3
| | | | | | | | | | | | | | | | | | 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.
* Use logical rather than bitwise OR in if() expression.ian2014-04-261-1/+1
|
* Add a SLEEP->SCAN transition. Without this a disassociate or scanadrian2014-04-251-9/+8
| | | | | | | | | | | | | 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)
* Modify the ioctl path to support querying things if the vap state isadrian2014-04-241-7/+7
| | | | | | | | | | | | 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)
* Begin fleshing out support for net80211 provided (legacy) sleep management.adrian2014-04-243-5/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Add a capability to indicate that the net80211 stack should be doingadrian2014-04-241-0/+1
| | | | RUN->SLEEP->RUN transitions for station mode sleep management.
* Allow frames to be transmitted in either RUN or SLEEP stateadrian2014-04-231-10/+25
| | | | | | | 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.
* Allow the state of the interface to be "up" if the VAP is in SLEEP state.adrian2014-04-231-1/+2
| | | | | Without this, the carrier will drop when the NIC transitions to SLEEP and nothing will ever transmit.
* Remove IPX support.glebius2014-03-141-24/+0
| | | | | | | | | | | 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.
* Another round of removing historical mbuf(9) allocator flags.glebius2014-01-161-1/+1
| | | | | | They are breeding! New ones arouse since last round. Sponsored by: Nginx, Inc.
* Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.kevlo2014-01-088-19/+19
| | | | | | | | | | | 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
* Make sure any waiters on the scan results get notified if the scan taskadrian2013-11-291-0/+1
| | | | | | | | | | | 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
* Fix typo in comment.rpaulo2013-11-291-1/+1
|
* Fix AMRR to correctly select the initial rate.adrian2013-11-091-5/+5
| | | | | | | | | | | | | | | | | | | | | | | 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
* Don't return ENOBUFS if the transmit path handles the frame but queues it ↵adrian2013-11-061-4/+8
| | | | | | | | (eg in power save.) This is definitely an MFC candidate for 10.0-REL. MFC after: 1 week
* Don't treat the node as an 11n node if 11n rates are disabled.adrian2013-10-311-0/+8
| | | | | | | | 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
* - Provide necessary includes, that before came via if.h pollution.glebius2013-10-282-5/+4
| | | | | | | - Remove unnecessary ones. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Include necessary headers that now are available due to pollutionglebius2013-10-285-0/+8
| | | | | | | via if_var.h. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Provide includes that are needed in these files, and before were readglebius2013-10-263-0/+10
| | | | | | | in implicitly via if.h -> if_var.h pollution. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* The r48589 promised to remove implicit inclusion of if_var.h soon. Prepareglebius2013-10-2623-0/+24
| | | | | | | | 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.
* Fix a use-after-free node reference issue when waiting for a returnadrian2013-10-243-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix the "am I a net80211 vap" check for bpf listeners.adrian2013-10-101-2/+2
| | | | | | | | | | | 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)
* Create a new function to complete 802.11 mbuf transmission.adrian2013-08-272-0/+33
| | | | | | | | | | | | | | | | | 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)
* Migrate the ff_encap1() routine out into the normal output code.adrian2013-08-263-39/+42
| | | | | This will eventually be used by the A-MSDU encapsulation code that I'm writing - the sub-frame encapsulation requirement is the same.
* Add in some backwards compatability hacks to make -HEAD net80211 compileadrian2013-08-223-0/+27
| | | | on -9.
* Reorder the mbuf defines to make more sense and group related flagsandre2013-08-191-8/+5
| | | | | | | | | | | | | | 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
* Migrate the net80211 protocol specific use of M_FRAG, M_FIRSTFRAG andandre2013-08-191-2/+5
| | | | | | | | 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
* Add m_clrprotoflags() to clear protocol specific mbuf flags at up andandre2013-08-192-2/+4
| | | | | | | | downwards layer crossings. Consistently use it within IP, IPv6 and ethernet protocols. Discussed with: trociny, glebius
* Don't return ENOTSUPP here - the net80211 pluggable ioctl API will treatadrian2013-08-181-2/+2
| | | | | | this as the final item in the linker set and not try others. This stopped the fast frames IOCTLs from being called.
* Return the correct status if ieee80211_ff_check() consumes the mbuf.adrian2013-08-181-2/+1
| | | | I broke this when converting the net80211 TX path to use if_transmit.
* Replace the homegrown implementation of nitems() with calls to nitems()rpaulo2013-08-146-56/+37
| | | | | | | | | (param.h). Operating systems that don't have nitems() can easily define it on their own net80211 OS-specific header file. Discussed with: adrian
* Blank m_nextpkt before passing it up.adrian2013-08-121-0/+1
|
* When flushing packets from the powersave queue, make sure thatadrian2013-08-121-0/+1
| | | | | m_nextpkt is NULL before passing it up to the parent transmit method.
* Add in missing m_free()'s during error conditions.adrian2013-08-101-0/+6
|
* Convert net80211 over to using if_transmit for the dispatch from theadrian2013-08-0812-61/+54
| | | | | | | | | | | | | | | | | | | | | | | | upper layer(s). This eliminates the if_snd queue from net80211. Yay! This unfortunately has a few side effects: * It breaks ALTQ to net80211 for now - sorry everyone, but fixing parallelism and eliminating the if_snd queue is more important than supporting this broken traffic scheduling model. :-) * There's no VAP and IC flush methods just yet - I think I'll add some NULL methods for now just as placeholders. * It reduces throughput a little because now net80211 will drop packets rather than buffer them if the driver doesn't do its own buffering. This will be addressed in the future as I implement per-node software queues. Tested: * ath(4) and iwn(4) in STA operation
* Allow net80211 to compile on stable/9 and stable/8.adrian2013-08-074-0/+22
|
* Fix compilation when debugging is disabled.adrian2013-07-281-2/+1
|
* Commit the missing header change.adrian2013-07-281-0/+2
|
* Refactor the VAP transmit path code into a utility function that bothadrian2013-07-282-217/+155
| | | | | | | | | | the normal and the mesh transmit paths can use. The API is a bit horrible because it both consumes the mbuf and frees the node reference regardless of whether it succeeds or not. It's a hold-over from how the code behaves; it'd be nice to have it not free the node reference / mbuf if TX fails and let the caller decide what to do.
* Add ieee80211_add_{qos,wpa,rsn}() functions since they are needed by anrpaulo2013-07-253-40/+46
| | | | | | OpenBSD driver that is being ported to FreeBSD. Reviewed by: adrian
* Make kassert_printf use __printflike.alfred2013-07-071-1/+1
| | | | | | Fix associated errors/warnings while I'm here. Requested by: avg
* Add a missing unlock.adrian2013-07-051-0/+1
|
* Document the current 11n rate selection shortcoming in the AMRR code.adrian2013-07-051-0/+8
|
* Implement basic 802.11n awareness in the PHY and AMRR rate control code.adrian2013-07-043-30/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to MCS23 rates (3x3.) * Populate the rate code -> rate index lookup table with MCS _and_ normal rates, but _not_ the basic rate flag. Since the basic rate flag is the same as the MCS flag, we can only use one. * Introduce some accessor inlines that do PLCP and rate table lookup/access and enforce that it doesn't set the basic rate bit. They're not designed for MCS rates, so it will panic. * Start converting drivers that use the rate table stuff to use the accessor inlines and strip the basic flag. * Teach AMRR about basic 11n - it's still as crap for MCS as it is being used by iwn, so it's not a step _backwardS_. * Convert iwn over to accept 11n MCS rates rather than 'translate' legacy to MCS rates. It doesn't use a lookup table any longer; instead it's a function which takes the current node (for HT parameters) and the rate code, and returns the hardware PLCP code to use. Tested: * ath - it's a no-op, and it works that way * iwn - both 11n and non-11n
* Don't panic the kernel if we run wpa_supplicant on a hostap VAP.rpaulo2013-06-291-1/+3
| | | | Reviewed by: adrian
* Fix typo (dbM -> dBm)eadler2013-06-141-1/+1
| | | | | Submitted by: Daan@vitsch.nl Reviewed by: adrian
* Don't hold the node lock over the iterator.adrian2013-06-071-4/+24
| | | | | | | | | | | | | | | | The "find node" function call will increase the node reference anyway; so there's no reason to hold the node table lock during the MLME change. The only reason I could think of is to stop overlapping mlme ioctls from causing issues, but this should be fixed a different way. This fixes a whole class of LORs that creep up when nodes are being timed out or removed by hostapd. Tested: * AR5416, hostap, with nodes coming and going. No LORs or stability issues were observed.
OpenPOWER on IntegriCloud