Undocumented network_status Events?

Firmware
1

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

16%20AM
16%20AM1372×1000 225 KB

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
2

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

17%20PM
17%20PM1380×482 72.9 KB

3

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
4

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:

55%20PM
55%20PM920×392 20.9 KB

It turns out that these events ARE undocumented:

41%20PM
41%20PM1270×870 92 KB

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

5

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"

6

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
7

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.

8

Try again :wink:

You are shifting by 4.

9

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

10

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

2 Likes
11

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

1 Like
12

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

2 Likes
13

Has just started here :sunglasses: :sunrise:

2 Likes
14

Summary:

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.