| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Extend the radiotap code to be aware of the size of any extra vendor | adrian | 2012-06-18 | 1 | -6/+20 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmaps that may occur. The way this works is: * the beginning of the radiotap frame has a 32 bit "radiotap" namespace bitmap; * if the vendor bitmap bit is set, then the next bitmap will be interpreted as a vendor bitmap; * this can keep going on and on (ie, more vendor and radiotap namespace bitmaps can be added) until the last bitmap with no "more bitmaps" set. Now, the radiotap code gets its grubby fingers into the supplied radiotap rx/tx buffer and replaces the channel configuration for each frame. I don't know why it's not up to the drivers themselves to do this, but I digress. So, if a vendor bitmap (or two, etc) exists, the offset calculations will be all completely wrong. This particular patch introduces ieee80211_radiotap_attachv(), which includes the number of vendor bitmaps (well, any other bitmaps, vendor or otherwise) between the end of the bitmap/header and the start of the actual radiotap field entries. This makes the radiotap calculations "right", so it correctly calculates where to overwrite the channel configuration. The long term fix is to go through and make each driver update the channel configuration, as some of the fields are already being updated. That, however, is a longer term fix that will need each driver fixed. I leave that as an exercise to someone in the future. | ||||
| * | Add missing \n's. | adrian | 2012-03-08 | 1 | -2/+2 |
| | | | | | | This showed up when testing the wtap module, as it attaches with no radiotap tx/rx configuration. | ||||
| * | Add the MCS radiotype entry. | adrian | 2012-01-11 | 1 | -0/+4 |
| | | |||||
| * | purge dead code | sam | 2009-06-08 | 1 | -29/+0 |
| | | |||||
| * | fix big-endian machines | sam | 2009-06-08 | 1 | -4/+4 |
| | | |||||
| * | Fix monitor mode vaps to work as intended: | sam | 2009-06-02 | 1 | -9/+66 |
| | | | | | | | | o track # bpf taps on monitor mode vaps instead of # monitor mode vaps o spam monitor mode taps on tx/rx o fix ieee80211_radiotap_rx_all to dispatch frames only if the vap is up o while here print radiotap (and superg) state in show com | ||||
| * | Fix handling of devices w/o radiotap support: | sam | 2009-05-25 | 1 | -6/+8 |
| | | | | | | | | 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: | sam | 2009-05-20 | 1 | -0/+325 |
| 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 | |||||
 |
index : FreeBSD-src | |
| Raptor Engineering's fork of pfsense FreeBSD src with pfSense changes | Raptor Engineering, LLC |
| summaryrefslogtreecommitdiffstats |
|