This is likely now fixed in -current. See https://marc.info/?l=openbsd-cvs&m=158201459403461&w=2
On Thu, Mar 21, 2019 at 11:45:22AM +0100, Stefan Sperling wrote: > On Thu, Mar 21, 2019 at 11:38:44AM +0100, Stefan Sperling wrote: > > On Thu, Mar 21, 2019 at 10:21:37AM +0000, Kevin Chadwick wrote: > > > On 3/20/19 8:58 AM, Stefan Sperling wrote: > > > >>> I see a possibility that this could be triggered by QoS data frames > > > >>> from foreign networks, in which case the bug might not trigger > > > >>> reliably > > > >>> unless you produce foreign 11n network traffic yourself. > > > > > > >> OK, I shall play around and see if I can trigger it earlier. > > > > > > > Thanks! Please try without the diff first, and once it has triggered > > > > try to trigger it again with the diff. > > > > > > > > > My network is in 11G mode. Is it still possible for n frames to trigger > > > this bug? > > > > I cannot easily tell you that. What I'm doing is I'm going through the > > code trying to spot code paths which could make us hit that assertion. > > I cannot yet reproduce this problem myself, and I cannot tell you all > > the variables which might be involved. I am making blind guesses which > > need to be verified by actual tests from people who are seeing this issue. > > That said, if anyone is able to unearth more evidence such as packet captures > leading up to the problem, that would of course help me a great deal. > > At present, the best method is to listen with a separate iwn(4) device > in monitor mode on the same channel. Example for channel 1: > ifconfig iwn0 down -nwid > ifconfig iwn0 mode 11n > ifconfig iwn0 mediaopt monitor > ifconfig iwn0 chan 1 > ifconfig iwn0 chan 1 # workaround for channel-setting bug in monitor mode > ifconfig iwn0 up > tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwn.pcap > If you need more help with this, just ask. >
