fix(wifi): prevent stale WiFi settings from being applied after Skip#1540
Conversation
4fc34af to
42aa9e0
Compare
|
Thanks for the PR, @4RH1T3CT0R7 I think this is probably inverted, though? Shouldn't we just fix the customisation generator to actually honour the |
Move the wifiConfigured check from QML-side filtering into the C++ customisation generator itself. All three generation paths (systemd script, cloud-init user-data, cloud-init network-config) now read the wifiConfigured flag and return empty WiFi fields when false. This prevents stale persisted WiFi settings from earlier sessions being applied when the user skips WiFi configuration. Defaults to true for backward compatibility. Fixes: raspberrypi#1326
42aa9e0 to
c897862
Compare
|
Good point, the generator should honour the flag directly rather than filtering state in QML Reworked: the The QML side now just passes |
When a user previously configured WiFi and later skips customization (e.g. for an ETH0-only headless build), the WiFi settings from the previous session were silently applied to the image
customizationSettingsis loaded from persistent storage (QSettings) at app startup. When the user clicks "Skip" on any customization step, the runtime flags (wifiConfigured = false) are cleared but the WiFi keys (wifiSSID,wifiPasswordCrypt,wifiHidden) remain incustomizationSettings. The customization generator checkswifiSSIDdirectly - not thewifiConfiguredflag - so it applies the stale WiFi configThis is the same class of bug as #1520 (USB Gadget Mode persistence)
Fix
Before calling
applyCustomisationFromSettings(), strip WiFi keys fromcustomizationSettingswhenwifiConfiguredisfalse. This is done centrally inWizardContainer.qmlat the writing step entry point, covering all Skip pathsCloses #1326