OpenBSD cvs log

created 2021-08-21T22:13:54Z
begin 2021-08-19T00:00:00Z
end 2021-08-20T00:00:00Z
path src/sys
commits 6

date 2021-08-19T06:02:04Z
author stsp
files src/sys/dev/pci/if_iwm.c log diff annotate
src/sys/dev/pci/if_iwn.c log diff annotate
src/sys/dev/pci/if_iwx.c log diff annotate
message Hide detailed firmware error reports from iwn/iwm/iwx by default.

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@

date 2021-08-19T06:02:39Z
author stsp
files src/sys/dev/ic/bwfm.c log diff annotate
message Fix an off-by-one in bwfm(4) SSID length checks.
SSIDs are binary data, not NUL-terminated strings.

ok patrick@

date 2021-08-19T10:22:00Z
author dlg
files src/sys/net/if_ethersubr.c log diff annotate
src/sys/net/if_vlan.c log diff annotate
src/sys/net/if_vlan_var.h log diff annotate
message implement reception of "VLAN 0 priority tagged" packets.

according to 802.1Q, vlan 0 on the wire is special and should be
interpreted as if it was a packet received on the parent interface,
but you get the packet priority information encoded in the vlan
header.

historically we drop vlan tagged packets that don't have a vlan
interface configured for the received tag number. historically we
have deviated from 802.1Q by allowing for the configuration of a
vlan subinterface with the vnetid "unset". this works just like any
other vlan interface, but it uses tag 0 on the wire. however, if
you're in a situation where you're receiving vlan tagged 0 packets
that really are part of the same layer 2 ethernet domain as the
parent inteface, this doesnt work well.

landry@ is in such a situation at work where the network is sending
his OpenBSD boxes packets with VLAN tag 0. sometimes. most of the
time the packets are untagged, which is expected, but sometimes
they have a VLAN header set. this causes problems, particularly
with arp.

this diff does the smallest possible change to enable reception of
these vlan 0 priority tagged packets. if an "unset" vlan interface
is not configured on the parent, then vlan 0 tagged packets get
their header stripped and continue stack processing as if they didnt
have the tag at all.

landry has been running this for months.
ok sthen@ claudio@

date 2021-08-19T13:58:40Z
author patrick
files src/sys/dev/ic/bwfm.c log diff annotate
message Consistently use ieee80211_begin_scan() to switch to SCAN.
React to deauth/disassoc and link state events if we're
already past the SCAN stage.

ok stsp@

date 2021-08-19T14:13:39Z
author patrick
files src/sys/dev/ic/bwfm.c log diff annotate
message Purge the cached nodes when we switch back to SCAN. In case we lost
the connection because an AP is gone away, this makes sure we don't
end up picking a now non-existant AP over and over.

Another problem this works around is that when trying to re-join that
AP, the attempt to connect would not yield any event message from the
firmware, and then we would get stuck. Since we now definitely choose
a different AP, this issue does not show up.

ok stsp@

date 2021-08-19T18:45:11Z
author stsp
files src/sys/dev/pci/if_iwm.c log diff annotate
src/sys/dev/pci/if_iwx.c log diff annotate
message Run more device init code when resuming iwm(4) and iwx(4) devices.

deraadt@ pointed out that the resume code path only ran a small part
of the entire hardware init sequence which runs when the device is
first attached at boot time.

In particular, we didn't wait for device stabilization, and MSI-X
initialization was attempted too early, and the "persistence bit"
workaround was skipped (which, ironically, is supposed to address
a known hardware bug during resume).

Tested by jcs on AX201 and by myself on 8265 with no regressions seen.