| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ok mpi@
|
|
IFM_AUTO is a media sub-type, not a media mode.
Should fix issues where only a subset of channels were scanned.
Tested:
iwm 8260: millert@
iwm 8265: mglocker@
iwm 9560: gnezdo@
iwx ax200: jmc@
iwx ax210: spiros thanasoulas
iwx ax211: kn@
|
|
suggests that this fix did not in fact help with the issue. And this
change broke wireless for other iwn(4) users, as reported by Lucas on bugs@
|
|
Enabling 40MHz too early can cause firmware sysassert 0x05 on 5300 devices
when we send the initial AUTH frame to kick off association. At this point
we haven't negotiated 11n mode yet (this happens later during the association
sequence), so perhaps firmware saw an inconsistent configuration state?
It is unclear why this problem did not seem to affect any other devices.
Reported by Christian Schulte on misc@
|
|
Sven Wolf noticed that scans on ral(4) are buggy ever since I added a new
field to this struct. Turns out a lot of drivers were initializing fields
one-by-one, leaving any newly added fields uninitialized by default.
Affected drivers may report wrong channel numbers for received beacons.
The net80211 stack will discard such beacons, assuming they were received
on the wrong channel due to signal leakage. Scanning is broken as result.
ok miod@
|
|
the channel on which a frame was received.
ieee80211_inputm() was expecting that ic->ic_bss->ni_chan would correspond
to the channel which is currently being scanned. This dates back to older
devices which are manually tuned to the next channel by the driver during
SCAN->SCAN state transitions.
However, this approach is very awkward for drivers which scan across a
whole range of channels in firmware. Such drivers had an ugly workaround
in place which tweaked ni_chan for each received frame.
Introduce a channel number field in the Rx info struct which drivers
can use to indicate the channel on which a frame was received.
If this field is set, net80211 will use it instead of using the current
channel of ic_bss. Use this new mechanism in all affected drivers.
Tested by jmc@, sthen@, and myself on iwm(4) and iwx(4).
Changes to iwn(4) and bwfm(4) are the same mechanical changes to get rid
of the ni_chan tweak, and are therefore expected to work.
ok sthen@ dlg@
|
|
|
|
Clear HT-related rxon flags in firmware when switching away from RUN
or ASSOC state. This avoids fatal firmware errors.
When starting a scan, set link state down and clear ic_bss before
sending the scan command to the device, not after.
tested by mbuhl@ on eduroam
ok mbuhl@
|
|
feedback and ok tb@ jmc@ ok ratchov@
|
|
Tested:
4965: jsg
5300: stsp, Jan Stary
6030: Fred Crowsons
6200: stsp
6205: stsp, Josh Grosse
6300: okan, afresh1
|
|
No functional change, as this data is not being used anywhere yet.
|
|
Our driver was using the wrong data structure for RXON_ASSOC commands on
4965 devices. This resulted in fatal firmware errors during association.
Problem found and fix tested on 4965 by jsg@.
Patch also tested on 6200 by me.
|
|
For the moment we use either the 40MHz rate set or the 20 MHz one,
depending on whether our peer supports 40MHz channels.
If this turns out to be suboptimal we could probe the 40MHz and 20MHz
rate sets separately to detect which one works better.
The same applies to use of the short guard interval (SGI), which is
either always on or off at the moment. Again, probing for this could
be added later if needed.
|
|
These drivers will now report "fatal firmware error" on a single line
by default and provide the full trace when debugging has been enabled
with e.g. 'ifconfig iwm0 debug'.
ok sthen@ kevlo@
|
|
- HT protection settings (this was already implemented)
- ERP (11g) protection setting
- short slottime setting
- short preamble setting
- EDCA (QoS) parameters
All of these parameters are communicated in beacons and hardware is
now kept up-to-date with them.
Prompted by a problem report from Christian Ehrhardt regarding ERP.
Tested:
iwn 6205: stsp, Josh Grosse
iwm 7265: trondd
iwm 8265: stsp, Matthias Schmidt
iwm 9260: phessler
iwx ax200: stsp, jmc, gnezdo
|
|
of trying to be smart and clearing already acknowledged frames which are
still within the firmware's BA window.
This matches what the Linux driver does and makes our driver code simpler.
Also, Tx rate control code relies on sequence numbers falling into the
BA window so let's skip Tx rate control for frames before this window.
Tested by:
myself on 6205 and 6300
afresh1, bluhm, and paco on 6300
jmatthew on 5100
Balder Oddson on 6205
|
|
which represents the AP, rather than the firmware's broadcast node.
Fixes a problem where firmware would generate bogus block ack requests
with a wrong starting sequence number, shifting the receiver's block ack
window out of sync with that of the firmware. Traffic would stall until
enough frames were sent to wrap sequence numbers of the block ack window.
ok chris@ kmos@
|
|
Tested by:
iwn 6200: stsp
iwn 6205: cwen, Jeremy O'Brien
iwn 6300: okan
|
|
OK dlg@, bluhm@
No Opinion mpi@
Not against it claudio@
|
|
|
|
Pointed by and ok jsg@
|
|
Patch by Holger Mikolon
|
|
Patch by Holger Mikolon
ok tobhe@
|
|
|
|
IWN_LSB() returns an index starting with 1, however the arrays used
later on (noise and gain in iwn5000_set_gains()) start with 0. The
previous code accounted for this difference when setting the antenna
gain by accessing cmd.gain[i - 1]. However the noise array was accessed
with noise[i], the chainmask was checked against i, and more importantly
the overall for() loop iterated wrongly over the antennas by always
starting with i=2 (the third antenna). One consequence is that gain
calibration never happened in case of only two antennas.
Patch by Holger Mikolon.
|
|
A-MPDU ran while a fixed Tx MCS was configured. The intention was of
course the inverse: Use automatic rate control if Tx MCS is not fixed.
There is a second bug which went unnoticed because of the above bug.
The value of 'seq' provided by firmware may be smaller than ba_winstart.
When this happened it triggered a KASSERT in ieee80211_output_ba_record_ack.
iwn_ampdu_rate_control() implicitly assumes that its 'seq' parameter equals
ba_winstart, so just pass that value directly.
tested by bket@, jmc@, and myself
ok mpi@
|
|
|
|
triggered the Tx completion interrupt, instead of the frame with the starting
sequence number (SSN) of the firmware's block ack window. The frame at SSN
is unrelated and may not even have been transmitted yet.
tested by bket@, jmc@, and myself
ok mpi@
|
|
"new" API.
ok dlg@ tobhe@
|
|
while building a scan command for the firmware. This isn't the right place
to set our address, which has already been set during driver initialization.
ok mpi@ kettenis@
|
|
decryption failed. The node here is always ic_bss, for which the
reference count isn't actually used (it's always freed when the interface
detaches), so missing these calls wasn't really a problem.
ok stsp@
|
|
|
|
So far, drivers using hardware CCMP decryption were expected to keep the
most recently seen CCMP packet number (PN) up-to-date, and to discard frames
with lower PNs as replays.
A-MPDU subframes may legitimately arrive out of order, and the drivers skipped
CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(),
after the driver is done with a frame. Drivers cannot tell replayed frames
apart from legitimate out-of-order retransmissions.
To fix this, update the PN value in ieee80211_inputm() after subframes have
been reordered into their proper sequence. Drivers still perform replay checks
but they no longer have to worry about updating the last seen PN value.
The 802.11 spec confirms that replay checking is supposed to happen after
A-MPDU re-ordering.
Tested by jmc@, benno@, solene@, and myself with the following drivers:
athn(4), iwn(4), iwm(4), wpi(4), urtwn(4)
ok solene@
|
|
block ack notifications sent by iwn(4) firmware").
This effectively reverts changes in how the driver interacts with firmware
and fixes connections getting stuck for unknown reasons, in two known cases:
One with an Airport Extreme 6th gen AP and another with a b-box 3V+ modem
using a Sagemcom MAC address for its built-in AP.
The Sagemcom case was observed by myself.
The Airport case was reported by Jeremy O'Brien via abieber@.
I am committing this now to prevent the problem from affecting 6.7 release
even though we don't yet understand what caused the problem.
ok mpi@
|
|
ok deraadt@
|
|
Fix wrong assumptions about what the data in these notifications is supposed
to represent, and actually piece information about individual subframes of
aggregated frames (A-MPDUs) back together when reporting to MiRA, rather than
reporting unrelated subframes to MiRA individually.
Testing by cwen@, Josh Grosse, f.holop, benno@
ok jmatthew@
|
|
This mostly prepares the driver for MIMO support but should also allow for
a higher number of hardware retries at low rates.
Tested by jmc@ and myself.
ok jmatthew@
|
|
When this error occurs, it tends to occur multiple times in a row. Affected
frames are lost and never get transmitted, and traffic stalls for a while.
I don't understand what is causing this. I have found that it only occurs if
we ask the firmware to use its multi-rate retry table. If we send frames at
a fixed rate, it does not happen. So this can be used as a workaround until
the real problem is understood.
Since this error is particularly problematic with block ack, use a fixed Tx
rate for aggregation queues for now. All subframes contained in an aggregate
are always sent together at the same rate anyway.
ok mpi@
|
|
ok jmatthew@ mpi@
|
|
every CCMP encrypted frame is discarded by the AP as a replay.
This happened because of CCMP frames with out of range PNs sent by hardware.
It seems iwn firmware doesn't like it if we reset the Tx scheduler slot for
a frame which is still within the firmware's block ack window, even if the
frame has already been ACKed. So frames now get cleared off the Tx queue
only when the block ack window has moved past them, which is good enough and
seems to prevent the problem.
Problem reproduced and fix tested by both myself and jca@
|
|
Same change as made for iwm(4) and iwx(4), but also accounts for block ack.
Avoids Tx results being reported and evaluated even if they did not correspond
to the most recently chosen rate, spoiling the data available to the rate
control algorithm.
tested by benno, jmc, and krw; no regressions seen
|
|
Tx aggregation is stopped. Fixes a bug where outstanding frames on
the aggregation queue interfere with roaming to another AP.
net80211 will only roam once all outstanding frames destined for the
old AP have been sent, i.e. once that AP node's Tx refcount goes to 0.
Any outstanding frames sitting in the Tx aggregation queue, waiting to
be ACKed, will keep this refcount above zero.
To make roaming work reliably in combination with Tx aggregation, the
driver must ensure that ieee80211_release_node() gets called for each
frame on the queue when Tx aggregation is stopped.
Problem observed by tobhe@
Fix tested + ok tobhe@ jca@
|
|
to APs that are relatively far away and suffer some packet loss.
The former threshold was 7 beacons (about 700 ms).
This raises the threshold to 30 beacons (about 3 seconds).
Should still be good enough for detecting APs that have disappeared, and
makes wifi networks provided by the University of Bucharest more reliable
in the p2k19 hackroom.
While here, make 'ifconfig iwm0/iwn0 debug' print an obvious message when
we believe that the AP has disappeared.
Problem reported and fix tested by landry@ / pirofti@
ok mpi@ sthen@
|
|
Synced from iwm(4).
ok stsp@ patrick@
|
|
it was previously (ab)used by pflog, which has since been fixed.
apart from that nothing else used it, so we can trim the cruft.
ok kn@ claudio@ visa@
visa@ also made sure i fixed ipw(4) so i386 won't break.
|
|
the radiotap code prepends a big struct to the packets, and wires
them up with the packet by putting an mbuf on the stack and using
that as the head of an mbuf chain. bpf_mtap_hdr does the chain head
thing for us, so shrink this code by calling the bpf function.
there's some other drivers that do this too, so if anyone wants a
free commit they should go looking in the other wireless drivers
and do the same change.
ok claudio@
|
|
This reduces drops caused by the ifq pressure drop mechanism and hence
increases throughput. Such drops are visible with e.g. 'netstat -dnI iwm0'.
Not all affected drivers have been tested yet but these changes are largely
mechanical and should be safe. As usual, please report any regressions.
With help from dlg@ and mpi@
Problem found by robert@
Tested by robert, jmc, Tracey Emer, Matthias Schmidt, florian, Björn Ketelaars
ok mpi@
|
|
crash reported by mlarkin@
|
|
are in media autoselect mode.
The interface might have been switched to a fixed PHY mode during association
and keeping it fixed will mislead AP selection after roaming failure.
Problem found and diagnosed at CCC camp 2019
Tested by myself, fkr@, chris@
|
