On Fri, May 07, 2021 at 10:02:56PM +0000, 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 +0000, 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 more information about the bad key.
> > Could you run with this?
> >
> > diff 87962d75d1c1a416b89e927cd4ab8e3327a47509 /usr/src
> > blob - 037aca21138df15a4b0b8ec2a96afd8d67c5e3cc
> > file + sys/net80211/ieee80211_crypto.c
> > --- sys/net80211/ieee80211_crypto.c
> > +++ sys/net80211/ieee80211_crypto.c
> > @@ -257,8 +257,10 @@ struct mbuf *
> > ieee80211_encrypt(struct ieee80211com *ic, struct mbuf *m0,
> > struct ieee80211_key *k)
> > {
> > - if ((k->k_flags & IEEE80211_KEY_SWCRYPTO) == 0)
> > - panic("%s: key unset for sw crypto: %d", __func__, k->k_id);
> > + if ((k->k_flags & IEEE80211_KEY_SWCRYPTO) == 0) {
> > + panic("%s: key unset for sw crypto: id=%d cipher=%d flags=0x%x",
> > + __func__, k->k_id, k->k_cipher, k->k_flags);
> > + }
> >
> > switch (k->k_cipher) {
> > case IEEE80211_CIPHER_WEP40:
>
> Finally managed to `got rebase` all my testing diffs with above
> included and build new kernel. Not deployed yet. Panic is very rare,
> looking at my logs it's between once per quarter and even once per
> half of a year. I'm not always in a position to quickly rebase my
> testing diffs and sometimes I just deploy official snapshot, because
> sysupgrade makes it so super easy.
>
> Do you think above could be committed to HEAD?
Yes, I will commit it.
> Wrong place, wong time.. but could `got rebase` return dedicated
> exit code for below situation?
>
> $ got rebase main
> got: refs/heads/main is already based on refs/heads/key-unset-printf-trigger
>
> At present it's exit code 1, but if that would be lets say 2, I could
> improve my automation script to rebase stack of my diffs and rebuild
> my custom kernel in more efficient manner. Probably without human
> intervention.
How about returning exit code 0 in this case? There's nothing to be done
so the command could "trivially" succeed.
