Wireless Daemon for Linux
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: Michael Johnson <mjohnson459@gmail.com>
Cc: iwd@lists.linux.dev
Subject: Re: [PATCH 1/2] netdev: Add logging for CQM messages
Date: Mon, 1 Aug 2022 13:30:44 -0500	[thread overview]
Message-ID: <837ca848-73dc-3811-2845-8d9be235afa6@gmail.com> (raw)
In-Reply-To: <CACsRnHW4N1aBkcJyeAppgMj1bqV8t3V_BwYrjy+MB=S0uepaWg@mail.gmail.com>

Hi Michael,

On 8/1/22 13:09, Michael Johnson wrote:
> Hi Denis,
> 
> On Mon, 1 Aug 2022 at 18:24, Denis Kenzior <denkenz@gmail.com> wrote:
>> I wonder if we should report this over D-Bus instead?  I mean you can always
>> setup your own SignalLevelAgent, or we could even add more reporting via
>> StationDiagnostic interface?
> 
> I actually do record the signal level separately but it's stored in an
> annoying binary format so access is more painful :(. This was just to
> make things easier and reduce the jump from wpa_supplicant to iwd for
> anyone on plain ubuntu etc. I can understand why you don't want the
> spam though.

I don't mind the spam in debug mode, that's what it is for.  But not sure they 
really belong at info/warn levels.  I think we can consider putting in roaming 
related messages at the info level since that type of information might be 
generally useful.

> 
>> Right, but I think it sets a single CQM threshold, not multiple like we (might)
>> do.  Also, wpa_s is very spammy since it is really (only) meant for testing wifi
>> implementations in a lab ;)
> 
> haha fair. Of course, it's still the default on most linux systems ;).
> 

And we're working to change that.

> 
> What would you like to do with the patch? I'm happy to drop it if its
> too spammy or we can lower the level to debug? Or make it only print
> when the threshold changes.

I don't mind these at debug level, if you want to start with that.

> Are you happy with the packet loss and beacon loss events or are they
> too much as well?

As I mentioned before, kernel will generally disconnect us as soon as the beacon 
loss event happens (depends on the STA capability if I recall correctly).  Not 
sure how really useful this is, but since beacon loss goes via dmesg at 'info' 
level, I think it would be fine for iwd to do so as well.

The packet loss one I'm not sure.  Certaintly not 'warn'.  I think I'd start 
with 'debug' since this event isn't being reacted to (yet).

Regards,
-Denis

      reply	other threads:[~2022-08-01 18:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 10:06 [PATCH 1/2] netdev: Add logging for CQM messages Michael Johnson
2022-08-01 10:06 ` [PATCH 2/2] station: Log scan results during a roam Michael Johnson
2022-08-01 15:17 ` [PATCH 1/2] netdev: Add logging for CQM messages Denis Kenzior
2022-08-01 16:18   ` Michael Johnson
2022-08-01 17:14     ` Denis Kenzior
2022-08-01 18:09       ` Michael Johnson
2022-08-01 18:30         ` Denis Kenzior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837ca848-73dc-3811-2845-8d9be235afa6@gmail.com \
    --to=denkenz@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=mjohnson459@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox