public inbox for iwd@lists.linux.dev
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: iwd@lists.linux.dev
Cc: James Prestwood <prestwoj@gmail.com>
Subject: [RFC 0/4] Fix extra settings not being taken post-DPP
Date: Wed, 13 Dec 2023 09:25:42 -0800	[thread overview]
Message-ID: <20231213172546.145998-1-prestwoj@gmail.com> (raw)

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.

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
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.

The scan cancelation patch was thrown in there as well. Since we route
through network_autoconnect/__station_connect_network after DPP there
is no canceling logic and this leads to scans failing after DPP
connects. This doesn't "break" anything but the scans should be
canceled prior to a connection.

James Prestwood (4):
  knownnetworks: set ops on info in __network_info_init
  station: unify scan cancelation
  dpp: fix non-scan connect path in DPP
  auto-t: add a few more DPP tests for seen/known networks

 autotests/testDPP/pkex_test.py | 40 ++++++++++++++
 src/dpp.c                      | 89 +++++++++++++++++++++----------
 src/knownnetworks.c            | 32 ++++++------
 src/station.c                  | 96 +++++++++++++++-------------------
 4 files changed, 162 insertions(+), 95 deletions(-)

-- 
2.34.1


             reply	other threads:[~2023-12-13 17:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 17:25 James Prestwood [this message]
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 ` [RFC 0/4] Fix extra settings not being taken post-DPP 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=20231213172546.145998-1-prestwoj@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=iwd@lists.linux.dev \
    /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