Undocumented network_status Events?

I am encountering some odd, seemingly undocumented network_status events when a connection is aborted:

These don’t match anything that should be issued, unless events are being combined in an undocumented way:

From https://github.com/particle-iot/firmware/blob/develop/system/inc/system_event.h :

// Network status. bit 0 is clear if it's a transition state (e.g. powering up, connecting), is set when it's a rest state (connected/ready etc)
network_status_powering_off     = 1<<1 | 0,
network_status_off              = 1<<1 | 1,
network_status_powering_on      = 2<<1 | 0,
network_status_on               = 2<<1 | 1,
network_status_connecting       = 3<<1 | 0,
network_status_connected        = 3<<1 | 1,
// network_status_preparing        = 4<<1 | 0,
// network_status_ready            = 4<<1 | 1,
network_status_disconnecting    = 5<<1 | 0,
network_status_disconnected     = 5<<1 | 1,
1 Like

Here is a more concise capture with the entire event sequence logged:

Yes, noticed these myself too and tried to find them in the system framework. I couldn’t find where the events where defined or emitted. I suspect it is somewhere in the closed sourced WICED stack.

1 Like

FWIW, these events are missing from my trace:

network_status_disconnecting    = 5<<1 | 0,
network_status_disconnected     = 5<<1 | 1,

so I suspect something is getting corrupted but I don’t have enough information/knowledge about it to make that kind of claim.

Something I thought of is that this could be 10 and 11 hex, but it is not. Here is the logger line:

netlog.error("An unknown Network event was triggered (%d)", param);

Hmmm… this makes me think…

Ok I went back and looked and the issue was that I didn’t have those two statuses covered in my switch…case for capturing events. Here is the new trace:

It turns out that these events ARE undocumented:

But the really confusing part is that the numerical values seemingly don’t match the numbers given in the header file.

AFAICT they do match.
You may have considered it already, but 5<<1 and 5<<1 | 1 do actually calculate to 10 & 11 (decimal %d).

5 = 0x05 = 0b00000101 -> <<1 -> 0b00001010 = 0x0A = 10 -> 10 | 1 = 11

So - at least for the log posted in your previous post - …

… they are not missing but only reported as “unknown”

Damn I feel stupid. I have a lot of experience with bit manipulation but somehow I read it as a shift by 5 instead of a shift by 1, so a multiply by 2.

The header file is fine.

1 Like

I did the same, I read 5<<1 as 1<<5 which is 0x10 and 0x11 :slight_smile:

…not used to seeing regular numbers bit-shifted in this way…

Yes, once I added them to the switch statement everything worked reasonably.

I stand by the post title though-- these events are undocumented since I had to go to the source code to find them.

Try again :wink:

You are shifting by 4.

Obviously I meant 0b0.1 << 5…
:clock1: :sleeping_bed:

1<<5 is shifting 1 (irrespective whether you write 1 << 5, 0x01 << 5 or 0b00000001 << 5) five binary places and all of that would end in 0b00100000 = 0x20 = 32


Still wrong. 1<<5 is 32, 0x20. You need more coffee.

1 Like

Yes… guys… I know… It’s been a long day…


Has just started here :sunglasses: :sunrise:



network_status_disconnecting and network_status_disconnected are not documented, so if implementing a network status event handler, be aware that these events should be expected as well.