public inbox for iwd@lists.linux.dev
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: Martin Petzold <martin.petzold@tavla.de>,
	"iwd@lists.linux.dev" <iwd@lists.linux.dev>
Cc: Denis Kenzior <denkenz@gmail.com>
Subject: Re: Frequent Disconnects / Roaming Issue with IWD + systemd-networkd
Date: Mon, 29 Jul 2024 05:38:51 -0700	[thread overview]
Message-ID: <e0b71ad0-0fcf-479e-b976-0f84d36a88c2@gmail.com> (raw)
In-Reply-To: <85ef594d-d928-4d12-8741-b3d897c008fa@tavla.de>

Hi Martin,

On 7/28/24 11:53 AM, Martin Petzold wrote:
> Hi all,
>
> this issue is related to my previous issue, see [1]. It seems quite 
> sure that BSSes are blacklisted and, therefore, do not re-connect or 
> re-connect after a long period of time and then lose the connection 
> again. I cannot tell the exact reason, still working on getting some 
> logs from these devices.
Yeah I don't think there is much that can be done without debug logs to 
see exactly why.
> Changing the blacklist configurations helps in terms of the devices 
> coming back, also adding "IgnoreCarrierLoss" in systemd-networkd 
> configuration seems to make the situation better. However, still 
> really bad!

So fwiw if you suspect blacklisting is the issue you can always lower 
the blacklist timeout very low. For our use case we have it set to 2s, 
only to ensure the BSS gets blacklisted for the remainder of that 
connection attempt. All our clients run on a known network 
infrastructure though, which may not be true for you, but disabling the 
blacklist (by setting a low maximum timeout) will only cause IWD to try 
connecting again after certain failures.

>
> I have now updated to most recent Laird firmware (11.x), IWD 1.27 and 
> systemd 252. The problem still exists without any difference. Of 
> course our customer now also investigates his AP infrastructure, which 
> also could be miss-configured.
>
> This issue is especially present with multiple AP with same SSID 
> (typical roaming setup). But also present with single router. The 
> signal strength of the APs is usually low between -60 and -80 (and may 
> change also over time - closed doors etc.). We still have a stationary 
> device. Maybe it is jumping between AP and then blacklisting these AP.
>
> 1. I wonder if the problem could be related to systemd-networkd 
> managing the network interface and DHCP?
Hard to say without debug logs.
>
> 2. What is actually your recommended management configuration with IWD 
> + systemd-networkd (1.27 and 2.x)?
This really comes down to personal preference. I prefer using IWD 
because it removes one more dependency but there isn't any problem with 
using systemd-networkd either.
>
> -> Like everything should work, especially Wi-Fi and also roaming 
> scenarios.
>
> 3. What does IWD do using the "RoamThreshold5G" value of "-76" and 
> with two APs and same SSID (roaming) with slightly lower or changing 
> values?
If the current connection drops below the threshold IWD issues a roam 
scan, and if there is a better AP out there it will attempt a roam. If 
no better AP exists it remains on the current, even if the threshold is 
below that value. As long as the current RSSI is below that value IWD 
will continue to scan looking for a roam target.
>
> 4. Is the following configuration correct, if I want IWD to manage the 
> network interface and DHCP, and still let systemd-networkd knowing the 
> interface?
>
> -> I need the *.network for wait-for-online triggers and also because 
> I am reading out the network topology using networkctl and there is 
> also an Ethernet interface.
>
> ##### /etc/iwd/main.conf
>
> [General]
> EnableNetworkConfiguration=true
>
> [Network]
> NameResolvingService=systemd
>
> [Scan]
> InitialPeriodicScanInterval=10
> MaximumPeriodicScanInterval=60
>
> [Blacklist]
> InitialTimeout=60
> MaximumTimeout=3600
I would suggest setting MaximumTimeout to something low, at least to 
debug if this is indeed the issue you are seeing. If APs are routinely 
failing to allow clients to connect they will be blacklisted.
>
> ##### /etc/systemd/network/20-wlan0.network
>
> [Match]
> Name=wlan0
>
> [Link]
> RequiredForOnline=no
>
> #####
I'm no systemd expert, but this seems fine. I think as long as you don't 
set any DHCP settings in systemd it should work with IWD managing the IP.
>
> [1] 
> https://lore.kernel.org/iwd/8c7ff992-2f03-4e4f-97bc-36eab3727d44@tavla.de/T/
>
> Thanks,
>
> Martin
>
>

      reply	other threads:[~2024-07-29 12:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-28 18:53 Frequent Disconnects / Roaming Issue with IWD + systemd-networkd Martin Petzold
2024-07-29 12:38 ` James Prestwood [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=e0b71ad0-0fcf-479e-b976-0f84d36a88c2@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=denkenz@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=martin.petzold@tavla.de \
    /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