summaryrefslogtreecommitdiffstats
path: root/sys/net80211
Commit message (Collapse)AuthorAgeFilesLines
* net80211: add ieee80211_restart_all() call.avos2015-10-274-0/+28
| | | | | | | | | This call may be used when device cannot continue to operate normally (e.g., throws firmware error, watchdog timer expires) and need to be restarted. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D3998
* net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ↵adrian2015-10-121-1/+3
| | | | | | | | | | ieee80211_raw_output(). This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still doing that. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3774
* net80211: free node reference in the ieee80211_parent_xmitpkt() when error ↵adrian2015-10-127-36/+18
| | | | | | | | | | happened. Move error handling into ieee80211_parent_xmitpkt() instead of spreading it between functions. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3772
* net80211: separate mbuf cleanup from ieee80211_fragment()adrian2015-10-123-7/+19
| | | | | | | | | | | | * Create ieee80211_free_mbuf() which frees a list of mbufs. * Use it in the fragment transmit path and ath / uath transmit paths. * Call it in xmit_pkt() if the transmission fails; otherwise fragments may be leaked. This should be a big no-op. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3769
* net80211: reduce code duplication in the ieee80211_ioctl_setwmeparam() + fix ↵adrian2015-10-031-35/+17
| | | | | | | comments. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3701
* net80211: drop ieee80211_beacon_offsets parameter from ↵adrian2015-10-032-10/+9
| | | | | | | ieee80211_beacon_alloc() and ieee80211_beacon_update() Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3659
* net80211: drop redundant 3rd parameter from iv_key_set().adrian2015-10-032-5/+3
| | | | | | | | | The MAC can be fetched from the key struct. I added the ndis updates to make it compile. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3657
* net80211: add a possibility to retrieve current TX key without encapsulation.adrian2015-10-032-11/+23
| | | | | Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3639
* net80211: add new method for ieee80211_cipher (ic_setiv).adrian2015-10-035-46/+85
| | | | | | | | | This can be used to update IV state for the caller without adding information to the mbuf. Some hardware (eg rum) apparently requires bits of this. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3638
* net80211: get rid of tx_phase1_done flag (ieee80211_crypto_tkip.c).adrian2015-10-031-13/+5
| | | | | Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3596
* net80211: separate ieee80211_crypto_get_keyid() from ieee80211_crypto_encap()adrian2015-10-026-17/+39
| | | | | | | | | | | Tested: * rum(4), STA mode * rsu(4), STA mode * urtwn(4), STA mode Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3637
* Fix neeed -> neeeded.adrian2015-10-023-3/+3
| | | | | Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3595
* Defer calling into the driver to update the QOS (WME) configuration.adrian2015-09-292-1/+17
| | | | This gets called from the driver RX path which leads to driver re-entry.
* Remove some debugging that wasn't supposed to be there.adrian2015-09-281-2/+0
|
* Migrate the fast-frames transmit support away from using the txa_privateadrian2015-09-282-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | field and into a separate fast-frames staging pointer in ieee80211_node. The A-MPDU TX path allows txa_private to be used by drivers. So it will clash with any attempt to use fast-frames. Now, fast-frames is not really anything special - it's just a custom ethernet frame type that contains two MSDUs into one MPDU. So all the NIC has to support doing is transmitting up to a 4KiB frame with an arbitrary ethertype and bam! Fast-frames. However, using txa_private means we can /either/ do fast-frames or A-MPDU TX, so fast frames has been turned off in the Atheros HAL for 11n chipsets. This is a bit silly - it actually means that 802.11 performance to/from 11abg Atheros chips is actually better than between an 11abg atheros device and an 11n Atheros device. So: * create a new mbuf staging queue for fast frames. It only queues a single frame in the staging queue (and there's a top-level ic staging queue used for expiry/tracking) so it's just an mbuf pointer per TID. * Still use the ampdu TX packet counter to determine whether to do aggregation or not. It'll double count if we start doing both A-MPDU TX and fast frames, but that's not all that important right now. * Initialise the pps tracker so ticks isn't zero. This ensures that fast-frames actually gets used - without it, the ticks math overflows and the pps math always sets txa_pps=0. This is the same bug that plagued A-MPDU TX starting logic. This actually allows fast-frames transmit to occur between the AR9331 (in 11n HT/20 mode) and AR9170 (if_otus) in 11bg mode. Now, this is a great big no-op on atheros 11n hardware, so don't worry. It may mean you start seeing more reliable fast-frames transmission on 11abg hardware which may expose some more amusing bugs. TODO: * further testing and debugging of all of this before flipping on fast-frames in if_ath (for 11n) and if_otus.
* Comments, mostly to remind myself of what's going on and why.adrian2015-09-281-0/+21
|
* Abstract out the ampdu TX pps initialisation code so it can be reusedadrian2015-09-282-4/+15
| | | | | | | | | | | | | | | | | | in the superg fast-frames code. This harks back to an earlier commit (r280349) where I found that initialising the pps code with ticks=0 would cause hilariously bad hz ticks wraparound failures, leading to never actually aggregating traffic. This is still true for the superg path and so I have to do the same thing there. This is a big no-op; a subsequent commit will flip this on so it works with the fast-frames transmit path. Tested: * AR9170, otus(4) - STA mode, 11bg operation * AR9331, AP mode
* Perform some rather amusing layering violations to add mbuf tags to theadrian2015-09-265-34/+103
| | | | | | | | | | | | | | | | | net80211 receive path. This allows drivers (notably USB right now, but anything/everything!) to optionally defer bulk RX of 802.11 frames until /outside/ of the driver lock(s), rather than doing: UNLOCK(sc); ieee80211_input*() LOCK(sc); .. which is really stupid. The existing API is maintaned - if ieee80211_input() / ieee80211_input_all() is called then the RSSI/NF values are used. If the MIMO versions are called with a given rx status pointer then it's used. Else, it'll use whatever is in the RX mbuf tag.
* net80211: include one copy of struct ieee80211_beacon_offsets into ieee80211vapadrian2015-09-221-0/+1
| | | | | Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3658
* Remove duplicate use of RV(), LE_* and other macros.adrian2015-09-223-21/+10
| | | | | Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
* Add external facing methods to control TX A-MPDU negotiaton.adrian2015-09-222-6/+52
| | | | | | | Some fullmac devices may rely on the stack starting it but not doing it. Whilst here, remove a duplicate LE_* macro definition, thanks to Andriy Voskoboinyk <s3erios@gmail.com>.
* Define a rateval macro that drivers tend to hard-code.adrian2015-09-221-0/+1
| | | | | Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
* Add an external facing function to manually set the RX A-MPDU parametersadrian2015-09-182-0/+40
| | | | | | | | for re-ordering. Devices like if_rsu don't pass through action/management frames but do send firmware commands to inform us of things. One of those notifications is the RX A-MPDU negotiated parameters.
* Expose the wme_info IE method.adrian2015-09-182-1/+3
|
* Replay r286410. Change KPI of how device drivers that provide wirelessglebius2015-08-2711-409/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Reset the channel to the first available channel if the interfaceadrian2015-08-231-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | is configured on a channel that isn't valid in the new operating mode. This isn't strictly true - it should find the first channel that is available for the given operating mode. However, I think defaulting to the first channel is fine - it's typically available for all modes. If someone would like to correctly implement this feature - try to find a channel that is valid for the given operating mode and error out if we can't find one. This prevents various NICs (eg wpi(4)) from throwing a firmware error. Tested: * ath(4), STA/AP mode * iwn(4), STA/adhoc mode PR: kern/202502 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
* Revert the wifi ifnet changes until things are more baked and tested.adrian2015-08-0811-217/+409
| | | | | | | | | * 286410 * 286413 * 286416 The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
* Change KPI of how device drivers that provide wireless connectivity interactglebius2015-08-0711-409/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here: https://wiki.freebsd.org/projects/ifnet/net80211 Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated. Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
* Break out the current 802.11 software scan methods into an indirect table.adrian2015-06-085-98/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | In order for drivers to provide an alternate set of scan methods, these have to finally use an indirection table and all of the calls in ieee80211_scan.c need to use said table. For all existing drivers - this is basically a glorified, KBI-breaking functional no-op. This is also not the final form - too much functionality is currently hiding in ieee80211_scan_sw.c that should be in ieee80211_scan.c. That'll be the target of some follow-up commits. Note: * You have to recompile your kernel/drivers after this - the net80211 KBI has changed. * I'm not yet planning on bumping any versioning - I have a few more things to shuffle around. Tested: * urtwn(4) - STA mode * Intel 7260 in local repo - overriding the methods and table at attach time has the desired effect (ie, all the methods are called, but nothing is ever performed.)
* Remove the start-scan call and re-inline it for now.adrian2015-06-081-12/+1
|
* For now, just default to presenting "found" channels as 11g, not 11b.adrian2015-06-051-1/+1
| | | | | | | | | | | | | | | | | The intel 7260 driver under development requires this - the scans come in as normal frames but with the frequency provided. The correct method is to have the driver provide flags (so we can determine if it's 11b or 11g); this will have to do in the meantime. Without this, the channel found is 11b, and no ERP (ie "11g") bits are negotiated with the AP. This allows the 7260 in 2ghz mode to operate in 11bg, rather than just 11b. Tested: * intel 7260 driver, 11bg channels
* Some hostap setups may result in raw frames being transmitted withadrian2015-06-041-1/+2
| | | | | | | | | no parameters set. So, don't unconditionally call things. Thanks to jkim@ for pointing this out! MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
* Tag outbound raw 802.11 frames with both the node and an mbuf tagadrian2015-06-041-0/+19
| | | | | | | | | | | | | | | with the transmit params. This allows raw 802.11 frames to be queued in the driver if necessary, rather than requiring it to be direct-dispatched into the hardware. Tested: * ath(4), STA mode * iwn(4), STA mode MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
* Fix the build by hiding ieee80211_add_xmit_params andandrew2015-06-041-0/+2
| | | | ieee80211_get_xmit_params from userspace.
* First pass of adding transmit parameters as an option for outboundadrian2015-06-042-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 802.11 mbufs. The raw transmit path currently doesn't make it easy to queue these frames: * there's no node reference stored in the mbuf, like for the normal path, and * the bpf supplied raw transmit parameters (rate, rts/cts, etc) are passed in as an argument, not as an mbuf tag. In order to support driver queuing of these frames, we need to be able to put the above into the mbuf before the driver gets it, so the driver /can/ put it into a queue if needed. Use an mbuf tag and for now just verbatim copy the bpf parameters into it. Later on it may grow to include more options but this will do for now. Why would you want to queue raw frames? Well, in the case of iwn(4), we can't send the firmware frames to transmit before we hear a beacon - the firmware will consider passive channels as unavailable until it hears a beacon. The firmware "passive" channel state is cleared upon each RXON command, which is sent to update association status. So, when we attempt association and authorisation, the RXON command causes the firmware to clear out what it's already seen, and so we have to wait for a beacon before we can transmit. Before people get overly excited - this alone doesn't "fix" 5GHz operation - it just makes it (more) possible. The aim here is to convert all the drivers over to use a raw_xmit() API that doesn't include the node and params - instead they'd get those from the mbuf. Then raw_xmit() becomes just a side-channel version of the normal transmit path for management traffic. MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
* Move counter.h include into ieee80211_freebsd.h. Should fix build.glebius2015-05-278-10/+4
| | | | Submitted by: Zilvinas Valinskas <zilvinas.valinskas gmail.com>
* Fix spelling mistake in comment.gavin2015-05-261-1/+1
|
* Provide ieee80211_get_counter() that sums up ieee802comglebius2015-05-261-0/+31
| | | | | | | errors to the errors of this vap interface. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Add two counters to ieee80211com, that will be used to count transmissionglebius2015-05-268-1/+12
| | | | | | | or receive errors that can't be associated with any vap. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Make ieee80211broadcastaddr global, so that drivers or otherglebius2015-05-262-1/+5
| | | | code may use it and not paste.
* Reduce diff before functional changes:glebius2015-05-261-3/+2
| | | | | - Use ic_name instead of if_xname. - Formatting cleanup.
* Migrate the scan iterator lock typedefs out into ieee80211_freebsd.h.adrian2015-05-262-5/+12
| | | | | This removes the final piece of freebsd-specific locking that snuck into the tree - it's now all inside ieee80211_freebsd.h.
* Migrate the 802.11s locks out into ieee80211_freebsd.h, so they can beadrian2015-05-263-18/+31
| | | | | | defined as platform specific bits. This is to help make OS portability easier.
* Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE.glebius2015-05-258-78/+0
| | | | | | There are no plans to merge anything save a trivial bugfix to stable/9. Discussed with: adrian
* Change three methods in struct ieee80211com, namely ic_updateslot,glebius2015-05-253-12/+12
| | | | | | | | ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* When sending RTM_IEEE80211_CSA, RTM_IEEE80211_RADAR, RTM_IEEE80211_CAC andglebius2015-05-251-16/+32
| | | | | | | | | RTM_IEEE80211_RADIO routing messages, broadcast them on all vap interfaces instead of sending them on parent. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Convert malloc/free back to #define's, as part of OS portability work.adrian2015-05-2524-127/+163
| | | | | | | | | | | | | | | | | | | | | | | DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc() API is named differently, so they don't have userland/kernel symbol clashes like we do (think libuinet.) So, to make it easier for them and to port to other BSDs/other operating systems, start hiding the malloc specific bits behind defines in ieee80211_freebsd.h. DragonflyBSD can now put these portability defines in their local ieee80211_dragonflybsd.h. This should be a great big no-op for everyone running wifi. TODO: * kill M_WAITOK - some platforms just don't want you to use it * .. and/or handle it returning NULL rather than waiting forever. * MALLOC_DEFINE() ? * Migrate the well-known malloc names (eg M_TEMP) to net80211 namespace defines.
* Begin plumbing ieee80211_rx_stats through the receive path.adrian2015-05-2513-52/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260 series, etc) support doing a lot of things in firmware. This includes but isn't limited to things like scanning, sending probe requests and receiving probe responses. However, net80211 doesn't know about any of this - it still drives the whole scan/probe infrastructure itself. In order to move towards suppoting smart NICs, the receive path needs to know about the channel/details for each received packet. In at least the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet) it will do the scanning, power-save and off-channel buffering for you - all you need to do is handle receiving beacons and probe responses on channels that aren't what you're currently on. However the whole receive path is peppered with ic->ic_curchan and manual scan/powersave handling. The beacon parsing code also checks ic->ic_curchan to determine if the received beacon is on the correct channel or not.[1] So: * add freq/ieee values to ieee80211_rx_stats; * change ieee80211_parse_beacon() to accept the 'current' channel as an argument; * modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats; * add a new method - ieee80211_lookup_channel_rxstats() - that looks up a channel based on the contents of ieee80211_rx_stats; * if it exists, use it in the mgmt path to switch the current channel (which still defaults to ic->ic_curchan) over to something determined by rx_stats. This is enough to kick-start scan offload support in the Intel 7260 driver that Rui/I are working on. It also is a good start for scan offload support for a handful of existing NICs (wpi, iwn, some USB parts) and it'll very likely dramatically improve stability/performance there. It's not the whole thing - notably, we don't need to do powersave, we should not scan all channels, and we should leave probe request sending to the firmware and not do it ourselves. But, this allows for continued development on the above features whilst actually having a somewhat working NIC. TODO: * Finish tidying up how the net80211 input path works. Right now ieee80211_input / ieee80211_input_all act as the top-level that everything feeds into; it should change so the MIMO input routines are those and the legacy routines are phased out. * The band selection should be done by the driver, not by the net80211 layer. * ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels for now - this is enough for scanning, but not 100% true in all cases. If we ever need to handle off-channel scan support for things like static-40MHz or static-80MHz, or turbo-G, or half/quarter rates, then we should extend this. [1] This is a side effect of frequency-hopping and CCK modes - you can receive beacons when you think you're on a different channel. In particular, CCK (which is used by the low 11b rates, eg beacons!) is decodable from adjacent channels - just at a low SNR. FH is a side effect of having the hardware/firmware do the frequency hopping - it may pick up beacons transmitted from other FH networks that are in a different phase of hopping frequencies.
* Add void * member to struct ieee80211com, so that drivers can obtain theirglebius2015-05-251-0/+1
| | | | | | | softc without going through the struct ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Remove unused include.glebius2015-05-251-1/+0
|
OpenPOWER on IntegriCloud