[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    Re: athn panic: invalid key cipher 0x0
From:       Stefan Sperling <stsp () openbsd ! org>
Date:       2019-03-21 10:45:22
Message-ID: 20190321104522.GY90911 () ted ! stsp ! name
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]