Google Geolocation Request Results in Disconnection from Particle Cloud

Firmware
1

Hi Particle community,

I am dealing with an issue with the Particle Argon (cloud connected), everytime I try to use the google geolocation call - the Particle Argon is kicked off the Particle Cloud?

Running the Logger, I get the following output. It appears that the DNS server list changed and mbed ttls error occur.

How do I approach correcting the mbed_ttls error and stop the Particle from disconnecting?

Look forward to hearing back - thank you.
slab

publishLocation (Request Geolocation from Google)
scanData={"w":{"a":[{"m":"90:09:d0:37:d9:b4","s":-26,"c":1},{"m":"a6:09:d0:37:d9:b4","s":-30,"c":1},{"m":"3c:ce:73:f7:bb:c0","s":-60,"c":11},{"m":"3c:ce:73:f7:bb:c2","s":-60,"c":11},{"m":"3c:ce:73:f7:bb:c1","s":-60,"c":11},{"m":"3c:ce:73:c6:5d:12","s":-68,"c":6
publishLocation
0000114434 [net.ifapi] INFO: Netif wl3 link DOWN, profile=NONE
0000114435 [system.nm] INFO: State changed: IP_CONFIGURED -> IFACE_LINK_UP
0000114435 [hal] INFO: DNS server list changed
0000114436 [hal] INFO: DNS server list changed
0000114440 [system.nm] INFO: State changed: IFACE_LINK_UP -> IFACE_UP
0000114441 [comm] INFO: Forcing a cloud ping
0000114441 [system] ERROR: sock_send returned -1 118
0000114442 [comm.dtls] ERROR: mbedtls_ssl_write() failed: -0x4e
0000114442 [system] ERROR: sock_send returned -1 118
0000114443 [comm.dtls] ERROR: mbedtls_ssl_read() failed: -0x4e
0000114443 [comm.protocol] ERROR: Event loop error 34
0000114444 [system] WARN: Communication loop error, closing cloud socket
0000114444 [system] INFO: Cloud: disconnecting
0000114445 [system] INFO: Cloud: disconnected

scanData={"w":{"a":[{"m":"90:09:d0:37:d9:b4","s":-25,"c":1},{"m":"a6:09:d0:37:d9:b4","s":-29,"c":1},{"m":"3c:ce:73:f7:bb:c4","s":-62,"c":11},{"m":"3c:ce:73:f7:bb:c2","s":-62,"c":11},{"m":"3c:ce:73:f7:bb:c3","s":-62,"c":11},{"m":"70:10:5c:f9:36:40","s":-68,"c":6

0000118763 [ncp.esp32.mux] INFO: Mux channel 2 already opened
0000138251 [ncp.esp32.mux] INFO: Mux channel 2 already opened
0000141101 [net.ifapi] INFO: Netif wl3 link UP, profile=anomalous
0000141105 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP
0000141147 [hal] INFO: DNS server list changed
0000141149 [system.nm] INFO: State changed: IFACE_LINK_UP -> IP_CONFIGURED
0000141149 [system] INFO: Cloud: connecting
0000141152 [system] INFO: Read Server Address = type:1,domain:$id.udp.particle.io
0000141154 [system] INFO: Loaded cloud server address and port from session data
0000141156 [system] INFO: Cloud socket=0, connecting to 34.231.252.59#5684
0000141158 [system] INFO: Cloud socket connected
0000141158 [system] INFO: Starting handshake: presense_announce=0
0000141158 [comm.protocol.handshake] INFO: Establish secure connection
0000141166 [comm.dtls] INFO: session has 0 uses
0000141184 [comm.dtls] INFO: (CMPL,RENEG,NO_SESS,ERR) restoreStatus=0
0000141186 [comm.dtls] INFO: out_ctr 0,1,0,0,0,0,0,109, next_coap_id=55
0000141186 [comm.dtls] INFO: restored session from persisted session data. next_msg_id=85
0000141188 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 2
0000141562 [comm.protocol.handshake] INFO: Skipping HELLO message
0000141565 [system] INFO: cloud connected from existing session.
0000141569 [system] INFO: Sending application DESCRIBE
0000141570 [comm.protocol] INFO: Checksum has not changed; not sending application DESCRIBE
0000141571 [system] INFO: Sending subscriptions
0000141572 [comm.protocol] INFO: Checksum has not changed; not sending subscriptions
0000141605 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000141713 [system] INFO: All handshake messages have been processed
0000141812 [system] INFO: Cloud connected

2

What happened before the beginning of the log starts (the first scanData)?

The second one will definitely fail because you're not cloud connected yet. You should only do the location publish when Particle.connected() returns true.

3

Hi rickkas,

The Particle Argon connects promptly to the Particle Cloud upon startup (pulsing cyan).

For clarity: I successfully publish data to the Particle Cloud. When I want to get geolocation data when locator.publishLocation() called the Argon drops the Particle cloud connection and the mbed_ttls errors appears.

At the point where this block is executed:
/* EVENT WHICH INDUCES A GOOGLE GEOLOCATION REQUEST /
if( digitalRead(B_TN) == LOW ) {
/ REQUEST LOCATION FROM GOOGLE */
locator.publishLocation();
delay(1000);
}

This call locator.publishLocation() produces:
scanData={"w":{"a":[{"m":"90:09:d0:37:d9:b4","s":-23,"c":1},{"m":"a6:09:d0:37:d9:b4","s":-25,"c":1},{"m":"b2:f7:5b:03:46:c3","s":-48,"c":6},{"m":"70:10:5c:f9:36:41","s":-68,"c":6},{"m":"3c:ce:73:f7:bb:c4","s":-68,"c":11},{"m":"70:10:5c:f9:36:40","s":-69,"c":6}]}}

And then promptly the Particle Argon disconnects from the Particle Cloud.

4

Are you calling locator.publish location from the main loop thread, or somewhere else?

And what version of Device OS?

5

Argon V6.1.1 and called in the void loop() { }. Started the project from scratch, still got the same issue - changed Argon. Problem persists, not clear to me on how to proceed.

Thank you rickkas.

6

I was unable to reproduce this problem with an Argon and Device OS 6.1.1. I updated the library to version 0.0.8 with some more debugging; you should run it with

SerialLogHandler logHandler(LOG_LEVEL_TRACE);

to get additional messages. I also added another example using a button to trigger and that worked as well.

7

Hi Rickkas,

Thank you for all your assistance in attempting to resolve the Particle Cloud issue, I accessed the updated library and deployed the straight forward examples. Sadly, the problem persists and I am now convinced that it must be the university's firewall is disrupting / inciting the breakdown of the Particle Cloud connection.

I will continue to source a solution.

Thank you
slab

p.s. if you are curious about TRACE DUMP, I can pack it and send it over

8

A firewall can cause that behavior. On the Argon, the default keepalive is 25 seconds, but two things can cause the cloud connection to fail in the way you've described:

  • The keep-alive is actually shorter than 25 seconds
  • The firewall has a fixed lifetime for the return port, and the keep-alive is not actually keeping the connection alive

The issue is that the Argon uses UDP to send to the cloud. When a device using UDP sends off the LAN, the firewall will create a temporary return port mapping to allow the return packet. These are periodically cleaned up by the firewall, but the keep-alive should prevent that from occurring before the Particle device is done with the cloud connection.

The reason it looks like the publish is breaking the cloud connection is that the device does not know that the return port has been deleted until it tries to send data.

9

Hi rickkas,

I have made a request to the IT Firewall / Network admins at the university to accommodate our network access requirements. Thank you again!

Best,
slabn