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.

[Triffid_Hunter]

The errors after "HTTPS Client started" are a red herring - see https://devzone.nordicsemi.com/f/nordic-q-a/64965/nrf9160-sdk-bug-report-at_cmd_write-is-called-before-at_comms_init-if-config_lte_auto_init_and_connect-becomes-set

I've still no idea what the error 45 is about though, some searching seems to indicate it may be something to do with the modem not liking the certificate, but I already grabbed the requisite cert from the target server and provided it.

Is there some way to get more debugging information from that section of NRF's library?

[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.