On Wed, Nov 17, 2021 at 07:53:44PM +0100, Stefan Sperling wrote:
> I don't see where and how this could happen, but this seems to be where
> this bug is hiding. Multicast frames are also never encrypted, so they
> would never even trigger any attempt to use a key.
Sorry, I was not making much
On Wed, Nov 17, 2021 at 03:25:36PM +, Mikolaj Kucharski wrote:
> What is strange, I would imagine, that address of they key is one
> between those two:
>
>
> $ grep -w ic_def_txkey panic.txt | cut -f3- -d: | tail
> ieee80211_setkeysdone() [ieee80211_proto.c|480] case 0 ic_def_txkey
>
On Wed, Nov 17, 2021 at 03:25:36PM +, Mikolaj Kucharski wrote:
> On Mon, Nov 15, 2021 at 12:33:09PM +, Mikolaj Kucharski wrote:
> > I have more panics, with couple of minutes gap between
> > ieee80211_setkeysdone() from ieee80211_proto.c and panic
> > in ieee80211_encrypt() from
I have more panics, with couple of minutes gap between
ieee80211_setkeysdone() from ieee80211_proto.c and panic
in ieee80211_encrypt() from ieee80211_crypto.c.
Sorry for wrapped lines, but I added Time::HiRes in a rush,
the console grabbing script.
2025.100422.505898Z: MMM:
On Mon, Sep 27, 2021 at 08:39:48AM +, Mikolaj Kucharski wrote:
> On Sat, Sep 25, 2021 at 10:25:12AM +0200, Stefan Sperling wrote:
> > On Sat, Sep 25, 2021 at 02:03:40AM +, Mikolaj Kucharski wrote:
> > > I've added more info, probably mainly for myself. I'm not sure where to
> > > go with
On Sat, Sep 25, 2021 at 10:25:12AM +0200, Stefan Sperling wrote:
> On Sat, Sep 25, 2021 at 02:03:40AM +, Mikolaj Kucharski wrote:
> > I've added more info, probably mainly for myself. I'm not sure where to
> > go with this information yet.
>
> We need to figure out what makes this code use a
On Sat, Sep 25, 2021 at 02:03:40AM +, Mikolaj Kucharski wrote:
> I've added more info, probably mainly for myself. I'm not sure where to
> go with this information yet.
We need to figure out what makes this code use a group key which
has been cleared.
Please add printfs for lines of code
I've added more info, probably mainly for myself. I'm not sure where to
go with this information yet.
On Sat, Sep 25, 2021 at 01:31:33AM +, Mikolaj Kucharski wrote:
> On Wed, Sep 22, 2021 at 03:00:37PM +, Mikolaj Kucharski wrote:
> > Another one, it happened with below diff applied.
On Wed, Sep 22, 2021 at 03:00:37PM +, Mikolaj Kucharski wrote:
> Another one, it happened with below diff applied. Didn't had time yet to
> dive into this.
I have limited time in recent months, so I'm trying to put anything what
I have in spare moment. This should be more clear, from my
Another one, it happened with below diff applied. Didn't had time yet to
dive into this.
---
commit 94d934f45b45bd87293428425164d8120ec10255 (main)
from: Mikolaj Kucharski
date: Mon Sep 20 08:35:49 2021 UTC
ignore the SWBA interrupt while we're not
On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > I got it again, but had official snapshot, so I don't have more info
> > than I had in the past, but I would like to share it anyway..
>
> > ddb{0}> show panic
On Tue, May 11, 2021 at 10:28:21AM +0200, Stefan Sperling wrote:
> On Sun, May 09, 2021 at 08:28:14PM +, Mikolaj Kucharski wrote:
> > ..and in case timestamps may give a bit more clue, here is example from
> > one of the accesspoints:
>
> Yes, this is insightful:
>
> > # grep -F
..and in case timestamps may give a bit more clue, here is example from
one of the accesspoints:
# grep -F ieee80211_encap /var/log/messages
2021-05-09T11:35:31.155Z pce-0041 /bsd: ieee80211_encap: data frame for node
c0:ee:fb:33:f0:11 in state 4
2021-05-09T11:36:07.957Z pce-0041 /bsd:
On Sat, May 08, 2021 at 10:06:08AM +0200, Stefan Sperling wrote:
>
> Fixed patch, with the condition ni != ic->ic_bss added:
>
> diff b412d6f4250f42e50e0333dbcedab9189b4b19e2 /usr/src
> blob - 58f654273f7ea0cc3c04e0a60d5e5e6a33296dc0
> file + sys/net80211/ieee80211_output.c
> ---
Hi Mikolaj, Stefan,
Am 08.05.21 um 16:16 schrieb Mikolaj Kucharski:
> On Sat, May 08, 2021 at 10:06:08AM +0200, Stefan Sperling wrote:
>> On Fri, May 07, 2021 at 10:27:36PM +, Mikolaj Kucharski wrote:
>>> Yes, I see ieee80211_encap: data frame for node... messages in
>>> dmesg. Two dmesgs,
On Sat, May 08, 2021 at 10:06:08AM +0200, Stefan Sperling wrote:
> On Fri, May 07, 2021 at 10:27:36PM +, Mikolaj Kucharski wrote:
> > Yes, I see ieee80211_encap: data frame for node... messages in
> > dmesg. Two dmesgs, from two PC Engines machines, in two different
> > locations, 150+km
On Sat, May 08, 2021 at 09:51:06AM +0200, Stefan Sperling wrote:
> >
> > Do you think above could be committed to HEAD?
>
> Yes, I will commit it.
>
Cool, thanks!
> > Wrong place, wong time.. but could `got rebase` return dedicated
> > exit code for below situation?
> >
> > $ got rebase main
On Fri, May 07, 2021 at 10:27:36PM +, Mikolaj Kucharski wrote:
> Yes, I see ieee80211_encap: data frame for node... messages in
> dmesg. Two dmesgs, from two PC Engines machines, in two different
> locations, 150+km apart, below.
>
> Uptime of 12 minutes as hostap from pce-0041:
> athn0:
On Fri, May 07, 2021 at 10:02:56PM +, Mikolaj Kucharski wrote:
> On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> > On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > > I got it again, but had official snapshot, so I don't have more info
> > > than I had
On Wed, Apr 28, 2021 at 12:52:36AM +0200, Stefan Sperling wrote:
>
> Here is another shot in the dark.
> The patch below ensures that we don't attempt to send data frames
> to nodes that aren't in associated state anymore. The node's crypto
> keys would already have been cleared which would
On Wed, Apr 28, 2021 at 12:52:36AM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> > On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > > I got it again, but had official snapshot, so I don't have more info
> > > than I had in
On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > I got it again, but had official snapshot, so I don't have more info
> > than I had in the past, but I would like to share it anyway..
>
> > ddb{0}> show panic
Hi Stefan, Mikolaj, all,
I'm glad this is getting renewed attention.
I have been unable to reliably reproduce this, but it still happens to
me from time to time.
(I am still running stable 6.8, just fyi.)
If there's anything else I can do in support, please let me know.
Stephen
Am 28.04.21
On Tue, Apr 27, 2021 at 11:32:49PM +0200, Stefan Sperling wrote:
> On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> > I got it again, but had official snapshot, so I don't have more info
> > than I had in the past, but I would like to share it anyway..
>
> > ddb{0}> show panic
On Tue, Apr 27, 2021 at 06:36:32PM +, Mikolaj Kucharski wrote:
> I got it again, but had official snapshot, so I don't have more info
> than I had in the past, but I would like to share it anyway..
> ddb{0}> show panic
> ieee80211_encrypt: key unset for sw crypto: 0
It would be nice to have
On Mon, Nov 16, 2020 at 01:57:06PM +, Mikolaj Kucharski wrote:
> On Mon, Nov 16, 2020 at 12:53:14PM +0100, Stefan Sperling wrote:
> > On Mon, Nov 16, 2020 at 10:59:45AM +, Mikolaj Kucharski wrote:
> > > It happened again. This time on current. I was on Android phone using
> > > Signal and
On Mon, Nov 16, 2020 at 12:53:14PM +0100, Stefan Sperling wrote:
> On Mon, Nov 16, 2020 at 10:59:45AM +, Mikolaj Kucharski wrote:
> > It happened again. This time on current. I was on Android phone using
> > Signal and other laptop on urwn(4) was fetching newest packages snapshot.
> >
> > In
On Mon, Nov 16, 2020 at 10:59:45AM +, Mikolaj Kucharski wrote:
> It happened again. This time on current. I was on Android phone using
> Signal and other laptop on urwn(4) was fetching newest packages snapshot.
>
> In this email thread it's different physical hardware, but I think
> it's same
It happened again. This time on current. I was on Android phone using
Signal and other laptop on urwn(4) was fetching newest packages snapshot.
In this email thread it's different physical hardware, but I think
it's same Wi-Fi card like on the other PC Engines board.
This email thread which I'm
On Thu, Sep 17, 2020 at 12:31:16PM +0200, Stefan Sperling wrote:
> On Wed, Sep 16, 2020 at 08:39:19PM +, Mikolaj Kucharski wrote:
> > This one seems random, on that machine I see it first time. CVS checkout
> > is basically the build time as I first do cvs up and then make.
>
> We have seen
On Wed, Sep 16, 2020 at 08:39:19PM +, Mikolaj Kucharski wrote:
> This one seems random, on that machine I see it first time. CVS checkout
> is basically the build time as I first do cvs up and then make.
We have seen this before, haven't we?
This means another race condition exists.
Are you
31 matches
Mail list logo
