Nanostack network handle does not always call status cb for BOOTSTRAP events #10434
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
UBLOX_EVK_ODIN_W2 advertises more events than we expect.
When disconnecting, first the network connectivity is lost (Nanostack receives MESH_BOOTSTRAP_STARTED and advertises CONNECTING) and only then does an actual disconnection event arrive (DISCONNECT).
The intermittent CONNECTING phase makes little sense to me after we call
net->disconnect()
, but actually LWIP interface receives the very same event and simply prevents it from being advertised. I also assume it is the wrapper's responsibility to advertise events according to our spec, regardless of how the underlying driver behaves. I decided to fix it myself, but I admit I am not 100% sure if this should not be raised with the Ublox team...When reconnecting, MESH_BOOTSTRAP_START_FAILED shows up, but the board eventually manages to connect. If the bootstrap failed, then it is good that the driver advertises this. Our network status flow just doesn't consider this interesting enough to be advertised with the user's callback. Again - LWIP Interface is getting the exact same event and does not call the callback either.
I did not see the network-interface tests failing for any other hardware than Ublox WiFi (UBLOX Ethernet, K64F Ethernet, AT86RF233, MCR20A) but I still think the wrapper should take care of the extra events.
Pull request type
Reviewers
@SeppoTakalo
@VeijoPesonen
@KariHaapalehto
@kjbracey-arm