From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [RFC 0/4] Fix extra settings not being taken post-DPP
Date: Wed, 13 Dec 2023 16:59:44 -0600 [thread overview]
Message-ID: <a269538b-9c6f-4646-8294-c93ecd06475b@gmail.com> (raw)
In-Reply-To: <20231213172546.145998-1-prestwoj@gmail.com>
Hi James,
On 12/13/23 11:25, James Prestwood wrote:
> The current logic in DPP syncs the settings to disk but this doesn't
> actually turn an existing network object into a known network, i.e.
> sets network->info, which then allows settings to be loaded from
> disk via the open() op. Currently a connection can be made (since the
> PSK is set into the network object) but any additional settings like
> Hidden/SendHostname are not used.
Okay. So you can solve this in two ways:
1. Have dpp listen to KNOWN_NETWORKS_EVENT_ADDED and start the connection once
the new network has been detected.
2. Fix match_known_network to take care of merging the new settings with the
temporary settings obtained from the agent / set using network_set_*.
Advantage of 2 is that you'd be fixing the current race condition that exists
today, where if the connection is started and a profile is modified while the
connection is ongoing, the new settings are not taken into account.
>
> This set is one way we could solve it, though its a bit intrusive
> and requires DPP have deeper knowledge that it really should
> regarding known networks. It basically forces the creation of a
> known network, and I did have to modify __network_info_init to set
> the default ops structure, which was a bit nasty. This is the most
> direct route without having to worry about callbacks and/or idle
> functions.
>
> An alternative way would be to watch the known networks events from
> DPP and connect only after an ADDED event. The reason I didn't go
> this route was because I wasn't sure about the event ordering. We
> need the watch in network.c to be called first (so the network->info
> can be created), then connect from DPP. watchlist_add does append to
Just use l_idle
> the tail of the queue so in theory as the above _should_ work so long
> as the network watch is added prior to DPP, which is the case since
> network's is added in init versus DPP. But I'd hate to put an implied
> dependency on watchlist ordering if this changes later. This could
> be coupled with an l_idle to avoid the watchlist ordering, but thats
> yet another callback.
>
Regards,
-Denis
prev parent reply other threads:[~2023-12-13 22:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 17:25 [RFC 0/4] Fix extra settings not being taken post-DPP James Prestwood
2023-12-13 17:25 ` [RFC 1/4] knownnetworks: set ops on info in __network_info_init James Prestwood
2023-12-13 17:25 ` [RFC 2/4] station: unify scan cancelation James Prestwood
2023-12-13 17:32 ` James Prestwood
2023-12-13 17:25 ` [RFC 3/4] dpp: fix non-scan connect path in DPP James Prestwood
2023-12-13 17:25 ` [RFC 4/4] auto-t: add a few more DPP tests for seen/known networks James Prestwood
2023-12-13 22:59 ` 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=a269538b-9c6f-4646-8294-c93ecd06475b@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).