From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 2/5] knownnetworks: network: support updating known network settings
Date: Fri, 15 Dec 2023 10:37:02 -0600 [thread overview]
Message-ID: <e2b80483-8976-454f-8b7d-428bbb63ea89@gmail.com> (raw)
In-Reply-To: <20231214180110.130991-2-prestwoj@gmail.com>
Hi James,
On 12/14/23 12:01, James Prestwood wrote:
> Currently if a known network is modified on disk the settings are not
> reloaded by network. Only disconnecting/reconnecting to the network
> would update the settings. This poses an issue to DPP since its
> creating or updating a known network after configuration then trying
> to connect. The connection itself works fine since the PSK/passphrase
> is set to the network object directly, but any additional settings
> are not updated.
>
> To fix this add a new UPDATED known network event. This is then
> handled from within network and all settings read from disk are
> applied to the network object.
Okay, so you chose option 2...
> ---
> src/knownnetworks.c | 4 ++
> src/knownnetworks.h | 1 +
> src/network.c | 104 ++++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 106 insertions(+), 3 deletions(-)
>
<snip>
> diff --git a/src/network.c b/src/network.c
> index 41c5460b..bd3671ca 100644
> --- a/src/network.c
> +++ b/src/network.c
> @@ -730,6 +730,73 @@ static void network_settings_save(struct network *network,
> network_settings_save_sae_pt_ecc(settings, network->sae_pt_20);
> }
>
> +static bool network_settings_update(struct network *network,
> + struct l_settings *new)
> +{
> + bool have_transition_disable;
> + uint8_t transition_disable = 0;
> + unsigned int i;
> + size_t psk_len;
> + _auto_(l_strv_free) char **list = NULL;
> + _auto_(l_free) uint8_t *psk = NULL;
> + _auto_(l_free) char *passphrase = NULL;
> +
> + if (l_settings_get_bool(new, NET_TRANSITION_DISABLE,
> + &have_transition_disable) &&
> + have_transition_disable) {
> + list = l_settings_get_string_list(new,
> + NET_TRANSITION_DISABLE_MODES, ' ');
> +
> + for (i = 0; list[i]; i++) {
> + if (!strcmp(list[i], "personal"))
> + set_bit(&transition_disable, 0);
> + else if (!strcmp(list[i], "enterprise"))
> + set_bit(&transition_disable, 1);
> + else if (!strcmp(list[i], "open"))
> + set_bit(&transition_disable, 2);
> + }
> +
> + have_transition_disable = true;
> + } else
> + have_transition_disable = false;
> +
> + if (network->security != SECURITY_PSK)
> + goto apply;
> +
> + psk = l_settings_get_bytes(network->settings, "Security",
> + "PreSharedKey", &psk_len);
> + if (psk && psk_len != 32) {
> + l_warn("updated [Security].PreSharedKey value is invalid!");
> + return false;
> + }
I'm not sure you really want to yank the PSK or Passphrase actually. These are
obtained via the Agent and should take precedence.
> +
> + passphrase = l_settings_get_string(network->settings,
> + "Security", "Passphrase");
> + if (passphrase && !crypto_passphrase_is_valid(passphrase)) {
> + l_warn("updated [Security].Passphrase value is invalid!");
> + return false;
> + }
> +
> +apply:
> + network_settings_close(network);
> + network->settings = new;
> +
> + network->have_transition_disable = have_transition_disable;
> + network->transition_disable = transition_disable;
> +
> + if (psk)
> + network->psk = l_steal_ptr(psk);
> +
> + if (passphrase) {
> + network->passphrase = l_strdup(passphrase);
> +
> + network_settings_load_pt_ecc(network, 19, &network->sae_pt_19);
> + network_settings_load_pt_ecc(network, 20, &network->sae_pt_20);
> + }
I suspect you're better off copying all the settings (with the exception of
Security) over to the open settings object instead,
> +
> + return true;
> +}
> +
> void network_sync_settings(struct network *network)
> {
> struct network_info *info = network->info;
> @@ -1966,17 +2033,32 @@ static void network_update_hotspot(struct network *network, void *user_data)
> match_hotspot_network(info, network);
> }
>
> -static void match_known_network(struct station *station, void *user_data)
> +static void match_known_network(struct station *station, void *user_data,
> + bool new)
> {
> struct network_info *info = user_data;
> struct network *network;
>
> if (!info->is_hotspot) {
> + struct l_settings *settings;
> network = station_network_find(station, info->ssid, info->type);
> if (!network)
> return;
>
> - network_set_info(network, info);
> + /* New networks should load settings upon connecting */
> + if (new) {
> + network_set_info(network, info);
> + return;
> + }
Don't you want to update the settings even for the EVENT_ADDED case? Something
like this might happen for example:
- User issues Network.Connect() for an unknown network
- At the same time, the network file is written to /var/lib/iwd
Connect proceeds to win the race, with the EVENT_ADDED event coming in shortly
after. Don't you want any additional settings (say DHCP hostname or whatever)
to be used when the network succeeds in associating?
> +
> + settings = network_info_open_settings(info);
> +
> + if (!settings || !network_settings_update(network, settings)) {
> + l_warn("Failed to apply new/updated settings (%s)",
> + info->ssid);
> + l_settings_free(settings);
> + }
> +
> return;
> }
>
<snip>
> + case KNOWN_NETWORKS_EVENT_UPDATED:
> + station_foreach(update_known_network, (void *) info);
> +
> + /* Syncs frequencies of updated known network */
> + known_network_frequency_sync((struct network_info *)info);
> + break;
Hmm, why do this on the update?
> case KNOWN_NETWORKS_EVENT_REMOVED:
> station_foreach(emit_known_network_removed, (void *) info);
> break;
Regards,
-Denis
next prev parent reply other threads:[~2023-12-15 16:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 18:01 [PATCH 1/5] network: remove 'path' from settings_load_pt_ecc James Prestwood
2023-12-14 18:01 ` [PATCH 2/5] knownnetworks: network: support updating known network settings James Prestwood
2023-12-15 16:37 ` Denis Kenzior [this message]
2023-12-14 18:01 ` [PATCH 3/5] dpp: fix extra settings not being used when connecting James Prestwood
2023-12-14 18:01 ` [PATCH 4/5] auto-t: add DPP tests to check extra settings are applied James Prestwood
2023-12-14 18:01 ` [PATCH 5/5] auto-t: increase RAM when running with valgrind (UML) James Prestwood
2023-12-15 16:28 ` [PATCH 1/5] network: remove 'path' from settings_load_pt_ecc Denis Kenzior
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=e2b80483-8976-454f-8b7d-428bbb63ea89@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).