Age | Commit message (Collapse) | Author |
|
The account flag `ASU' will no longer be set but that makes suser()
mpsafe since it no longer mess with a per-process field.
No objection from millert@, ok tedu@, bluhm@
|
|
no binary change on amd64
|
|
instead of testing some un-obvious bitfield
OK stsp@
|
|
left-over kernel malloc feature we don't use.
OK deraadt@
|
|
can use to process, and then acknowledge or reject, incoming AUTH
requests in hostap mode.
net80211 accepts an AUTH request from any STA which fits into the node
cache. This behaviour doesn't work for devices which have a lower limit
on concurrent STAs they can serve, so such drivers need an override.
This will be used by our athn(4) USB driver soon.
ok kevlo@
|
|
Using if_enqueue() here, from interrupt context, might result in
the packet beeing enqueued, incorrectly encrypted, on the TX ring.
This race has been recently exposed by the re-introduction of the
TX mitigation. It exists because the net80211 stack sets
IEEE80211_NODE_TXPROT on the node while processing the 3rd message,
assuming the answer has already been transmitted. However a CPU
returns from if_enqueue() it cannot assume that the send queue is
empty. So call if_start() to flush this queue.
Encrypting the 4th message of the 4way handshake with the new key
breaks WPA handshake as found the hardway by anton@.
Race analysed by dlg@, a lot of net80211 inputs and suggetions from
stsp@.
ok stsp@, dlg@
|
|
|
|
we aren't running in hostap or ibss mode.
|
|
a node's RSSI info while we are still in INIT state.
ok phessler@
|
|
ok patrick@
|
|
Should speed up debugging.
ok phessler patrick
|
|
Problem reported by Gregoire Jadi on bugs@
|
|
strongest received signal.
OK stsp@
|
|
2Ghz APs because the 5Ghz band is generally less saturated.
The previous implementation was dependent upon the order of walking
APs.
ok stsp
|
|
list has zero elements and PMKID would be the last field in the RSN IE.
This is correct as per 802.11-2012 8.4.2.27.1 and aligns net80211 code with
behaviour of bwfm(4) firmware, unblocking further progress in that driver.
ok patrick@ phessler@
|
|
The iwm(4) driver will now roam between access points which share an SSID.
Use 'ifconfig iwm0 debug' and 'tail -f /var/log/messages' to watch it do so.
Tested by several people in various iterations.
As usual, let me know if you run into issues.
ok phessler deraadt
|
|
The kernel is not a password database; look your wifi keys up elsewhere.
Discussed with several.
ok phessler@ jca@
|
|
OK stsp@
|
|
WPA and WEP configuration.
OK pirofti@ stsp@ sthen@
|
|
Found with ctfconv(1). ok jsg@, guenther@
|
|
ok stsp@ kevlo@ jca@
|
|
ok jsg@, stsp@
|
|
ok mpi@
|
|
priority visible to underlying bus protocols like bwfm(4)'s bcdc.
|
|
|
|
all bands at once. Fixes a problem where e.g. 5GHz APs were filtered out
if we were previously associated to an 11g-only AP.
ok mpi@ phessler@
|
|
AUTO mode if the driver scans all bands at once. Otherwise the net80211
layer unnecessarily filters out some of the beacons received by the device.
ok phessler@ mpi@ kevlo@
|
|
Some wifi drivers send a probe request if the hardware reports "missed beacon"
events. If the AP replies with a probe response it is still servicing us and
there is no need to search for a new AP. However, the management timer was not
reset if a beacon was received while in RUN state. So the interface watchdog
always ended up putting the driver into SCAN state after a missed beacon event,
even if the AP did respond to our probe request. Under some conditions this
bug would cause spurious disconnects.
Problem reported and fix tested by mlarkin@
(Using the management timer in RUN state is a new convention. Before support
for missed beacons was added, this timer was only used during the association
sequence to handle APs which don't respond to our assoc requests and such.)
|
|
with an access point. Prevents false positive 'reused group key'
warnings in dmesg when re-associating to the same access point.
Problem reported by tb@
ok tb@
|
|
group keys are being reused. OpenBSD wireless clients will now leave a
trail of such events in their message log.
There has been increased public scrutiny of WPA's security recently, so
I am curious to see if anyone is attempting replay attacks in the wild.
ok deraadt
|
|
guarded by the IEEE80211_DEBUG preprocessor flag. This shows one line
per detected AP after a scan, and indicates which APs are considered
candidates for association.
Shorten the output a bit to fit into 80 columns more likely.
ok sthen@
|
|
frames to dmesg, if debug mode was enabled with ifconfig.
This debug output was much too verbose and not actually useful for debugging.
tcpdump -y IEEE802_11_RADIO will show the same information.
ok sthen@
|
|
This information is needed in bug reports.
Convert the invalid state transitions from panic() to a printf() which is
also guarded by ifconfig debug. There are many races exposed by these panics
which should all be fixed. But that will surely take some time, and the
panics have now served their purpose. Thanks to everyone who reported
these panics being triggered, your help is appreciated.
|
|
Triggers on driver bugs such as those which were fixed in rsu(4) recently.
ok kevlo@
|
|
Problem reported by Ilja Van Sprundel.
ok tb@ kevlo@
|
|
Problem reported by Ilja Van Sprundel.
ok tb@
|
|
The previous code wasn't quite right: it didn't account for the fact that
some drivers don't set ic_max_rssi, and it compared 5GHz APs to a threshold
relative to the max RSSI, rather than comparing RSSI on 5GHz relative to
RSSI on 2GHz.
This heuristic is only used by SCANNALLBAND drivers: iwn(4), iwm(4), wpi(4)
In the future the AP selection heuristic should be made more intelligent,
e.g. it should take BSS load information in beacons into account.
Another open problem is inconsistent representation of RSSI measurement
values throughout our drivers and stack. Help is welcome!
For now, this hopefully improves AP selection at busy airports.
ok sthen@ deraadt@
|
|
From IEEE Std. 802.11-2016, Table 18-5 "ERP characteristics", p. 2332:
aSlotTime characteristic:
If dont11OperatingClassesRequired is false:
Long = 20 us
Short = 9 us
ok stsp@
|
|
interface is attached to the net80211 layer. Prevents confusion
in cases where drivers forget to initialize the link state.
ok mpi@ kettenis@
|
|
to make it more readable.
help, many explanations and ok stsp
|
|
Input, help & ok stsp
|
|
ok stsp
|
|
This should make fading APs time out consistently regardless of what the
beacon interval is set to (range is 1 to 2^16 TU, though in practice 100 TU
seems to be a common value).
Print the beacon interval and missed beacon counter threshold to dmesg
if the DEBUG flag was set on the wireless interface with ifconfig(8).
This should help with diagnosing any issues that pop up.
Requested and diff eye-balled by kettenis@
help & ok tb@ phessler@
|
|
which specified how much time may elapse without beacons before drivers
begin searching for a new AP.
Drivers convert this timeout value into the amount of beacons they're allowed
to miss. Having the stack provide this number upfront simplifies things.
ok mpi@
|
|
Instead of returning an index into ni_rates, return the RVAL of the
basic rate we want to use. This allows a driver to unambiguously map
the basic rate to the corresponding hardware-specific rate value, and
reduces the possibility of bugs where indices are used with arrays
they weren't intended for.
Adjust iwn(4) accordingly, and use the lowest instead of the highest
basic rate in iwn_tx() to cope better in noisy environments.
Fixes association problems on 5GHz reported by tb@
|
|
These helpers can be used by drivers to improve compatibility with APs
that disable some mandatory PHY rates in the basic rate set.
For instance, many of our drivers hard-code 11b rates on 2 Ghz and run
into problems when APs disable them. Since 11b rates are being disabled
by default by some vendors, hardcoding them is not a good idea anymore.
ok mpi@ phessler@
|
|
of whether the wifi interface happens to be leaving RUN state. The interface
is never usable during state transitions so setting the link DOWN is the only
reasonable option when any transition is triggered.
Fixes a problem where, at boot time, the link state of wifi interfaces was
reported to userland as UNKNOWN (which, curiously, has value 0). dhclient's
link detection logic was recently changed from ifmedia to getifaddrs which
exposed the UNKOWN link state. Since dhclient assumes an UNKNOWN link state
means UP it would start trying to negotiate a lease too early during boot.
Problem reported by tb@
ok krw@
|
|
OK stsp@
|
|
If an AP is configured to hide its SSID it sends a non-zero length SSID
which contains only zeroes. The AP sends its actual SSID only in probe
responses after a client includes this SSID in a probe request.
If we happened to receive a beacon before the probe response we stored a
non-zero-length SSID of zeroes and never updated the SSID when the probe
response arrived. The client was then unable to find the AP.
test & ok jung@
|
|
Problem reported by Colton Lewis on misc@
ok tb@
|