All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Zaborowski <andrew.zaborowski@intel.com>
To: iwd@lists.01.org
Subject: Re: Reconnect issues, still
Date: Wed, 10 Feb 2021 00:33:00 +0100	[thread overview]
Message-ID: <CAOq732Kh64TRDOuFjAvkN1YGgfKiW-DtsQOM=h3ndaPgKos8aA@mail.gmail.com> (raw)
In-Reply-To: <CAG17S_OkvN8dYd=NOdg_u8Gowv5bsp7=Hbjq8GAVYVUYSW0m6w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Hi Keith,

On Wed, 10 Feb 2021 at 00:11, KeithG <ys3al35l@gmail.com> wrote:
> I see a similar result, though the mechanism may be different, on an x86 laptop also running Arch Linux. I use iwd with NetworkManager on this computer and if I do the same thing (restart radio on router), it also does not reconnect. NM is 1.28.1dev+7+g3f5df3cdc6 and iwd is v1.11. If it is force disconnected from the router it never tries to reconnect. If I select it from the drop down, it reconnects.
>
> I noticed that NM did not set 'AutoConnect=true' in the /var/lib/iwd/spg3.psk file, so I added it and verified that iwctl reports that this feature is set (It did not before), but even after this was added, it does not reconnect when it is forced off the network by rebooting, disconnecting or cycling the radio.
>
> The iwd-monitor log shows lots of this:
> {Station} [/net/connman/iwd/0/4] Scanning = False
> {Station} [/net/connman/iwd/0/4] Scanning = True
> {Station} [/net/connman/iwd/0/4] Scanning = False
> {Station} [/net/connman/iwd/0/4] Scanning = True
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/4/426964656e486172726973_psk]
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/4/4e4554474541523336_psk]
>       Name = NETGEAR36
>       Connected = False
>       Device = /net/connman/iwd/0/4
>       Type = psk
> {Station} [/net/connman/iwd/0/4] Scanning = False
> {Station} [/net/connman/iwd/0/4] Scanning = True
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/4/415454687a4366547869_psk]
>       Name = ATThzCfTxi
>       Connected = False
>       Device = /net/connman/iwd/0/4
>       Type = psk
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/4/5261676e6172_psk]
>       Name = Ragnar
>       Connected = False
>       Device = /net/connman/iwd/0/4
>       Type = psk
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/4/4d65617374657761_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/4/41545470666b766e4378_psk]
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/4/4e4554474541523539_psk]
>       Name = NETGEAR59
>       Connected = False
>       Device = /net/connman/iwd/0/4
>       Type = psk
> {Station} [/net/connman/iwd/0/4] Scanning = False
> ...
>
> Interestingly, none of the logs I made actually showed that iwd had scanned and found the network that it was just previously connected to in the list of Network Names. While scanning, it sees the 2.5 network on the same router, but not the 5Ghz that it knows the password to. If I do a 'iwctl wlan0 get-networks', the 5Ghz radio is at the top of the list but it does not connect to it. As soon as I select it in the drop down in NM it connects.
>
> My questions: With NM, is it supposed to have an 'AutoConnect=true' in the psk file? If so, it does not appear that NM creates that in the psk file. Why does the scan not pick up the previously connected SSID?

A few data points:

* With NM 1.28 NM's own autoconnect mechanism is used, it doesn't
depend on IWD.  Starting with 1.30 IWD will control autoconnect by
default (can be turned off).  NM profies have their own "autoconnect"
property which also defaults to true.

* AutoConnect defaults to true so adding an AutoConnect=true to the
.psk file shouldn't have any effect.

* So far only IWD writes the .psk files, it does this the first time
NM commands IWD to connect to a specific network.

* I've seen different quirks with NM autoconnect that I don't fully
understand, but generally it works.  It seemed that network profiles
created by some previous NM versions on my distro had the owner,
permissions and/or local hardware MAC set in a way that prevented them
from ever autoactivating but they could be activated manually.

Best regards

      reply	other threads:[~2021-02-09 23:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08  4:39 Reconnect issues, still KeithG
2021-02-08 19:53 ` Denis Kenzior
2021-02-08 21:32   ` KeithG
2021-02-09 23:11     ` KeithG
2021-02-09 23:33       ` Andrew Zaborowski [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='CAOq732Kh64TRDOuFjAvkN1YGgfKiW-DtsQOM=h3ndaPgKos8aA@mail.gmail.com' \
    --to=andrew.zaborowski@intel.com \
    --cc=iwd@lists.01.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.