summaryrefslogtreecommitdiffstats
path: root/sys/net80211
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Fix net80211 fragment creation.adrian2013-05-251-4/+15
| | | | | | | | | | | | | | | When creating fragment frames, the header length should honour the DATAPAD flag. This fixes the fragments that are queued to the ath(4) driver but it doesn't yet fix fragment transmission. That requires further changes to the ath(4) transmit path. Well, strictly speaking, it requires further changes to _all_ wifi driver transmit paths, but this is at least a start. Tested: * AR5416, STA mode, w/ fragthreshold set to 256.
* Fix a VAP BSS node reference in the HT code to actually take a referenceadrian2013-05-101-1/+7
| | | | | | | | | | | | | | before using said node. The "blessed" way here is to take a node reference before referencing anything inside the node, otherwise the node can be freed between the time the pointer is copied/dereferenced and the time the node contents are used. This mirrors fixes that I've done elsewhere in the net80211/driver stack. PR: kern/178470
* Add const qualifier to the dst parameter of the ifnet if_output method.glebius2013-04-264-4/+4
|
* Implement a utility function to return the current TX power cap foradrian2013-04-161-0/+22
| | | | | | | | | | | | the given node. This takes into account the per-node cap, the ic cap and the per-channel regulatory caps. This is designed to replace references to ni_txpower in various net80211 drivers - ni_txpower doesn't necessarily reflect the actual cap for the given node (eg if the node has the default value of 50dBm (100) and the administrator has manually configured a lower TX power.)
* Add VNET wrappers around the rest of the ieee80211 rtsock messages.adrian2013-03-201-0/+10
| | | | I triggered the cac/radar messages when doing testing in DFS channels.
* Kill this, it's not needed at this point and (hopefully) the parentadrian2013-03-101-2/+0
| | | | has correctly locked the ic/vap.
* Fix another compiler warning issue when invariants are disabled.adrian2013-03-091-2/+1
|
* Fix non-invariant compilation.adrian2013-03-091-6/+3
|
* Bring over my initial work from the net80211 TX locking branch.adrian2013-03-0813-250/+458
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Disable this variable; the code using it is also disabled.adrian2013-02-181-0/+2
|
* Disable this code and add a note as to why.adrian2013-02-181-0/+15
| | | | | It wasn't currently being called anyway - but being explicit about it can't hurt.
* Fix an incorrect sizeof()adrian2013-02-161-1/+1
| | | | | | Spotted by: clang Submitted by: dim
* Mesh: QoS Control field bit flags fix.monthadar2013-02-141-3/+3
| | | | | | | | | | * The following bit flags where incroccetly defined: o Mesh Control Present o Mesh Power Save Level o RSPI This is now corrected according to Table 8.4 as per IEEE 802.11 2012; Approved by: adrian (mentor)
* Substitute '#ifdef ALIGNED_POINTER' with '#ifndef __NO_STRICT_ALIGNMENT',glebius2013-02-123-4/+6
| | | | | | | | since the former is defined everywhere. This cuts off some code not necessary on non strict aligment arches. Reviewed by: adrian Sponsored by: Nginx, Inc.
* Fix ieee80211_mesh.c compilation.adrian2013-02-081-0/+4
| | | | | | * Add the superg.h header to allow ieee80211_check_ff() to work * Since the assert stuff creates assertions based on line numbers and there was a conflict, just nudge things down a bit.
* Mesh: recevied GANN frames where not parsed correctly.monthadar2013-02-071-26/+66
| | | | | | | * Added mesh_parse_meshgate_action that parse all values to host endian; * Add more detailed debug output; Approved by: adrian (mentor)
* Mesh HWMP forwarding information: updating FI for transmitter.monthadar2013-02-071-5/+44
| | | | | | | | | * Added hwmp_update_transmitter function that checks if the metric to the transmitter have improved. If old FI is invalid or metric is larger the FI to the transmitter is updated occurdingly. This is a recommendation from the 802.11 2012 standard, table 13-9; Approved by: adrian (mentor)
* Mesh HWMP PERR bug fixes.monthadar2013-02-071-1/+1
| | | | | | | | | * When calling ieee80211_mesh_rt_flush_peer, the rt->rt_dest argument should not be passed because it can get freed before invalidating the other routes that depends on it to compare with next_hop. Use PERR_DADDR(i) instead; Approved by: adrian (mentor)
* 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)
* Update ddb to print mesh routing table.monthadar2013-02-071-11/+27
| | | | | | | * Modified _db_show_vap and _db_show_com to print mesh routing table if the 'm' modifier is specified; Approved by: adrian (mentor)
* Mesh HWMP PREQ: fixed conditions for discarding elements.monthadar2013-02-071-4/+4
| | | | Approved by: adrian (mentor)
* Mesh HWMP: don't send an intermediate PREP for proxy entries.monthadar2013-02-071-1/+3
| | | | | | | | | * The standard is unclear about what should happen in case a mesh STA (not marked as a mesh gate) recevies a PREQ for a destination that is marked as proxy. Solution for now is not to do intermediate reply at all, and let the PREQ reach the mesh gate; Approved by: adrian (mentor)
* Mesh HWMP PREQ update: proxy reply only if mesh STA is a meshgate.monthadar2013-02-071-3/+6
| | | | | | | | | * Original PREP frame is transmitted only by the target mesh STA or the mesh STA that is the proxy target; * Fixed so that metric value is not over written incorrectly in hwmp_recv_preq for when replying back with a PREP; Approved by: adrian (mentor)
* HWMP: ic->raw_xmit didn't always point to correct ni.monthadar2013-02-073-75/+58
| | | | | | | | | | | | | | | | | | | This is a code re-write. ic->raw_xmit need a pointer to ieee80211_node for the destination node (da). I have reorganized the code so that a pointer to the da node is searched for in the end & in one place. * Make mesh_find_txnode public to be used by HWMP, renamed to ieee80211_mesh_finx_txnode; * changed the argument from ieee80211_node to ieee80211vap for all hwmp_send_* functions; * removed the 'sa' argument from hwmp_send_* functions as all HWMP frames have the source address equal to vap->iv_myaddr; * Modified hwmp_send_action so that if da is MULTCAST ni=vap->iv_bss otherwise we called ieee80211_mesh_find_txnode. Also no need to hold a reference in this functions if da is not MULTICAST as by finding the node it became referenced in ieee80211_find_txnode; Approved by: adrian (mentor)
* Mesh gate code to transmit to all mesh gates.monthadar2013-02-071-25/+167
| | | | | | | | | | | | | * Modified mesh_find_txnode to be able to handle proxy marked entries by recursively calling itself to find the txnode towards the active mesh gate; * Mesh Gate: Added a new function that transmits data frames similar to ieee80211_start; * Modified ieee80211_mesh_forward_to_gates so that: + Frames are duplicated and sent to each valid Mesh Gate; + Route is marked invalid before return of function, this is because we dont know yet which Mesh Gate is we will use; Approved by: adrian (mentor)
* Send frames to mesh gate if 11s discovery fails.monthadar2013-02-073-6/+78
| | | | | | | | | | | | * Send frames that have no path to a known valid Mesh Gate; * Added the function ieee80211_mesh_forward_to_gates that sends the frame to the first found Mesh Gate in the forwarding information; * If we try to discover again while we are discovering queue frame, the discovery callout will send the frames either to mesh gates or discards them silently; * Queue frame also if we try to discover to frequently; Approved by: adrian (mentor)
* Mark root mesh as gate when mesh gate flag set.monthadar2013-02-073-0/+59
| | | | | | | | * Add function ieee80211_mesh_mark_gate in ieee80211_mesh.h; * When received a proactive PREQ or RANN with corresponding mesh gate flag set, create a new entry in the known mesh gate list; Approved by: adrian (mentor)
* Propagate GANN frames, and store know gate info.monthadar2013-02-072-5/+79
| | | | | | | | | | | | | * Modified mesh_recv_action_meshgate to do following: + if mesh STA already knows the mesh gate of the recevied GANN frame + if mesh gate is know, check seq number according to 802.11 standard + if mesh gate is not know, add it to the list of known mesh gates + if forwarding is enabled and ttl >= 1 then propagate the GANN frame; * Declare a new malloc type M_80211_MESH_GT_RT; * Declare a struct to store GANN information, ieee80211_mesh_gate_route. And add it as a TAILQ list to ieee80211_mesh_state; Approved by: adrian (mentor)
* Mesh update: add base Mesh Gate functionality.monthadar2013-02-073-10/+196
| | | | | | | | | | | | | | | | | | | | | | | | | A Mesh Gate should transmit a Mesh Action frame containing ieee80211_meshgann_ie as its only information element periodically every ieee80211_mesh_gateint ms. Unless the mesh gate is also configure as a ROOT, then these frames should not be send. This is according to 802.11 2012 standard; * Introduce new SYSCTL net.wlan.mesh.gateint, with 10s default; * Add two new functions mesh_gatemode_setup and mesh_gatemode_cb. This is similar to how HWMP setups up a callout; * Add two new action handlers mesh_recv_action_meshgate and mesh_send_action_meshgate; * Added ieee80211_add_meshgate to ieee80211_mesh.h; * Modified mesh_send_action to look similar to hwmp_send_action. This is because we need to send out broadcast management frames. * Introduced a new flag for mesh state IEEE80211_MESHFLAGS_ROOT. This flag is now set by HWMP code when a mesh STA is configured as a ROOT. This is then checked by mesh_gatemode_cb before scheduling a new callout; * Added to new field to ieee80211_mesh_state: + struct callout ms_gatetimer + ieee80211_mesh_seq ms_gateseq; Approved by: adrian (mentor)
* Start accepting IEEE80211_ACTION_MESH_GANN frames;monthadar2013-02-071-0/+4
| | | | | | | * Add IEEE80211_ACTION_MESH_GANN Action frame verification in ieee80211_parse_action; Approved by: adrian (mentor)
* Mesh: management mesh action frames are to be discardedmonthadar2013-02-072-14/+11
| | | | | | | | | | | | when not peered. * Modified ieee80211_recv_action to check if neighbour is peered for IEEE80211_ACTION_CAT_MESH frames, if not frame is discarded. This is according to IEEE802.11 2012 standard; * Removed duplicate checks in each hwmp_recv_* handlers because HWMP is a subtype of mesh action; Approved by: adrian (mentor)
* Update in ieee80211_action.c for mesh code handlers.monthadar2013-02-071-51/+14
| | | | | | | | | | | * Removed meshlm_send_action and hwmp_send_action. Introduced one common for all Mesh Action frames meshaction_send_action. According to 802.11 standard Link Metric and HWMP are all under Mesh Action category; * Did similar changes to recv_action part; * The size of meshaction_*_action is set to 12. This is to make room for the rest of Mesh Action category subtypes; Approved by: adrian (mentor)
* Update net80211 mesh struct ieee80211_meshgann_ie.monthadar2013-02-072-7/+15
| | | | | | | | | | | | | * Change all field prefix from pann_ to gann_; * Added IEEE80211_MESHGANN_BASE_SZ macro to be used in the length field of a GANN frame according to 802.11 standard; * Changed gann_seq field type to uint32_t; * Added a Gate Announcement interval field according to IEEE802.11 2012 standard; * Added IEEE80211_MESHRT_FLAGS_GATE as flag bit to ieee80211_mesh_route; * Added IEEE80211_MESHRT_FLAGS_GATE as flag bit to ieee80211req_mesh_route; Approved by: adrian (mentor)
* HWMP: Accept a PERR even if path is valid.monthadar2013-02-071-1/+1
| | | | | | | * An HWMP PERR should be accepted even if path is valid. Because we check if we recevied it from a neighbour that we use as a next hop; Approved by: adrian (mentor)
* Add mesh debug for interarction between DS & MBSS.monthadar2013-02-072-0/+7
| | | | | | | * Add mesh debug information when frames enter or leave the MBSS; * Set IEEE80211_MSG_OUTPUT bit to enable output; Approved by: adrian (mentor)
* Fix mesh path flag.monthadar2013-02-071-2/+5
| | | | | | | | | * A bug occurs while in discovery mode which leaves a path marked with both Discover and Valid flag. This happens when receiving/sending PREQ and PREP in a particular order. Solution is to assign the Valid bit instead of oring it; Approved by: adrian (mentor)
* Stop a mesh STA from flooding with peer frames.monthadar2013-02-072-1/+33
| | | | | | | | | | | | | | | | | | | | | This problem happens when using ACL policy to filter mesh STA but two nodes have different policy. Then one of them will try to peer all the time. This can also help if for any reason one of the peering mesh STA have problems sending/receiving peer frames. * Modified struct ieee80211_node to include two new fields: + struct callout ni_mlhtimer /* link mesh backoff timer */ + uint8_t ni_mlhcnt /* link mesh holding counter */ * Added two new sysctl (check sysctl -d for more info): + net.wlan.mesh.backofftimeout=5000 + net.wlan.mesh.maxholding=2; * When receiving a beacon and we are in IEEE80211_NODE_MESH_IDLE check if ni_mlhcnt >= ieee80211_mesh_maxholding, if so do not do anything; * In mesh_peer_timeout_cb when transitioning from IEEE80211_NODE_MESH_HOLDING to IEEE80211_NODE_MESH_IDLE increment ni_mlhcnt, and eventually start ieee80211_mesh_backofftimeout; Approved by: adrian (mentor)
* Wrap this in an #ifdef so IEEE80211_SUPPORT_SUPERG will work correctlyadrian2013-02-021-0/+4
| | | | in a wlan.ko module.
* Initial cut at making IBSS support 802.11n aware.adrian2013-01-263-7/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not 100% correct as it's not looking at the draft 11n HTINFO location, but I don't think anyone will care. * When doing an IBSS join make sure the 11n channel configuration is used - otherwise the 11a/11bg channel will be used and there won't be any chance for an upgrade to 11n. * When creating an IBSS network, ensure the channel is updated to an 11n channel so other 11n nodes can see it and speak to it with MCS rates. * Add a bit of code that's disabled for now which handles the HT field updating. This won't work out very well with lots of adhoc nodes as we'd end up ping-ponging between the HT configuration for each node. Instead, we should likely only pay attention to the "master" node we initially associated against and then ensure we propagate that information forward in our subsequent beacons. However, due to the nature of IBSS (ie, there's no specific "master" node in the specification) it's unclear which node we should lift the HT parameters from. So for now this assumes the HT parameters are squirreled away in the initial beacon/probe response. So there's some trickiness here. With ap/sta pairing, the probe response just populates a legacy node and the association request/response is what is used for negotiation 11n-ness (and upgrading things as needed.) With ibss networks, the pairing is done with probe request/response, with discovery being done by creating nodes when new beacons in the IBSS / BSSID are heard. There's no assoc request/response frames going on. So the trick here has been to figure out where to upgrade things. I don't like how I just taught ieee80211_sta_join() to "speak" HT - I'd rather there be an upgrade path when an IBSS node joins and there are HT parameters present. Once I've done that, I'll kill this HT special casing that's going on in ieee80211_sta_join(). Tested: * AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests whilst in a non-encrypted adhoc network. TODO: * Fix up the HT upgrade path for IBSS nodes rather than adding code in ieee80211_sta_join(), then remove my code from there. * When associating, there's a concept of a "master" node in the IBSS which is the node you first joined the network through. It's possible the correct thing to do is to listen to HT updates and configure WME parameters from that node. However, once that node goes away, which node(s) should be listened to for configuration changes? For things like HT channel width, it's likely going to be ok to just associate as HT40 and then use the per-neighbor rate control and HTINFO/HTCAP fields to figure out which rates and configuration to speak. Ie, for a 20MHz 11n node, just speak 20MHz rates to it. It shouldn't "change", like what goes on in AP/STA configurations.
* Remove the use of the ifnet send queue and if_start() in the poweradrian2013-01-151-8/+32
| | | | | | | | | | | | | | | | | | | save queue code. Instead, use if_transmit() directly - and handle the cases where frame transmission fails. I don't necessarily like this and I think at this point the M_ENCAP check, node freeing upon fail and the actual if_transmit() call should be done in methods in ieee80211_freebsd.c, but I digress slightly.. This removes one of the last few uses of if_start() and the ifnet if_snd queue. The last major offender is ieee80211_output.c, where ieee80211_start() implements if_start() and uses the ifnet queue directly. (There's a couple of gotchas here, where the if_start pointer is compared to ieee80211_start(), but that's a later problem.)
* Add in the missing radiotap definitions from the sipsolutions.netadrian2013-01-081-1/+12
| | | | radiotap "upstream" source.
* Handle ps-poll data frame if_transmit() failure.adrian2013-01-061-1/+15
| | | | | | | | | | | | If the data frame transmission failures, it may have a node reference that needs cleaning up. If the frame is marked as M_ENCAP then it should treat recvif as a node reference and clear it. Now - since the mbuf has been freed by calling if_transmit() (even on failure), the mbuf has to be treated as invalid. Hence why the ifp is used.
* Handle HWMP if_transmit() failure gracefully.adrian2013-01-061-1/+13
| | | | | | | | | If if_transmit() fails, the node ref may need freeing. This is based on the same logic used by the ageq, which the mesh code (re) uses for frames which need to be staged before transmitting. It also does the same thing - if M_ENCAP is set on the mbuf, it treats the recvif pointer as a node reference and derefs it.
* if_start() is being used here as a way of kick-starting the new queueadrian2012-12-221-0/+5
| | | | | | processing. For if_transmit() style hardware drivers (which none publicly exist yet, for wireless) they will need to still implement if_start() but only to re-start the TX queue.
* Remove a use of if_start() - instead, use if_transmit() to dispatch theadrian2012-12-221-2/+1
| | | | frame.
* Adjust the channel to correctly setup the HT flags when transitioningadrian2012-12-101-1/+3
| | | | | | | | | | | | | an IBSS VAP to RUN. An 11n IBSS was beaconing HTINFO/HTCAP IE's that didn't have any HT information setup (like the HT TX/RX MCS bitmask.) Tested: * AR9280, IBSS - both a statically setup channel and a scanned channel PR: kern/172955
* Update the aggressive mode logic to also enable aggressive modeadrian2012-12-101-8/+50
| | | | | | | | | | | | parameters in IBSSes. IBSS was just being plainly ignored here even though aggressive mode was 'on'. This still doesn't fix the "why are the WME parameters reset upon interface down/up" issue. PR: kern/165969
* Undo the previous adhoc commit - doing the WME IE handling hereadrian2012-12-091-10/+0
| | | | | | | | | | | | | | | | | is totally wrong. If we parse the WME IE here, we'll be constantly updating the WME configuration from each WME enabled IBSS node we see. There's a separate issue where the WME configuration is blanked out when the interface is brought up; the WME parameters aren't "sticky." Also, ieee80211_init_neighbor() parses the ath IE, so doing it here isn't required. Sorry about the noise. PR: kern/165969
* Handle ath-specific and WME IE's in adhoc mode.adrian2012-12-093-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer. It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters. Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky. So ensure that you configure your adhoc nodes with the same WME parameters. Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly. TODO: * I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode. Tested: * AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.) PR: kern/165969
OpenPOWER on IntegriCloud