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. |