https_client sample:

[Triffid_Hunter]

Hi,

I'm trying to run the https_client sample on an nrf9160dk, and it's giving me the following output:

*** Booting Zephyr OS build v2.3.0-rc1-ncs1-1440-g"020" !$#a 1  ***
Flash regions           Domain          Permissions
00 00 0x00000 0x08000   Secure          rwxl
01 31 0x08000 0x100000  Non-Secure      rwxl

Non-secure callable region 0 placed in flash region 0 with size 32.

SRAM region             Domain          Permissions
00 07 0x00000 0x10000   Secure          rwxl
08 31 0x10000 0x40000   Non-Secure      rwxl

Peripheral              Domain          Status
00 NRF_P0               Non-Secure      OK
01 NRF_CLOCK            Non-Secure      OK
02 NRF_RTC0             Non-Secure      OK
03 NRF_RTC1             Non-Secure      OK
04 NRF_NVMC             Non-Secure      OK
05 NRF_UARTE1           Non-Secure      OK
06 NRF_UARTE2           Secure          SKIP
07 NRF_TWIM2            Non-Secure      OK
08 NRF_SPIM3            Non-Secure      OK
09 NRF_TIMER0           Non-Secure      OK
10 NRF_TIMER1           Non-Secure      OK
11 NRF_TIMER2           Non-Secure      OK
12 NRF_SAADC            Non-Secure      OK
13 NRF_PWM0             Non-Secure      OK
14 NRF_PWM1             Non-Secure      OK
15 NRF_PWM2             Non-Secure      OK
16 NRF_PWM3             Non-Secure      OK
17 NRF_WDT              Non-Secure      OK
18 NRF_IPC              Non-Secure      OK
19 NRF_VMC              Non-Secure      OK
20 NRF_FPU              Non-Secure      OK
21 NRF_EGU1             Non-Secure      OK
22 NRF_EGU2             Non-Secure      OK
23 NRF_DPPIC            Non-Secure      OK
24 NRF_GPIOTE1          Non-Secure      OK
25 NRF_REGULATORS       Non-Secure      OK

SPM: NS image at 0xc000
SPM: NS MSP at 0x20027028
SPM: NS reset vector at 0xea69
SPM: prepare to jump to Non-Secure image.
*** Booting Zephyr OS build v2.3.0-rc1-ncs1-1451-gb160c8c5caa5  ***
HTTPS client sample started
[00:00:00.008,209] <err> at_cmd: Failed to send AT command (err:9)
[00:00:00.008,270] <err> lte_lc: Could not send AT command, error: -9
[00:00:00.008,270] <err> lte_lc: Could not set system mode, error: -9
Provisioning certificate
Waiting for network..[00:10:00.575,469] <inf> lte_lc: Network connection attempt timed out
[00:10:00.597,229] <inf> lte_lc: Using fallback network mode
OK
Connecting to translate.google.cn
connect() failed, err: 45

error 9 is, as far as I can tell, EBADF bad file descriptor - does that seem right? Is there a better list for error codes than nrfxlib/bsdlib/include/nrf_errno.h?

error 45 seems to be related to certificates from searching these forums, but I already noticed that the example certificate didn't match and grabbed an updated one directly from the domain - apparently to no avail.

I've added

CONFIG_SERIAL=y
CONFIG_UART_CONSOLE_LOG_LEVEL_DBG=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y

CONFIG_AT_HOST_LIBRARY=y
CONFIG_UART_INTERRUPT_DRIVEN=y

to the prj.conf so I could access the debug log and try to poke the modem with LTE link monitor, are some of those flags somehow incompatible with the https_client sample?

I couldn't find any documentation about config flag incompatibilities.

Is there any way to get more verbose error logging about what's happening?

If I connect LTE Link monitor after the "fallback network mode" message, it sometimes indicates that LTE is connected, however if I connect it before that message, it never shows LTE as connected - is it unable to discern the transition between not connected and connected, or is this 'connected' indication a false positive?

I searched for similar posts, but couldn't find anything mentioning an error 9 or -9.

Fwiw, I'm using the sim card that a Nordic FAE provided with my nrf9160-DK and said should work fine.

My phone is on the same LTE network and same table, and shows a signal strength of -104dBm / 36 ASU which it seems quite happy with.

PS: LTE Link Monitor seems to eat 100% CPU while connected to the serial port, is that normal? strace says it's continually hammering epoll_wait with zero timeout and there's a couple of threads throwing futexes back and forth as fast as they can.

[Heidi]

Hi!

We don't support SNI yet, so you can't connect with hostname verification enabled. So when setting up TLS peer verification in main.c, make sure verify is NONE and not REQUIRED. 

As for the AT command issues, just follow Martin's recommendation to you in this ticket.

[Triffid_Hunter]

You're saying that https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/https_client/src/main.c#L122 is unsupported and causing the error I'm seeing?

Since that line has been unaltered since the https_client sample was first committed, does that mean that the https_client sample has never worked for anyone without modification?

[Heidi]

No, I suppose it hasn't worked for anyone connecting to a hostname that has numerous hostnames with the same IP. 

[Triffid_Hunter]

Setting verify = NONE does seem to allow it to connect, but does this mean that it'll happily send data to any server that offers a https certificate signed by the provided CA even if it's the wrong host?

What precisely is being verified by this verify setting?

I tried using openssl s_client -noservername -connect www.baidu.cn:443 --showcerts and it printed out the same certificate, so apparently this host doesn't require SNI.

I also tried against a server I control which doesn't support SNI and only has a single certificate, and it also gave me error 45 with verify = REQUIRE, so apparently SNI isn't the problem here.

[Heidi]

Hi, so SNI support will be present in MFW 1.2.1, and its release is right around the corner. 

However, I had some colleagues take a look at your case, and you might be correct in that SNI isn't the problem. It seems that  www.baidu.cn  and baidu.cn by different CA entities, with different entries in the CN andsubjectAltName field. You could try to add/remove www and see what happens (adding www worked in our testing with GlobalSign CA). 

We're not sure what's going on, and to get a complete picture we would need to know which hostname you're using, which certificates are being used and a modem trace. 

[Triffid_Hunter]

I've found some further info :-

Apparently the modem will only accept the top-level root certificate, it doesn't seem to like intermediate certificates at all.
Is this documented somewhere?

With the certificates fixed, error 45 seems to remain as a random transient error - out of 15 tests I had 5 failures with error 45 and 10 successes (in no particular order) with only nrfjprog -r between each run.
I had similar results in an area with -85dB of signal (according to my phone) rather than the -104dB reported at my desk, and connecting to LTE seems to mostly succeed in ~15s, so apparently it's not an LTE signal strength issue.
(with a code snippet modified from https://devzone.nordicsemi.com/f/nordic-q-a/49966/reading-signal-strength-in-firmware-nrf91/199273#199273 the 9160dk reports slightly better signal than my phone)

If I try to re-connect after a connection failure without resetting (ie do { err = connect(...) } while (err);), the connect() call fails instantly with error 45.
getaddrinfo() also seems to fail instantly if re-called in the same fashion.
How much of the networking library needs to be reinitialized after a connect() failure for me to be able to retry the connection?
Is that documented somewhere?
Is this a bug in bsdlib, since connect() doesn't invalidate the socket on other POSIX systems, and man connect explicitly states that connect() can be re-run on an existing socket?
Should I make a separate thread about this?

Log:

[Wed Aug 26 19:03:21 2020] *** Booting Zephyr OS build v2.3.0-rc1-ncs1-1451-gb160c8c5caa5 ***
[Wed Aug 26 19:03:21 2020] HTTPS client sample started
[Wed Aug 26 19:03:22 2020] Provisioning certificate..
[Wed Aug 26 19:03:22 2020] Provisioned
[Wed Aug 26 19:03:22 2020] Waiting for network...
[Wed Aug 26 19:03:37 2020] Connected
[Wed Aug 26 19:03:37 2020] RSSI: -101 dBm
[Wed Aug 26 19:03:37 2020] Looking up www.baidu.com
[Wed Aug 26 19:03:39 2020] Connecting to www.baidu.com
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 22
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45
[Wed Aug 26 19:06:25 2020] connect() failed, err -1 errno 45

I will investigate how to capture a modem trace and get back to you with that.

PS: connect() seems to take 1-3 minutes, is there any way to speed that up, or at least profile which stages of the connect process are taking most of the time?

[Heidi]

Hi, 

It's a bit tricky to interpret what you mean by the modem not liking the intermediate certificate. Are you not able to provision it, or did it fail when connect() was called? 

 

Regarding reinitialization before calling connect() again, this is what's stated by man pages.

If connect() fails, consider the state of the socket as unspecified. Portable  applications
should close the socket and create a new one for reconnecting.

So just call close() on the socket and then re-open a new one before attempting to connect again.

Triffid_Hunter said:

I will investigate how to capture a modem trace and get back to you with that.

PS: connect() seems to take 1-3 minutes, is there any way to speed that up, or at least profile which stages of the connect process are taking most of the time?

connect() blocking for 1-3 minutes is a long time. We really need a modem trace of this situation to be able to help you further with this issue.

Let me know if there's anything I can do to help you capture a modem trace. 

Best regards,

Heidi