summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_adhoc.c
Commit message (Collapse)AuthorAgeFilesLines
* When taking the AMPDU reorder fastpath, need_tap wasn't beingrpaulo2010-02-031-2/+1
| | | | | | initialized. Initialize on declaration to avoid this. Found with: clang static analyzer
* Revamp 802.11 action frame handling:sam2009-07-051-1/+1
| | | | | | | | | | | | | | o add a new facility for components to register send+recv handlers o ieee80211_send_action and ieee80211_recv_action now use the registered handlers to dispatch operations o rev ieee80211_send_action api to enable passing arbitrary data o rev ieee80211_recv_action api to pass the 802.11 frame header as it may be difficult to locate o update existing IEEE80211_ACTION_CAT_BA and IEEE80211_ACTION_CAT_HT handling o update mwl for api rev Reviewed by: rpaulo Approved by: re (kensmith)
* Fix handling of devices w/o radiotap support:sam2009-05-251-1/+1
| | | | | | | o do not attach DLT_IEEE802_11_RADIO unless both tx and rx headers are present; this is assumed in the capture code paths o verify the above with asserts in ieee80211_radiotap_{rx,tx} o add missing checks for active taps before calling ieee80211_radiotap_rx
* Overhaul monitor mode handling:sam2009-05-201-20/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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
* whitespacesam2009-05-021-0/+1
|
* print both fc bytes when hitting a protocol version mismatchsam2009-04-261-1/+2
|
* add iv_recv_ctl method to allow hooking rx ctl frame handlingsam2009-04-261-0/+8
|
* o use shared code to handle bpf tap and mbuf cleanupsam2009-04-261-5/+2
| | | | o swap conditional order to put the cheapest first
* split Atheros SuperG support out into it's own file that's included onlysam2009-03-241-24/+8
| | | | with a new IEEE80211_SUPPORT_SUPERG option
* clean neighbor entries on beacon misssam2009-02-101-1/+13
|
* TDMA support for long distance point-to-point links using ath devices:sam2009-01-081-1/+26
| | | | | | | | | | | | | | | o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
* Fix checks for fast frames negotiation. ni_ath_flags holds thesam2008-10-301-1/+1
| | | | | | | | | | | | | | capabilities reported by the ap. These need to be cross-checked against the local configuration in the vap. Previously we were only checking the ap capabilities which meant that if an ap reported it was ff-capable but we were not setup to use them we'd try to do ff aggregation and drop the frame. There are a number of problems to be fixed here but applying this fix immediately as the problem causes all traffic to stop (and has not workaround). Reported by: Ashish Shukla
* o use the new association callback to notify the driver when joining a bsssam2008-10-271-2/+6
| | | | | | | in sta and adhoc modes; this should've been done forever ago as most all drivers use this hook to set per-station transmit parameters such as for tx rate control o adjust drivers to remove explicit calls to the driver newassoc method
* use a private mgt frame recv handler for ahdemo mode instead of an inlinesam2008-10-251-4/+24
| | | | | test in the adhoc mode rx path so classes derived from ahdemo mode can override the default behaviour
* add/improve debug msgssam2008-10-251-2/+12
|
* Cleanup AMPDU handling:sam2008-09-211-13/+9
| | | | | | | | | | | | | | | | | | | | | | For receive: o explicitly tag rx frames w/ M_AMPDU instead of passing frames through the reorder processing according to the node having HT and the frame being QoS data o relax ieee80211_ampdu_reorder asserts to allow any frame to be passed in, unsuitable frames are returned to the caller for normal processing; this permits drivers that cannot inspect the PLCP to mark all data frames as potential ampdu candidates with only a small penalty o add M_AMPDU_MPDU to identify frames resubmitted from the reorder q For transmit: o tag aggregation candidates with M_AMPDU_MPDU o fix the QoS ack policy set in ampdu subframes; we only support immediate BA streams which should be marked for "normal ack" to get implicit block ack behaviour; interestingly certain vendor parts BA'd frames with the 11e BA ack policy set o do not assign a sequence # to aggregation candidates; this must be done when frames are submitted for transmit (NB: this can/will be handled better when aggregation is pulled up to net80211)
* no need to stop the sw beacon miss timer; it's not used with adhoc or wdssam2008-05-221-2/+0
|
* Multi-bss (aka vap) support for 802.11 devices.sam2008-04-201-0/+877
Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
OpenPOWER on IntegriCloud