search

PelionIoT / mbed-cloud-client

Izuma Device Management Client library
https://izumanetworks.com
Apache License 2.0
43 stars 60 forks source link

Connection issue to portal.mbedcloud.com from STM32F769I-DISC1 board with Pelion example #48

Closed svgeorge closed 5 years ago

svgeorge commented 5 years ago

I am trying to bring up the Pelion example on a STM32F769I-DISC1 board.

I have tried pelion-example-common(https://os.mbed.com/teams/ST/code/pelion-example-common/) and pelion-ready-example (https://os.mbed.com/teams/mbed-os-examples/code/pelion-ready-example/ ) Both of the programs fails to register with portal.mbedcloud.com.

I have followed the the steps correctly from this site. https://os.mbed.com/guides/connect-device-to-pelion/1/?board=ST-Discovery-F769NI

<< serial log >> [BOOT] Mbed Bootloader [BOOT] ARM: 00000000000000000000 [BOOT] OEM: 00000000000000000000 [BOOT] Layout: 0 8009328 [BOOT] Active firmware integrity check: [BOOT] SHA256: 87C10F94E43F5F3BBC6E1CF10E76468103D61A01D65C0482F501F15A69062E2B [BOOT] Version: 1560524045 [BOOT] Slot 0 is empty [BOOT] Active firmware up-to-date [BOOT] Application's start address: 0x8010400 [BOOT] Application's jump address: 0x80110A9 [BOOT] Application's stack address: 0x20080000 [BOOT] Forwarding to application... p@@ Starting Simple Pelion Device Management Client example You can hold the user button during boot to format the storage and change the device identity. Connecting to the network using the default network interface... Connected to the network successfully. IP address: 10.122.16.108 Initializing Pelion Device Management Client... Initialized Pelion Device Management Client. Registering... Press the user button to increment the LwM2M resource value... ADC temp: 23.2234 C, vref: 0.3665 % Button clicked 1 times Button clicked 2 times [SMCC] Error occurred : MbedCloudClient::ConnectNetworkError [SMCC] Error code : 6 [SMCC] Error details : Client in reconnection mode NetworkError

<< above error happens every 30 seconds and no device listed here. https://portal.mbedcloud.com/devices/list What could be the root cause ? My connection credentials as below from the mbed_cloud_dev_credentials.c file .

const char MBED_CLOUD_DEV_BOOTSTRAP_ENDPOINT_NAME[] = "016b5222ff847a6af473872f03c00000"; const char MBED_CLOUD_DEV_ACCOUNT_ID[] = "016b2914a5fc762d28a836d200000000"; const char MBED_CLOUD_DEV_BOOTSTRAP_SERVER_URI[] = "coaps://bootstrap.us-east-1.mbedcloud.com:5684?aid=016b2914a5fc762d28a836d200000000";

I am on corporate network and I able to ping the target. This proves that network stack is alive. vgeorge@CI0700000000653:~$ ping 10.122.16.108 PING 10.122.16.108 (10.122.16.108) 56(84) bytes of data. 64 bytes from 10.122.16.108: icmp_seq=1 ttl=254 time=0.318 ms 64 bytes from 10.122.16.108: icmp_seq=2 ttl=254 time=0.384 ms

Is it possible my corporate policy blocking the port 5684 ?

Any small help to debug this issue is greatly appreciated.

Varughese George

ciarmcom commented 5 years ago

ARM Internal Ref: IOTCLT-3544

teetak01 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

[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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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/

svgeorge commented 5 years ago

this can be closed