This displays the IE names in ifconfig but it doesn't yet decode things.
Submitted by: Idwer Vollering <vidwer@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3782
For hz=1000 any number, greater than 4194 causes integer overflow;
this change casts the number to uint64_t before operating with it.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5268
This warning is irrelevant, since user can execute
'ifconfig wlan0 down' (or turn off card via rfkill switch) at any time.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5511
m is not guaranteed to be valid after m_cat() returns. The effects of this
are most noticeable when INVARIANTS is enabled, since m's header length
field is given a value of 0xdeadc0de by the trash dtor.
Reviewed by: glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D5497
Drivers should set their own filters via ic_scan_start()/ic_scan_end()
callbacks; and we don't need frames other than beacons or probe responses.
(Note: this was a noop since r287197 due to promiscuous mode with bridge
workaround)
Tested with Intel 3945BG, RTL8188EU and WUSB54GC in HOSTAP mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5474
- In case, when we are doing <smth> -> INIT (FEXT_REINIT) -> <smth2>
state transition, cancel_scan() may be called in the first transition.
Reenqueue second state transition, so things will be executed in order.
- Discard any AUTH+ state transition request when INIT -> SCAN
transition is not done.
- Allow to track discarded state transitions via 'state' debugging
category.
Tested with:
* RTL8188EU, HOSTAP mode.
* RTL8188CUS, STA mode.
* Intel 3945BG, IBSS and STA modes.
PR: 197498
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5482
- Pass scan state and additional internal flags as a parameters.
- Add locked version.
Tested with:
* Intel 3945BG, STA mode.
* RTL8188EU, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5148
transmitted
- Use M_TXCB mechanism to report about null data frame transmission.
- Increase timeout from 1 to 10 ms (the previous one may be not enough
for non-empty queue).
Tested with:
* Intel 3945BG, STA mode.
* RTL8188CUS, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5147
scan_curchan_task() functions)
(This part should fix the problem, described in
https://lists.freebsd.org/pipermail/freebsd-wireless/2016-January/006420.html)
- Rename ss_scan_task into ss_scan_start (better describes it's
current purpose)
- Utilize taskqueue_*_timeout() functions instead of current mechanism:
* reschedule scan_curchan_task() via taskqueue_enqueue_timeout()
for every 'maxdwell' msecs (will replace infinite loop + sleeping
for 'maxdwell' period via cv_wait());
* rerun the task immediately when an external event occurs
(instead of waking it up via cv_signal())
Also, use mtx_sleep() to wait for null frame transmission
(allows to drop conditional variable).
Tested with:
* Intel 3945BG, STA mode;
* RTL8188EU, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5145
All callers of ieee80211_promisc()/ieee80211_allmulti()
(ieee80211_vap_detach(), ieee80211_ioctl(), ap_start() and ap_end())
already hold the com_lock while calling them.
Tested with RTL8188EU, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5475
Remove duplicate 'ni->ni_associd = 0' assignment from
ieee80211_node_leave(), since it breaks iv_set_tim() in
ic->ic_node_cleanup() (associd is cleared right after this call).
Tested with RTL8188EU (HOSTAP mode) and
WUSB54GC (STA mode, with powersaving enabled).
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5398
- Add definitions for Timing Advertisement and Control Wrapper frames.
- Refresh ieee80211_mgt_subtype_name and ieee80211_ctl_subtype_name
arrays.
- Count Timing Advertisement frames as discarded management frames in all
modes.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5331
Use malloc(9) for
- struct ieee80211req_wpaie2 (518 bytes, used in
ieee80211_ioctl_getwpaie())
- struct ieee80211_scan_req (128 bytes, used in setmlme_assoc_adhoc()
and ieee80211_ioctl_scanreq())
Also, drop __noinline workarounds; stack overflow is not reproducible
with recent compilers.
Tested with Clang 3.7.1, GCC 4.2.1 (from 9.3-RELEASE) and 4.9.4
(with -fstack-usage flag)
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5041
Do not duplicate code between IEEE80211_IOC_WPAIE and IEEE80211_IOC_WPAIE2
switch cases.
Approved by: adrian (mentor)
Differential Revision: D5041 (part)
we're assuming hz=1000 and not gracefully handling when it isn't.
The math involved will return 0 for hz < 1000, which it is on some
platforms and on DragonflyBSD.
This doesn't fix it, it:
* converts one manual use over to use the macro, and
* comments where it needs some thought/fixing.
I'll think about this a bit more before fixing it.
Submitted by: imre@vdsz.com
- Add IEEE80211_GET_SLOTTIME(ic) macro.
- Use predefined macroses to set slot time.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4044
wpa_supplicant actually calls the wpa ioctl with cipher 0 as part
of the teardown process and this returns an ioctl error.
It's required as part of the (hopefully!) upcoming encrypted
IBSS support which does indeed do the above as part of interface
setup and then exits ungracefully when it gets an ioctl error.
(I'll fix wpa_supplicant in a later commit as part of other work.)
I've seen some cases where we get stuck in a loop constantly trying to
negotiate A-MPDU TX which is definitely not supposed to happen.
This will let me see if it's something funky with the retry count or
not.
This call may be used when device cannot continue to operate normally
(e.g., throws firmware error, watchdog timer expires)
and need to be restarted.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D3998
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
Move error handling into ieee80211_parent_xmitpkt() instead of spreading it
between functions.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3772
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
may be leaked.
This should be a big no-op.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3769
The MAC can be fetched from the key struct.
I added the ndis updates to make it compile.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3657
This can be used to update IV state for the caller without adding
information to the mbuf. Some hardware (eg rum) apparently requires
bits of this.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3638
field and into a separate fast-frames staging pointer in ieee80211_node.
The A-MPDU TX path allows txa_private to be used by drivers. So it will
clash with any attempt to use fast-frames. Now, fast-frames is not really
anything special - it's just a custom ethernet frame type that contains
two MSDUs into one MPDU. So all the NIC has to support doing is transmitting
up to a 4KiB frame with an arbitrary ethertype and bam! Fast-frames.
However, using txa_private means we can /either/ do fast-frames or A-MPDU TX,
so fast frames has been turned off in the Atheros HAL for 11n chipsets.
This is a bit silly - it actually means that 802.11 performance to/from
11abg Atheros chips is actually better than between an 11abg atheros device
and an 11n Atheros device.
So:
* create a new mbuf staging queue for fast frames. It only queues a single
frame in the staging queue (and there's a top-level ic staging queue
used for expiry/tracking) so it's just an mbuf pointer per TID.
* Still use the ampdu TX packet counter to determine whether to do
aggregation or not. It'll double count if we start doing both A-MPDU TX
and fast frames, but that's not all that important right now.
* Initialise the pps tracker so ticks isn't zero. This ensures that
fast-frames actually gets used - without it, the ticks math overflows
and the pps math always sets txa_pps=0. This is the same bug that
plagued A-MPDU TX starting logic.
This actually allows fast-frames transmit to occur between the AR9331
(in 11n HT/20 mode) and AR9170 (if_otus) in 11bg mode.
Now, this is a great big no-op on atheros 11n hardware, so don't worry.
It may mean you start seeing more reliable fast-frames transmission on
11abg hardware which may expose some more amusing bugs.
TODO:
* further testing and debugging of all of this before flipping on
fast-frames in if_ath (for 11n) and if_otus.
in the superg fast-frames code.
This harks back to an earlier commit (r280349) where I found that
initialising the pps code with ticks=0 would cause hilariously bad
hz ticks wraparound failures, leading to never actually aggregating
traffic. This is still true for the superg path and so I have to
do the same thing there.
This is a big no-op; a subsequent commit will flip this on so it
works with the fast-frames transmit path.
Tested:
* AR9170, otus(4) - STA mode, 11bg operation
* AR9331, AP mode
