-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PW_SID:809766] Fix extra settings not being taken post-DPP #282
base: workflow
Are you sure you want to change the base?
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
This function was only used by hotspot as a backdoor to initializing a network info object. For the hotspot case it has its own ops structure which is set after calling. DPP now will need a way to create/update a known network from a receieved configuration but it only needs the default ops structure from known networks. Set this automatically within this function. This won't pose an issue to hotspot as it will just overwrite the ops pointer to its own implementation.
The scan cancelation was all being done manually so group all the automatic-type scans into a single cancel function. This includes hidden, quick, owe, and periodic scans. This is being done in order to avoid scan failures after DPP initiates a connection. This is ultimately done through __station_connect_network which has no cancelation logic. This patch will move the scan cancelation into station_enter_state when the state changes to CONNECTING. All the mentioned scans will be canceled at that point. DBus scans were left out intentionally as they are an explicit type of scan rather than one that IWD starts on its own.
When DPP completes it writes the network configuration to disk but these changes aren't picked up by the network object until the known networks dir watch. Currently the connection itself works fine because the network object holds a copy of the passphrase/psk but additional settings like Hidden/SendHostname are not updated and not used for the connection through DPP. In theory DPP could also watch for known networks events and wait until the expected network is added but that is also fragile since its not guaranteed that the DPP watch callback will happen _after_ the one in network (when the network_info) is set into the object. Instead, DPP itself can handle the known network creation/update itself. If a known network already exists update its config. Otherwise create a new network_info object and set it into the network object.
These ensure DPP works correctly when a network has already been seen in the scan results as well as if its a known network.
Fetch PR Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches |
Fetch PR GitLint Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Autotest Runner Output:
Clang Build |
a6b078e
to
1c88fa1
Compare
d7c5f62
to
2526ce4
Compare
c08a6fa
to
1106532
Compare
66ab708
to
4f2c8df
Compare
9eef0d5
to
d3b4175
Compare
68c71d2
to
43f4327
Compare
4170bb4
to
c067bc7
Compare
f10f2fc
to
c2be9ec
Compare
ebbbc93
to
089fa9a
Compare
2192e98
to
43a07cc
Compare
2c7b52e
to
58d64d4
Compare
f7c5ee3
to
38fe7c3
Compare
This function was only used by hotspot as a backdoor to initializing
a network info object. For the hotspot case it has its own ops
structure which is set after calling.
DPP now will need a way to create/update a known network from a
receieved configuration but it only needs the default ops structure
from known networks. Set this automatically within this function.
This won't pose an issue to hotspot as it will just overwrite the
ops pointer to its own implementation.
src/knownnetworks.c | 32 +++++++++++++++++---------------
1 file changed, 17 insertions(+), 15 deletions(-)