Skip to content
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

[BUG] onnetwork commissioning doesn't add network to networks list #24684

Closed
pankore opened this issue Jan 27, 2023 · 3 comments
Closed

[BUG] onnetwork commissioning doesn't add network to networks list #24684

pankore opened this issue Jan 27, 2023 · 3 comments

Comments

@pankore
Copy link
Contributor

pankore commented Jan 27, 2023

Reproduction steps

Connect wifi device to the same wifi network as the commissioner beforehand
Commission the device using onnetwork pairing
./chip-tool pairing onnetwork 1 20202021
Read the networks list, it should show 0 entries
./chip-tool networkcommissioning read networks 1 0

  • Controller/commissioner has no way to get the wifi password
  • AddOrUpdateWiFiNetwork is not called
  • The wifi network is not added to the networks list, this also results in CommitConfiguration storing an empty mStagingNetwork and the wifi is not persisted in kvs for Ameba platform

Is this an expected behaviour? Should platform code implement adding the network or should it be the controller's job? If it is controller's job, how would the wifi password be known to the controller?

Bug prevalence

always

GitHub hash of the SDK that was being used

bdefbcb

Platform

ameba, other

Platform Version(s)

No response

Anything else?

No response

@bzbarsky-apple
Copy link
Contributor

If a device is placed on the network through non-Matter means, then either the network should not appear in the networks list, or whatever did the placing on the network should explicitly add the network there.

The first of those is argued for by this part of the spec:

The order of list items SHALL only be modified by the AddOrUpdateThreadNetwork, AddOrUpdateWiFiNetwork and ReorderNetwork commands. In other words, the list SHALL be stable over time, unless mutated externally.

but the spec does have provisions for the Ethernet version of the network commissioning cluster to automatically populate the list with the one entry....

So really, this needs to be raised as a spec issue to clarify behavior.

@ksperling-apple
Copy link
Contributor

ksperling-apple commented Jan 27, 2023

To my reading that spec paragraph simply talks about the fact that the list order reflects configuration precedence and doesn't change by itself (e.g. when the primary network is unavailable and the device falls back to the secondary network).

@pankore
Copy link
Contributor Author

pankore commented Feb 16, 2023

closing issue, onnetwork devices should not have network commissioning cluster

@pankore pankore closed this as completed Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants