| Message ID | 20231113182800.344348-1-prestwoj@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | RFC: Support full profile sharing via DPP 3rd party attributes | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/pre-ci_am | success | Success |
| prestwoj/iwd-alpine-ci-fetch | success | Fetch PR |
| prestwoj/iwd-ci-gitlint | success | GitLint |
| prestwoj/iwd-ci-fetch | success | Fetch PR |
| prestwoj/iwd-ci-makedistcheck | success | Make Distcheck |
| prestwoj/iwd-ci-incremental_build | success | Incremental build not run PASS |
| prestwoj/iwd-alpine-ci-makedistcheck | success | Make Distcheck |
| prestwoj/iwd-alpine-ci-incremental_build | success | Incremental build not run PASS |
| prestwoj/iwd-ci-build | success | Build - Configure |
| prestwoj/iwd-alpine-ci-build | success | Build - Configure |
| prestwoj/iwd-ci-makecheckvalgrind | success | Make Check w/Valgrind |
| prestwoj/iwd-ci-makecheck | success | Make Check |
| prestwoj/iwd-ci-clang | success | clang PASS |
| prestwoj/iwd-alpine-ci-makecheckvalgrind | success | Make Check w/Valgrind |
| prestwoj/iwd-alpine-ci-makecheck | success | Make Check |
| prestwoj/iwd-ci-testrunner | success | test-runner PASS |
Hi James, On 11/13/23 12:28, James Prestwood wrote: > If an IWD profile contains network-specific settings which are > required to utilize the network correctly configuring via DPP > will not carry over those settings to the enrollee. The DPP > configuration object only contains the SSID/PSK to connect and > anything else set in the configurators profile is not included. > > This is likely something that the majority of users will not > need (most networks don't need additional settings) but if the > network does it would be convenient for the configurator to send > over its exact configuration to the enrollee. This is useful for > an automated use case where a configuration should be consistent > across all devices. > > DPP allows for arbitrary 3rd party attributes in the configuration > object (section 4.5.2) which can be used to communicate additional > settings. > > The plan is to define a new object within the overall > configuration object who's keys are IWD profile groups and values > are objects containing settings for those groups: > > { > "ssid": "my_ssid", > ... main configuration object ... > > ... The IWD profile, converted to JSON ... > "/net/connman/iwd": { > "Network": { > "MutlicastDNS": "true" > }, > "IPv4": { > "SendHostname": "true" > }, > ... etc ... > } > } > > The "/net/connman/iwd" object could then be parsed by the enrollee > (potentially if the feature is enable in main.conf?) and set to > the profile as it is now with the passphrase/psk. > > Several profile values don't apply here like MAC/IP address > overrides. Mainly the settings that do matter would be: > > [IPv4].SendHostname Yeah I can see this one since this might be a network-wide DHCP server quirk... > [Network].MulticastDNS But why would you want this one? > [Settings] (most values here, except AddressOverride) What settings do you want from here besides Hidden? Transition disable settings would be automagically restored as soon as the transition network is connected to. You may want to drop the IPv4/Network hierarchy and make these more generic. Regards, -Denis
Hi Denis, On 11/16/23 07:29, Denis Kenzior wrote: > Hi James, > > On 11/13/23 12:28, James Prestwood wrote: >> If an IWD profile contains network-specific settings which are >> required to utilize the network correctly configuring via DPP >> will not carry over those settings to the enrollee. The DPP >> configuration object only contains the SSID/PSK to connect and >> anything else set in the configurators profile is not included. >> >> This is likely something that the majority of users will not >> need (most networks don't need additional settings) but if the >> network does it would be convenient for the configurator to send >> over its exact configuration to the enrollee. This is useful for >> an automated use case where a configuration should be consistent >> across all devices. >> >> DPP allows for arbitrary 3rd party attributes in the configuration >> object (section 4.5.2) which can be used to communicate additional >> settings. >> >> The plan is to define a new object within the overall >> configuration object who's keys are IWD profile groups and values >> are objects containing settings for those groups: >> >> { >> "ssid": "my_ssid", >> ... main configuration object ... >> >> ... The IWD profile, converted to JSON ... >> "/net/connman/iwd": { >> "Network": { >> "MutlicastDNS": "true" >> }, >> "IPv4": { >> "SendHostname": "true" >> }, >> ... etc ... >> } >> } >> >> The "/net/connman/iwd" object could then be parsed by the enrollee >> (potentially if the feature is enable in main.conf?) and set to >> the profile as it is now with the passphrase/psk. >> >> Several profile values don't apply here like MAC/IP address >> overrides. Mainly the settings that do matter would be: >> >> [IPv4].SendHostname > > Yeah I can see this one since this might be a network-wide DHCP server > quirk... To be completely honest SendHostname is all I actually needed. I was trying to make it more generic and allow any setting but it certainly simplifies the implementation if we just pick individual settings we want. Thanks, James
diff --git a/src/iwd.network.rst b/src/iwd.network.rst index 719853fa..8f4e54f9 100644 --- a/src/iwd.network.rst +++ b/src/iwd.network.rst @@ -440,6 +440,25 @@ network configuration. value obtained from the DHCPv6 server or via Router Advertisements. +The group ``[DeviceProvisioning]`` contains settings for device provisioning +credential sharing. + +.. list-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 20 80 + :align: left + + * - ShareFullConfig + - Values: true, **false** + + When configuring an enrollee, include all additional network profile + settings except those that are device specific (e.g. MAC/IP address + overrides). This uses 3rd party attributes in the DPP configuration + response and will only be compatible with IWD-based enrollees that can + parse those attributes. + + Embedded PEMs -------------
If an IWD profile contains network-specific settings which are required to utilize the network correctly configuring via DPP will not carry over those settings to the enrollee. The DPP configuration object only contains the SSID/PSK to connect and anything else set in the configurators profile is not included. This is likely something that the majority of users will not need (most networks don't need additional settings) but if the network does it would be convenient for the configurator to send over its exact configuration to the enrollee. This is useful for an automated use case where a configuration should be consistent across all devices. DPP allows for arbitrary 3rd party attributes in the configuration object (section 4.5.2) which can be used to communicate additional settings. The plan is to define a new object within the overall configuration object who's keys are IWD profile groups and values are objects containing settings for those groups: { "ssid": "my_ssid", ... main configuration object ... ... The IWD profile, converted to JSON ... "/net/connman/iwd": { "Network": { "MutlicastDNS": "true" }, "IPv4": { "SendHostname": "true" }, ... etc ... } } The "/net/connman/iwd" object could then be parsed by the enrollee (potentially if the feature is enable in main.conf?) and set to the profile as it is now with the passphrase/psk. Several profile values don't apply here like MAC/IP address overrides. Mainly the settings that do matter would be: [IPv4].SendHostname [Network].MulticastDNS [Settings] (most values here, except AddressOverride) The other IPv4/v6 settings likely aren't useful since they pertain mostly to static configurations and are obtained from DHCP. The [Security] group would be omitted entirely since its already set by the main configuration and contains generated values like SAE-PT-Group's. --- src/iwd.network.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)