Include ridx <-> rate conversion functions from rtwn(4) +
reuse already calculated value for ieee80211_radiotap(9).
Tested with Asus USB-N10, STA mode.
I don't yet know which RX descriptor bits map to shortgi, long-gi,
short-preamble, long-preamble, STBC, LDPC, HT40, etc - so I can't
easily add those just yet.
There's apparently no per-frame RX RSSI information exposed so we
also just use the results from the previous calibration task.
This also tidies up how the per-mbuf RSSI is pushed into the frame -
now that it's attached to the mbuf via rx_stats, we don't have to
do any silly hijinx to get it out of the frame processing path.
Tested:
* RTL8712, 1x1 cut 3, STA mode
- Do not ignore initialization errors; call ieee80211_stop()
when initialization failed.
- Use usb_pause_mtx() instead of DELAY() while waiting for firmware
loading; this fixes system freeze during firmware startup.
- Do not execute rsu_stop() when device is powered off; fixes
'unknown board type (rfconfig=0xff)' error when the device is
reattached.
Tested with Asus USB-N10.
- Replace all remaining DPRINTF(N)'s with RSU_DPRINTF.
- Add new RSU_DEBUG_USB flag to track error codes returned by
usbd_do_request_flags().
- Improve few messages.
- Add partial promiscuous mode support (no management frames;
they cannot be received by the firmware and net80211 at the same time).
- Add monitor mode support (all frames).
Tested with Asus, USB-N10.
This change includes firmware commands for key setup +
some additional checking via CAMREAD / CAMWRITE registers.
Nothing (except rsu_delete_key() for pairwise keys) is deferred;
to ensure that things are done in order rsu_set_key() will wait
until key deletion task will be finished.
Tested with Asus USB-N10 (all ciphers).
Differences from initial (reviewed) patch:
- Pause AC queues before disassociation - since CMD_DISCONNECT clears
crypto state all pending frames must be processed / dropped before it.
- Check sc_running flag before trying to set static keys.
- Clear key index from bitmap even when firmware command fails
(it will be invalidated via CAMWRITE anyway).
Reviewed by: adrian, kevlo
Tested by: kevlo
Differential Revision: https://reviews.freebsd.org/D8706
- Append RCR_APP_PHYSTS bit after firmware loading - otherwise
firmware will reset the register and this modification will be lost.
(without it Rx PHY descriptor section will contain garbage).
- Check if R92S_RXDW0_PHYST bit is set (like it is done in rtwn(4)) -
even if infosz is non-zero the section may not contain anything useful.
- In case, if descriptor is absent (A-MPDU?) use last calibrated RSSI
(rtwn(4) uses RSSI from the previous (sub)frame; probably, this
approach should be used here too).
Tested with Asus USB-N10, STA mode.
- Fill in Rx radiotap header correctly (for every packet in a chain;
not once per chain).
- Fix rate / flags fields in Rx radiotap.
- Add debug messages for discarded frames.
- Pass received control (< sizeof(struct ieee80211_frame)) frames
to net80211 (if allowed by device filter; cannot happen yet).
Tested with Asus USB-N10.
Differential Revision: https://reviews.freebsd.org/D5723
- Set IEEE80211_FEXT_SCAN_OFFLOAD flag; firmware can send null data
frames when associated.
- Check IEEE80211_SCAN_ACTIVE scan flag instead of IEEE80211_F_ASCAN
ic flag; the last is never set since r170530.
- Eliminate software scan (net80211) <-> site_survey (driver) race:
* override ic_scan_curchan and ic_scan_mindwell pointers so net80211
will not try to finish scanning automatically;
* inform net80211 about current status via ieee80211_cancel_scan()
and ieee80211_scan_done();
* remove corresponding workaround from rsu_join_bss().
Now the driver can associate to an AP with hidden SSID.
Tested with Asus USB-N10.
to ieee80211_add_rx_params() + drop last (ieee80211_rx_stats) parameter
Note: there is an additional check for ieee80211_get_rx_params()
return value (which does not exist in the original diff).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8207
There are a variety of more interesting RX statistics that we should
keep track of but we don't. This is a starting point for adding more
information.
Specifically:
* now the RX rate information and some of the packet status is
passed up;
* The 32 bit or 64 bit TSF is passed up;
* the PHY mode is passed up;
* the "I'm decap'ed AMSDU!" state is passed up;
* number of RX chains is bumped to 4.
This is all mostly a placeholder for getting the data into the RX status
before we pass it up to net80211 - unfortunately we don't yet enforce
that drivers provide it, nor do we pass the provided info back up the
stack so anyone can use the data.
We're going to need to use some of this data moving forward.
Notably, now that some hardware can do AMSDU decap for us (the intel iwm
driver can do it when we flip it on; the ath10k port I'm doing does
it for us) then we need to pass it up through the stack so the duplicate
RX sequence numbers and crypto/IV details don't cause the packet to
be dropped and/or counted against a replay counter.
It's also the beginning of being able to do more interesting node
accounting in net80211. Specifically, once drivers start populating
per-packet rate information, AMPDU information, timestamps, etc,
we can start providing histograms of rate-versus-RSSI, account
for receive time spent per node and other such interesting things.
(Note: I'm also hoping to include ranging and RTT information for
future chipset support; and it's likely going to include it in
this kind of fashion.)
Clear 'sc_calibrating' flag and stop calibration task when interface
is not associated; this fixes possible panic after detach.
Reported and tested by: hselasky
Reviewed by: adrian
MFC after: 6 days
tables. Some drivers needed some slight re-arrangement of declarations
to accommodate this. Change the USB pnp tables slightly to allow
better compatibility with the system by moving linux driver info from
start of each entry to the end. All other PNP tables in the system
have the per-device flags and such at the end of the elements rather
that at the beginning.
Differential Review: https://reviews.freebsd.org/D3458
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
The fullmac firmware doesn't seem to populate a useful rssi indicator
in the RX descriptor, so if one plotted said values, they'd basically
look like garbage.
The reference driver implements a "get current rssi" firmware command
which I guess is really meant for station operation only (as hostap
operation would need rssi per station, not a single firmware read.)
So:
* populate sc_currssi during each calibration run;
* use this in the RX path instead of trying to reconstruct the RSSI
value and passing it around as a pointer;
* do up a quick hack to map the rssi hardware value to some useful
signal level;
* the survey results provide an RSSI value between 0..100, so just
do another quick hack to map it into some usefulish signal level;
* supply a faked noise floor - I haven't yet found how to pull it
out of the firmware.
The scan results and the station RSSI information is now more useful
for indicating signal strength / distance.
This logic is mostly crimed from the reference driver and the linux
r92su driver.
I verified that it (a) worked on the rsu hardware I have, and (b)
did traffic testing whilst watching what ath(4) sent as a hostap.
It successfully sent MCS8..15 rates (which requires 2-stream reception)
as well as MCS0..7 (which is 1-stream.)
Tested:
* RTL8712, 1T1R NIC, MCS rates 0..7.
* RTL8712, 1T2R NIC, MCS rates 0..15
TODO:
* Find a 2T2R NIC!
in the join message so the firmware would pick it up.
* Strip out the direct hardware fiddling for 40MHz mode - the firmware
we're using doesn't require it (the rtl8712su firmware does; it
is less 'fullmac' than what we're using.)
* Fix the mbuf handling during errors - rsu_tx shouldn't free mbufs;
it's up to the caller to do so. This brings it in line with
what other drivers do or should be doing.
Tested:
* RTL8712, HT40 channel, STA mode (during this commit)
* Add a new method to control NIC poweron / network-sleep / power off;
* Add in A-MPDU TX negotiation support, but comment it out because it
does break TX traffic;
* blank out the tx buffer before sending a firmware message, just in case;
* go into network-sleep once associated;
TODO:
* figure out why ampdu negotiation isn't working and breaking TX traffic,
then enable it.
to do it directly.
Ensure that we re-queue starting transmit upon TX completion.
This solves two issues:
* It stops tx stalls - before this, if the transmit path filled the
mbuf queue then it'd never start another transmit.
* It enforces ordering - this is very required for 802.11n which
requires frames to be transmitted in the order they're queued.
Since everything remotely involved in USB has an unlock/thing/relock
pattern with that mutex, the only way to guarantee TX ordering is
to 100% defer it into a separate thread.
This now survives an iperf test and gets a reliable 30mbit/sec.
Correctly (I hope!) remove net80211 references before doing so.
Just doing a dumb mbufq drain isn't enough.
If enough traffic occurs and the mbuf queue fills up then transmit
stalls (which I'm not fixing in this commit!) but then the mbuf queue
stays full until the driver is removed. There's also the net80211
node refcounting leak.
This just ensures that during rsu_stop and detach the mbuf queue
is purged (and references!) so the queue-full situation can be
recovered from.
setup pieces and so (at least) transmit doesn't work.
It'll just fall back to being a straight HT20 device and negotiate
HT20 only.
Tested by: Idwer Vollering <vidwer@gmail.com>
requirements.
Don't start the opmode and join path until a pending survey is finished.
This seems to reliably fix things.
Ideally I'd just finish off the net80211 pluggable scan stuff and implement
the methods here so if_rsu can just drive the scan machinery.
However, that's a .. later thing.
Whilst here, remove the getbuf debugging; it's okay to run out of transmit
buffers under load; it however isn't okay to not be able to send commands.
I'll fix that later.
* Add a tunable to enable 11n if it's available, so to not anger people
who upgrade.
kenv hw.usb.rsu.enable_11n=1 before inserting the device.
* Add initial 11n htconfig bits;
* Enable 40MHz mode if it's available;
* Add 11n channels;
* Set 11n bits in the firmware.
It works for RX; I haven't tested TX aggregation just yet.
However the firmware doesn't do RX re-ordering, so I have to tie it into
the net80211 A-MPDU RX reorder path before I flip this on by default.
I've verified that I'm indeed actually seeing MCS 0->7 rates being received.
I haven't dug into whether it's actually transmitting 11n rates; I'll dig into
that later.
* the tx descriptor TID is priority, not TID.
* the tx descriptor queue id mapping is separate from the
TID/priority; rather than just "BE".
TODO:
* go and re-re-re-verify the queue mappings; the linux and openbsd
mappings aren't exactly the same. I need to verify all of this
before I try to flip on 11n RX.
* Do 1T1R for now, until we read the config out of ROM and use it.
* Disable turbo mode, I dunno what this is, but the linux drivers
have this disabled.
* Set the firmware endpoints to what we read from USB.
Tested:
* RTL8712 cut 3, STA mode
data queues.
This is similar to the openbsd and rtlwifi/r92su drivers.
Note: this driver still assumes it's a 4-endpoint device; I'll enforce
that in a follow-up commit.
