-
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:810180] [1/5] network: remove 'path' from settings_load_pt_ecc #284
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.
The path argument was used purely for debugging. It can be just as informational printing just the SSID of the profile that failed to parse the setting without requiring callers allocate a string to call the function.
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.
After DPP completes all settings are written and synced to disk as well as credentials set into the network object itself. The way network/knownnetworks worked at the time did not actually re-load these settings before the connection attempt was made which means that extra settings not set into the network object were not used, i.e. Hidden/Sendhostname. The connection itself always succeeded because the network object was given the credentials directly via setters. Now network and knownnetworks support updating on the directory watch callback and ADDED/UPDATED known network events. Take advantage of this and if the network object already exists after DPP (from a prior scan) wait unil known networks adds/updates the network and issue the connection after that.
In order to test that extra settings are applied prior to connecting two tests were added for hidden networks as well as one testing if there is already an existing profile after DPP. The reason hidden networks were used was due to the requirement of the "Hidden" settings in the profile. If this setting doesn't get sync'ed to disk the connection will fail.
This was done for QEMU but not for UML. Running more than a few tests with --valgrind will generally thrown an OOM error pretty quick.
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
a93a17f
to
68c71d2
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
68d5156
to
953fb5e
Compare
The path argument was used purely for debugging. It can be just as
informational printing just the SSID of the profile that failed to
parse the setting without requiring callers allocate a string to
call the function.
src/network.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)