Comm.protocol Event Loop error 24

Has anyone ever seen this issue before (P1 DeviceOS 2.0.0-rc.1)?

0000044818 [comm.protocol] ERROR: Event loop error 24
0000044833 [app.wfi] WARN: WS_RUN W.rdy=1 IP=0 
0000044938 [system] WARN: Cloud socket connection failed: -230
0000044938 [system] WARN: Internet test failed: DNS
0000044938 [system] WARN: Handling cloud error: 2

Note: "[app.wfi] WARN: WS_RUN W.rdy=1 IP=0 " is from the app. It indicates that WiFi.ready() is returning true but the device IP is 0.0.0.0.

Problem is that WiFi disconnects and we cannot connect again until the device is reset.

Q1. Am wondering if this was a side effect of the Particle cloud issue “Integrations not triggering - 2 October 2020”? (As discussed here: Webhook requests gone)

Q2. Any thoughts on how to remedy (I suppose upon detecting the condition: WiFi.ready() == true but the device IP is 0.0.0.0).

Hi @UMD,
Thanks for your query.
The cause is not related the mentioned outage.
I am checking on your other question.

@particle7888 any progress on what “Event loop error 24” represents?

Hi,I am checking on this and will update you again soon.

Hi @UMD,

We discussed this internally before replying.

This error is:
https://github.com/particle-iot/device-os/blob/develop/communication/inc/protocol_defs.h#L51,
which comes from https://github.com/particle-iot/device-os/blob/3d2588e4c0329ee43c47114a667c90ffe51da86f/communication/src/lightssl_message_channel.cpp#L160

This is an error you’d see when establishing TCP connection to Device Service (so, only on Photon and P1) succeeds, but we fail to receive an initial nonce packet.

The underlying problem most likely comes from the fact mentioned in the thread: WiFi.ready() being true, but there is no IP address. The cause is not 100% certain, ideally we’d want to see a log of what happened before to trigger this. Making a TCP connection without IP address should not work

@particle7888, I was about to start digging into the DeviceOS source code so thanks for the detailed response.

So error is 24 is IO_ERROR_LIGHTSSL_HANDSHAKE_NONCE.

I recall that the WiFi.ready() being true, but no IP address issue is a long standing one.

The outcomeL: “WiFi disconnects and we cannot connect again until the device is reset” is a serious problem IMHO.

I will see if I can reproduce the fault and report back by setting up a dedicated test app.

It would be great if we can sort this one out as it would greatly improve reliability. My guess is that it is caused by a weak WiFi signal.

Just reporting for whomever is interested, have been able to produce “Event loop error 24” at will by running a DeviceOS 2.0.0-rc.1 test application (that just runs the WiFi state machine code)(noting that it is not the app that had the original issue) by simply turning off the access point:

0003684102 [app] TRACE: P.connected() icd=0 bParticleConnect=0 WiFi.ready=1
0003685097 [app] TRACE: P.connected() icd=0 bParticleConnect=0 WiFi.ready=1
0003685176 [comm.protocol] ERROR: Event loop error 24     <======== HERE
0003685176 [system] INFO: Cloud: disconnecting
0003685178 [system] INFO: Cloud: disconnected
0003685278 [system] INFO: Cloud: connecting
0003685295 [system] WARN: Cloud socket connection failed: -230
0003685295 [system] WARN: Internet test failed: DNS
0003685295 [system] WARN: Handling cloud error: 2
0003686096 [app] WARN: WS_RUNNING W.rdy=0 IP=0
0003687096 [app] TRACE: WS_CONNECTING icd=0 W.cncting=1
0003688096 [app] TRACE: WS_CONNECTING icd=0 W.cncting=1

Good news is that performing the said test I have not been able to reproduce the issue of this post: “WiFi disconnects and we cannot connect again until the device is reset”.

Have also tested allocating memory to take up the heap. If I allocate too much (in my case 38,750), I cannot connect to the Access Point at all, below this, can do so with no issue (eg power cycling the access point multiple times).

Am closing this post as solved considering we now know how to reproduce the message and what it means.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.