Connection issue to portal.mbedcloud.com from STM32F769I-DISC1 board with Pelion example about mbed-cloud-client

[svgeorge]

The issue root caused to corporate network blocking the communication.
I am able to resolve by creating a access point using raspberryPI.
Did the installations mentioned here. Just switched the configurations for eth0 and wlan0.
You need the wlan0 to act as your Internet connection, and eth0 to act as the access connection
(which is the opposite of what's here). You can ignore step 5 and step 8.

https://thepi.io/how-to-use-your-raspberry-pi-as-a-wireless-access-point/

[ciarmcom]

ARM Internal Ref: IOTCLT-3544

[teetak01]

Hi @svgeorge, it is possible that 5684 is blocked by your company.

If you can enable some debug-tracing by setting "mbed-trace.enable": 1 it could give a bit more information what is causing the NetworkError. (https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/mbed_app.json#L21)

Can you confirm what network connectivity you are using with the board? It it is Wi-Fi, then using a mobile phone as access point (instead of corporate wlan), might give more unrestricted access.

[svgeorge]

Hello Teemu: Your conclusion is correct. I have used home network and application registered with mbed server. The board I am using donn't have any wi-fi. I am using Ethernet connection. Any work around I could implement to listen on another port?
Thanks
Varughese

[teetak01]

Client is listening to random port number so that should not be a problem. Client is trying to connect to 5684, so can it be a problem that outbound connection is also blocked?

You can fix the client-side port via configuration: https://github.com/ARMmbed/mbed-cloud-client/blob/4f4a8463dd06160844fe430192741a678cd34183/mbed-cloud-client/MbedCloudClientConfig.h#L113

[svgeorge]

The port 5684 is Ok from my desktop. I will change the client configuration and try it again.
const char MBED_CLOUD_DEV_BOOTSTRAP_SERVER_URI[] = "coaps://bootstrap.us-east-1.mbedcloud.com:5684?aid=016b2914a5fc762d28a836d200000000";
~$ nc -vz bootstrap.us-east-1.mbedcloud.com 5684
Connection to bootstrap.us-east-1.mbedcloud.com 5684 port [tcp/] succeeded!
~$nc -vuz bootstrap.us-east-1.mbedcloud.com 5684
Connection to bootstrap.us-east-1.mbedcloud.com 5684 port [udp/] succeeded!

[svgeorge]

I have enabled the trace logs and the following trace obtained.

Connect Failed due to
PAL_ERR_TLS_WANT_READ --> MBEDTLS_ERR_SSL_WANT_READ --> PAL_ERR_SOCKET_WOULD_BLOCK --> NSAPI_ERROR_WOULD_BLOCK

So the root error is NSAPI_ERROR_WOULD_BLOCK which set when recvfrom() call returns -1

***** trace ****
[DBG ][mClt]: M2MConnectionHandlerPimpl::receive_handshake_handler()

[DBG ][mClt]: M2MConnectionSecurityPimpl::connect

[DBG ][mClt]: M2MConnectionSecurityPimpl::start_handshake

[ERR ][PAL ]: PAL_ERR_SOCKET_WOULD_BLOCK status set due to NSAPI_ERROR_WOULD_BLOCK

[ERR ][PAL ]: MBEDTLS_ERR_SSL_WANT_READ status set due to PAL_ERR_SOCKET_WOULD_BLOCK

[DBG ][mClt]: M2MConnectionSecurityPimpl::start_handshake - handshake ret: 0XFFF00005

[DBG ][mClt]: M2MConnectionSecurityPimpl::start_handshake - PAL_ERR_TLS_WANT_READ ret: 0XFFF00005

[DBG ][mClt]: M2MConnectionSecurityPimpl::connect - handshake ret: -2

*** trace end ***

*** testing of the port ***
const char MBED_CLOUD_DEV_BOOTSTRAP_SERVER_URI[] = "coaps://bootstrap.us-east-1.mbedcloud.com:5684?aid=016b2914a5fc762d28a836d200000000";
~$ nc -vz bootstrap.us-east-1.mbedcloud.com 5684
Connection to bootstrap.us-east-1.mbedcloud.com 5684 port [tcp/] succeeded!
~$nc -vuz bootstrap.us-east-1.mbedcloud.com 5684
Connection to bootstrap.us-east-1.mbedcloud.com 5684 port [udp/] succeeded!

As mentioned before, the same program works fine using home network.
The issue shows only with corporate network. I don’t have wi-fi support on my board to use hotspot.

setting #define MBED_CLOUD_CLIENT_LISTEN_PORT 1 had no impact.

any chance this could be related to some time parameters?

[lauri-piikivi]

It seems like a company firewall issue. It may block the connections. Note that when you run nc with -z parameter, it does not really do anything on UDP. Are you using UDP or TCP? On TCP it creates a socket, but as there is no actual data transfer, the firewall may not act on it. I suggest to run without the -z.
It should be verified from IT what kind of firewall and proteins is done, if we can solve it in the networking stack.

[teetak01]

@svgeorge note that with MBED_CLOUD_CLIENT_LISTEN_PORT you define the number of the LISTEN port to something fixed.
0 => not defined, client will randomize it for you.

0 client will use that port number. (So its not boolean, 1 => use port number 1).

Generally you should not need to touch this parameter, even if connecting from behind a firewall.

[svgeorge]

this can be closed