summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_output.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix another compiler warning issue when invariants are disabled.adrian2013-03-091-2/+1
|
* Bring over my initial work from the net80211 TX locking branch.adrian2013-03-081-206/+300
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patchset implements a new TX lock, covering both the per-VAP (and thus per-node) TX locking and the serialisation through to the underlying physical device. This implements the hard requirement that frames to the underlying physical device are scheduled to the underlying device in the same order that they are processed at the VAP layer. This includes adding extra encapsulation state (such as sequence numbers and CCMP IV numbers.) Any order mismatch here will result in dropped packets at the receiver. There are multiple transmit contexts from the upper protocol layers as well as the "raw" interface via the management and BPF transmit paths. All of these need to be correctly serialised or bad behaviour will result under load. The specifics: * add a new TX IC lock - it will eventually just be used for serialisation to the underlying physical device but for now it's used for both the VAP encapsulation/serialisation and the physical device dispatch. This lock is specifically non-recursive. * Methodize the parent transmit, vap transmit and ic_raw_xmit function pointers; use lock assertions in the parent/vap transmit routines. * Add a lock assertion in ieee80211_encap() - the TX lock must be held here to guarantee sensible behaviour. * Refactor out the packet sending code from ieee80211_start() - now ieee80211_start() is just a loop over the ifnet queue and it dispatches each VAP packet send through ieee80211_start_pkt(). Yes, I will likely rename ieee80211_start_pkt() to something that better reflects its status as a VAP packet transmit path. More on that later. * Add locking around the management and BAR TX sending - to ensure that encapsulation and TX are done hand-in-hand. * Add locking in the mesh code - again, to ensure that encapsulation and mesh transmit are done hand-in-hand. * Add locking around the power save queue and ageq handling, when dispatching to the parent interface. * Add locking around the WDS handoff. * Add a note in the mesh dispatch code that the TX path needs to be re-thought-out - right now it's doing a direct parent device transmit rather than going via the vap layer. It may "work", but it's likely incorrect (as it bypasses any possible per-node power save and aggregation handling.) Why not a per-VAP or per-node lock? Because in order to ensure per-VAP ordering, we'd have to hold the VAP lock across parent->if_transmit(). There are a few problems with this: * There's some state being setup during each driver transmit - specifically, the encryption encap / CCMP IV setup. That should eventually be dragged back into the encapsulation phase but for now it lives in the driver TX path. This should be locked. * Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to allocate sequence numbers when doing transmit aggregation. This should also be locked. * Drivers may have multiple frames queued already - so when one calls if_transmit(), it may end up dispatching multiple frames for different VAPs/nodes, each needing a different lock when handling that particular end destination. So to be "correct" locking-wise, we'd end up needing to grab a VAP or node lock inside the driver TX path when setting up crypto / AMPDU sequence numbers, and we may already _have_ a TX lock held - mostly for the same destination vap/node, but sometimes it'll be for others. That could lead to LORs and thus deadlocks. So for now, I'm sticking with an IC TX lock. It has the advantage of papering over the above and it also has the added advantage that I can assert that it's being held when doing a parent device transmit. I'll look at splitting the locks out a bit more later on. General outstanding net80211 TX path issues / TODO: * Look into separating out the VAP serialisation and the IC handoff. It's going to be tricky as parent->if_transmit() doesn't give me the opportunity to split queuing from driver dispatch. See above. * Work with monthadar to fix up the mesh transmit path so it doesn't go via the parent interface when retransmitting frames. * Push the encryption handling back into the driver, if it's at all architectually sane to do so. I know it's possible - it's what mac80211 in Linux does. * Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather than doing a short-cut direct into the driver. There are QoS issues here - you do want your management frames to be encapsulated and pushed onto the stack sooner than the (large, bursty) amount of data frames that are queued. But there has to be a saner way to do this. * Fragments are still broken - drivers need to be upgraded to an if_transmit() implementation and then fragmentation handling needs to be properly fixed. Tested: * STA - AR5416, AR9280, Intel 5300 abgn wifi * Hostap - AR5416, AR9160, AR9280 * Mesh - some testing by monthadar@, more to come.
* Mesh bug: debug infomartion showing swapped SA and DA address.monthadar2013-02-071-2/+2
| | | | | | | * Fix bug for "forward frame from SA(%6D), DA(%6D)" where addresses where swapped between SA and DA; Approved by: adrian (mentor)
* Add mesh debug for interarction between DS & MBSS.monthadar2013-02-071-0/+4
| | | | | | | * Add mesh debug information when frames enter or leave the MBSS; * Set IEEE80211_MSG_OUTPUT bit to enable output; Approved by: adrian (mentor)
* Mechanically substitute flags from historic mbuf allocator withglebius2012-12-051-10/+10
| | | | | | | | | malloc(9) flags within sys. Exceptions: - sys/contrib not touched - sys/mbuf.h edited manually
* Mesh mode, potential garbage in QoS subfield.monthadar2012-06-251-3/+3
| | | | | | | | * qos[1] subfield is never assigned a value before this statement. qos[1] can potentially be OR:ed with garbage. Make it an assignment instead; * Remove brackets around if statement; Approved by: adrian
* Mesh forwarding with proxy support.monthadar2012-05-011-43/+72
| | | | | | | | | | | | | | | | | | | | | | * Modified HWMP PREP/PREQ to contain a proxy entry and also changed PREP frame processing according to amendment as following: o Fixed PREP to always update/create if acceptance criteria is meet; o PREQ processing to reply if request is for a proxy entry that is proxied by us; o Removed hwmp_discover call from PREQ, because sending a PREP will build the forward path, and by receving and accepting a PREQ we have already built the reverse path (non-proactive code); * Disabled code for pro-active in PREP for now (will make a separate patch for pro-active HWMP routing later) * Added proxy information for a Mesh route, mesh gate to use and proxy seqno; * Modified ieee80211_encap according to amendment; * Introduced Mesh control address extension enum and removed unused struct, also rename some structure element names. * Modified mesh_input and added mesh_recv_* that should verify and process mesh data frames according to 9.32 Mesh forwarding framework in amendment; * Modified mesh_decap accordingly to changes done in mesh control AE struct; Approved by: adrian
* Migrate the net80211 TX aggregation state to be from per-AC to per-TID.adrian2012-04-151-3/+3
| | | | | | | | TODO: * Test mwl(4) more thoroughly! Reviewed by: bschmidt (for iwn)
* * Introduce new flag for QoS control field;adrian2012-03-041-3/+21
| | | | | | | | | | | | * Change in mesh_input to validate that QoS is set and Mesh Control field is present, also both bytes of the QoS are read; * Moved defragmentation in mesh_input before we try to forward packet as inferred from amendment spec, because Mesh Control field only present in first fragment; * Changed in ieee80211_encap to set QoS subtype and Mesh Control field present, only first fragment have Mesh Control field present bit equal to 1; Submitted by: monthadar@gmail.com
* Hold IF_LOCK when manipulating the interface flags.adrian2012-02-241-1/+6
| | | | | | It doesn't _really_ help all that much, I'll commit something to sys/net/if.c at some point explaining why, but the lock should be held when checking/manipulating/branching because of said lock.
* Correct comment for the IPv6 case to say "traffic class" not "TOS"bz2012-01-071-1/+1
| | | | | | as pointed out back in 2009. MFC after: 3 days
* Add 802.11h quiet time element support into net80211.adrian2011-11-081-2/+56
| | | | | | | | | | | | This supports both station and hostap modes: * Station mode quiet time element support listens to quiet time IE's and modifies the local quiet time configuration as appropriate; * Hostap mode both obeys the locally configured quiet time period and includes it in beacon frames so stations also can obey as needed. Submitted by: Himali Patel <himali.patel@sibridgetech.com> Sponsored by: Sibridge Technologies
* This patch fixes beacon frame sequence number generation. The codeadrian2011-08-241-0/+8
| | | | | | | | | | | didn't set a sequence number; it didn't show up earlier because the hardware most people use for hostap (ie, AR5212 series stuff) sets the sequence numbers up in hardware. Later hardware (AR5416, etc) which can do 11n and aggregation require sequence numbers to be generated in software. Submitted by: paradyse@gmail.com Approved by: re (kib)
* Data frames sent over the mgmt path might be part of a TX aggr sessionbschmidt2011-06-041-3/+10
| | | | | | | | | | too. In that case don't fiddle with the seqno as drivers are supposed to handle that. Currently only the powersave feature does sent QoS-null-data frames before and after a background scan which must be handled correctly. Due to this being quite rare we don't fiddle around with starting of aggr sessions.
* We need in.h for both INET and INET6, as according to RFC 3493 itbz2011-04-251-1/+4
| | | | | | | | | defines struct in6_addr, which is needed by ip6_hdr used in here. Reviewed by: gnn Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems MFC after: 5 days
* When injecting frames a temporary node is faked, during this severalbschmidt2011-03-131-1/+2
| | | | | | | | | uses of ic_curchan occur. Due to the nature of a scan, switching channels constantly and all this happening without any kind of locks held, it might happen that ic_curchan points to nowhere leading to panics. Fix this by not allowing frame injections while in SCAN state. Tested by: Paul B. Mahol <onemda at gmail.com>
* It is IEEE80211_SUPPORT_XXX not IEEE80211_XXX_SUPPORT.bschmidt2011-02-211-6/+6
|
* The draft spec doesn't say beacon frames need to have a wildcard BSSID,rpaulo2009-10-231-7/+1
| | | | | | so remove the mesh code necessary for that. MFC after: 2 days
* Implement the missing support for updating the mesh conf number ofrpaulo2009-10-191-0/+12
| | | | | | neighbors via ieee80211_beacon_notify(). MFC after: 3 days
* revert OACTIVE part of r195845; instead fix the comment so it does not refersam2009-07-241-1/+13
| | | | | | to the old hack removed in r193312 Approved by: re (implicit)
* o kill old code no longer needed after r193312sam2009-07-241-14/+3
| | | | | | o count output packets+errors for frames sent through ieee80211_output Approved by: re (kensmith)
* More mesh bits, namely:rpaulo2009-07-201-17/+32
| | | | | | | | | | | | | | * bridge support (sam) * handling of errors (sam) * deletion of inactive routing entries * more debug msgs (sam) * fixed some inconsistencies with the spec. * decap is now specific to mesh (sam) * print mesh seq. no. on ifconfig list mesh * small perf. improvements Reviewed by: sam Approved by: re (kib)
* Implementation of the upcoming Wireless Mesh standard, 802.11s, on therpaulo2009-07-111-58/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
* do not strip M_MORE_DATA on packets coming through ieee80211_start;sam2009-06-081-3/+4
| | | | | | frames coming out of the ps q may have this set and removing it causes the 802.11 header to not indicate more frames follow which can result in the sta going to sleep and missing them
* teach ieee80211_classify about ipv6 packetssam2009-06-071-1/+23
| | | | Reviewed by: bz, rrs
* iv_flags_ext is full, make room by moving HT-related flags to a newsam2009-06-071-5/+5
| | | | iv_flags_ht word
* Fix spelling of MAC check for 8.x version of MAC Framework, not noticed duerwatson2009-06-051-1/+3
| | | | | | | to a lack of an opt_mac.h include, which I won't add for now as options MAC will soon move to opt_global.h. Spotted by: pjd
* o station mode channel switch supportsam2009-06-041-1/+1
| | | | | | | | | | o IEEE80211_IOC_CHANSWITCH fixups: - restrict to hostap vaps - return EOPNOTSUPP instead of EINVAL when applied to !hostap vap or to a vap w/o 11h enabled - interpret count of 0 to mean cancel the current CSA Reviewed by: rpaulo, avatar
* Overhaul monitor mode handling:sam2009-05-201-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
* Store the tx seq# of an 802.11 frame in the mbuf pkthdr; this will besam2009-04-271-0/+4
| | | | | | | | | | used for s/w retransmit schemes that want to access this information w/o the overhead of decoding the raw frame. Note this also allows drivers to record this information w/o writing the frame when the seq# is obtained through an out-of-band mechanism (e.g. when a h/w assigned seq# is reported in a descriptor on tx done notification). Reviewed by: sephe, avatar
* add IEEE80211_FEXT_4ADDR to indicate ieee80211_encap should do 4-addresssam2009-04-261-4/+3
| | | | | encapsulation when relaying frames; this reduces the cost of the test and enables use for situations other than "sta vap + dwds"
* hoist ampdu tx aggregation setup from ieee80211_encap to ieee80211_startsam2009-04-261-37/+36
| | | | | where it was meant all along (the code was in encap because ampdu was implemented pre vaps)
* stash the node pointer in the mbuf before doing ff aggregration so thissam2009-04-261-8/+7
| | | | is done in only one place
* don't fragment ampdu aggregatessam2009-04-261-1/+1
|
* uniformly mark mbufs that pass through the tx path with M_MCAST; driverssam2009-04-261-15/+22
| | | | can now use this flag instead of inspecting the contents
* add missing part of r191537 that should have read: hoist DLT_IEEE802_11sam2009-04-261-4/+0
| | | | bpf tap from ieee80211_encap up to ieee80211_start
* fix commentsam2009-04-261-3/+1
|
* add missing DLT_IEEE802_11 bpf tap in ieee80211_startsam2009-04-261-0/+4
|
* fixup ieee80211_output handling:sam2009-04-261-1/+11
| | | | | | o correct bpf handling, send 'em to the right tap o do accouting o mark mbufs holding multicast frames
* Change if_output to take a struct route as its fourth argument in orderkmacy2009-04-161-2/+2
| | | | | | to allow passing a cached struct llentry * down to L2 Reviewed by: rwatson
* o add a capability for drivers that require 802.3 encapsulation ofsam2009-04-081-8/+10
| | | | | | | frames passed down through the transmit path o mark ndis requiring 802.3 encap'd frames Reviewed by: "Paul B. Mahol" <onemda@gmail.com>, thompsa
* fix whitespacesam2009-04-031-1/+1
|
* o update dwds mcast handling after hoisting ieee80211_encap: frames needsam2009-04-031-3/+2
| | | | | | to be encapsulated before dispatching to the driver o eliminate M_WDS now that we call ieee80211_encap directly and can supply the wds vap to indicate a 4-address frame should be created
* Hoist 802.11 encapsulation up into net80211:sam2009-03-301-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
* Fix enough bits so that fast frames work again:sam2009-03-261-11/+35
| | | | | | o include ath ie in beacon frames o fix probe response check for including ath ie o add ieee80211_add_athcap shorthand for ap-side ie additions
* need to adjust htinfo offset when csa is insertedsam2009-03-261-0/+1
|
* adjust tdma ie offset when beacon frame contents changessam2009-03-261-0/+6
|
* split Atheros SuperG support out into it's own file that's included onlysam2009-03-241-211/+26
| | | | with a new IEEE80211_SUPPORT_SUPERG option
* Remove leftover comment because we now use a flag to check for associd.rpaulo2009-03-191-1/+0
| | | | Discussed with: sam
* mark M_LASTFRAG at the last fragment.weongyo2009-02-091-0/+3
| | | | | Reviewed by: sam MFC after: 3 weeks
OpenPOWER on IntegriCloud