feather nrf9151 and HTTPS example

marjonz · 2025-12-05T08:06:04+00:00

I’ve followed the instructions in https://docs.circuitdojo.com/nrf9151-feather/using-vscode.html and need to build the “https” example. When generating the b...

marjonz

jaredwolff I’m off the tip v3.0.x
Yes, I edited the prj.conf as I pasted above. Other than than, should be clean, as it builds the merged.hex properly and I can flash the device correctly.

EDIT: Wait, i think i got something, is this what is expected if the device is able to post?

{"level":"info","ts":1765144718.3906515,"logger":"http.log.access.log0","msg":"NOP","request":{"remote_ip":"<device ip address?>","remote_port":"43004","client_ip":"<device ip address?>","proto":"HTTP/2.0","method":"GET","host":"<public url redacted>","uri":"/js/lkk_ch.js","headers":{"Accept-Language":["en-US,en;q=0.9,de-CH;q=0.8,de;q=0.7,ca;q=0.6"],"User-Agent":["Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36"],"Accept-Encoding":["gzip, deflate"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"<public url redacted>"}},"bytes_read":0,"user_id":"","duration":0.000006041,"size":0,"status":0,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}

And the device seems to periodically post to the endpoint, is that correct?

marjonz

I disabled the lines

    /* Provision certificates before connecting to the LTE network */
    err = cert_provision();

last night before I saw your post for Caddy, thinking it might be my Apache server not liking the certificate since it was self signed. I re-enabled it again just now, and that seemed to work now. Thank you very much for the support.

I am still getting an error from the device:

[00:00:02.255,828] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.599,731] <inf> cloud: Certificate match
[00:00:16.359,771] <inf> cloud: Publish path: <public url redacted>/api/device/data
[00:00:16.359,924] <inf> cloud: Payload: {"do_something":true}
[00:00:16.359,954] <inf> cloud: Looking up <public url redacted>
[00:00:46.366,912] <err> cloud: getaddrinfo() failed. Err: 116
[00:00:46.367,370] <err> os: ***** BUS FAULT *****
[00:00:46.367,401] <err> os:   Precise data bus error
[00:00:46.367,401] <err> os:   BFAR Address: 0x0
[00:00:46.367,431] <err> os: r0/a1:  0xfffffffc  r1/a2:  0x200149cc  r2/a3:  0x40015000
[00:00:46.367,431] <err> os: r3/a4:  0x00000020 r12/ip:  0x00000001 r14/lr:  0x0002e2d5
[00:00:46.367,431] <err> os:  xpsr:  0x21000000
[00:00:46.367,462] <err> os: Faulting instruction address (r15/pc): 0x0002a52a
[00:00:46.367,492] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:46.367,523] <err> os: Current thread: 0x2000d9b0 (unknown)
[00:00:46.435,882] <err> os: Halting system

but watching the tail -f /var/log/caddy/nrf9151.log shows me a remote IP has connected to the endpoint and posted. Not sure what else I’m doing wrong at this point.

EDIT: It gave a different error after power cycling the device:

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,706] <inf> app_startup: *** Vsys Current Limit: 1000 mA ***
[00:00:02.255,859] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.599,639] <inf> cloud: Certificate match
[00:00:16.756,408] <inf> cloud: Publish path: <public url redacted>/api/device/data
[00:00:16.756,561] <inf> cloud: Payload: {"do_something":true}
[00:00:16.756,591] <inf> cloud: Looking up <public url redacted>
[00:00:22.481,323] <err> cloud: Unable to connect. Err: -116 - Connection timed out
[00:00:22.483,093] <err> os: ***** BUS FAULT *****
[00:00:22.483,093] <err> os:   Precise data bus error
[00:00:22.483,123] <err> os:   BFAR Address: 0x0
[00:00:22.483,123] <err> os: r0/a1:  0xfffffffc  r1/a2:  0x200149cc  r2/a3:  0x2000c644
[00:00:22.483,154] <err> os: r3/a4:  0x00000020 r12/ip:  0x00000000 r14/lr:  0x0002e2d5
[00:00:22.483,154] <err> os:  xpsr:  0x21000000
[00:00:22.483,154] <err> os: Faulting instruction address (r15/pc): 0x0002a52a
[00:00:22.483,184] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:22.483,245] <err> os: Current thread: 0x2000d9b0 (unknown)
[00:00:22.553,436] <err> os: Halting system

marjonz

Yeah, I’m now stuck at that error, essentially the connect() call is failing.

    /* Connect */
    err = connect(fd, res->ai_addr, sizeof(struct sockaddr_in));
    if (err < 0)
    {
        err = -errno;
        LOG_ERR("Unable to connect. Err: %i - %s", err, strerror(errno));
    }

I test with curl and it hits the endpoint properly, but the connect fails.
FYI: I have to keep shutting the external port when not testing, I’m getting random hits from people sniffing ports.

marjonz

I was able to catch it when it seemed to work (once!)

[00:01:37.619,628] <inf> cloud: Publish path: <url redacted>/api/device/data
[00:01:37.619,781] <inf> cloud: Payload: {"do_something":true}
[00:01:37.619,812] <inf> cloud: Looking up <url redacted>
[00:01:38.424,804] <inf> cloud: getaddrinfo() successful.
[00:01:38.425,231] <inf> cloud: Socket created.
[00:01:38.425,262] <inf> cloud: Socket options set.
[00:01:38.425,292] <inf> cloud: Socket TX successful.
[00:01:38.425,567] <inf> cloud: TLS setup complete.
[00:01:43.386,047] <inf> cloud: Connected!
[00:01:43.386,108] <inf> cloud: Socket setup complete
[00:01:44.865,753] <inf> cloud: HTTP Status 200
[00:01:44.865,905] <inf> cloud: HTTP Status 200
[00:01:44.865,936] <inf> cloud: Response data
                                22 73 74 61 74 75 73 22  3a 22 73 75 63 63 65 73 |"statu                                          s" :"succes
                                73 22 2c 22 74 69 6d 65  73 74 61 6d 70 22 3a 22 |s","ti                                          me stamp":"
                                32 30 32 35 2d 31 32 2d  30 38 54 30 30 3a 31 31 |2025-1                                          2- 08T00:11
                                3a 35 37 2e 33 36 33 5a  22 7d 65 6e 67 74 68 3a |:57.36                                          3Z "}ength:
                                20 35 39 0d 0a 43 6f 6e  74 65 6e 74 2d 54 79 70 | 59..C                                          on tent-Typ
                                65 3a 20 61 70 70 6c 69  63 61 74 69 6f 6e 2f 6a |e: app                                          li cation/j
                                73 6f 6e 3b 20 63 68 61  72 73 65 74 3d 75 74 66 |son; c                                          ha rset=utf
                                2d 38 0d 0a 44 61 74 65  3a 20 4d 6f 6e 2c 20 30 |-8..Da                                          te : Mon, 0
                                38 20 44 65 63 20 32 30  32 35 20 30 30 3a 31 31 |8 Dec                                           20 25 00:11
                                3a 35 37 20 47 4d 54 0d  0a 45 74 61 67 3a 20 57 |:57 GM                                          T. .Etag: W
                                2f 22 33 62 2d 79 77 4f  4e 42 67 2f 31 5a 71 4d |/"3b-y                                          wO NBg/1ZqM
                                63 75 36 6b 75 75 42 44  70 41 55 34 5a 61 55 30 |cu6kuu                                          BD pAU4ZaU0
                                22 0d 0a 56 69 61 3a 20  31 2e 31 20 43 61 64 64 |"..Via                                          :  1.1 Cadd
                                79 0d 0a 58 2d 50 6f 77  65 72 65 64 2d 42 79 3a |y..X-P                                          ow ered-By:
                                20 45 78 70 72 65 73 73  0d 0a 43 6f 6e 6e 65 63 | Expre                                          ss ..Connec
                                74 69 6f 6e 3a 20 63 6c  6f 73 65 0d 0a 0d 0a 7b |tion:                                           cl ose....{
[00:01:44.865,966] <inf> main: Cloud callback
[00:01:44.868,133] <inf> cloud: Data sent to cloud

Succeeding power cycles to the device, no changes on the server side, seems to keep failing to connect(). The device seems inconsistent somehow?

jaredwolff

So it seems like the bus fault is happening when a DNS failure occurs. I assume you had an activated SIM inserted and an antenna connected when it failed?

marjonz

jaredwolff yes. Activated sim and antenna. It succeeded a second time. But it’s pretty inconsistent. All I did was power off the device, wait longer seconds, then powered up again, and it worked. Sometimes it doesn’t

jaredwolff

One thing you can do is increase the size of the cloud stack. Usually you get an overflow message, but it’s potentially causing this.

I’ve also seen instances of the certificate not being loaded into the certificate store properly which can cause this issue as well.

I’ll dive in a bit more tomorrow.

marjonz

jaredwolff thank you. In the meantime, I will try and spin up a Docker container for the server. Rather no have random hits on my physical server, which I was getting a lot off, so I turned off the port forward on the port again

jaredwolff

@marjonz I just pushed a small fix: https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/commit/26b8e008d46360fa88ac0ae7742b6180fa1e6e5d

I was using k_free instead of cJSON_free. That should fix the fault. If your device has a spotty connection or the antenna is not hooked up, etc you will still get publish failures. The device cannot publish without a cellular connection.

marjonz

Thank you for that. I’ll cherry pick the fix into my branch.

marjonz

I’ve cherry picked all your changes, but it still struggles to have a consistent connection. I’m using an Onemondo SIM. and I’ve tried running the feather outside in an open area where I will most likely get better LTE coverage. It still fails getting a connection.
It has stopped crashing though if the connection fails, which is as expected with your fix.

jaredwolff

I would check with Onemondo to make sure they have appropriate (CAT M1 or NB IoT) coverage where you are. How are you powering your board? Via USB? What antenna are you using?

marjonz

jaredwolff powering the board off my laptop’s USB as I am watching it with putty for printouts. the antenna is the Linx LTE RPX UFL antenna

marjonz

I have physically moved to another office, and have done the following:

Ran the server side.

Test with curl that the endpoint is active. Works!
Then on the device side, flashed and programmed the software:
1) Plugged the board to my laptop, and ran putty (as quick as possible to see the output). Log output:

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,645] <inf> app_startup: *** Vsys Current Limit: 1000 mA ***
[00:00:02.255,798] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.599,670] <inf> cloud: Certificate match
[00:00:16.010,589] <inf> cloud: Publish path: <my url>/api/device/da                                                                        ta
[00:00:16.010,742] <inf> cloud: Payload: {"do_something":true}
[00:00:16.010,772] <inf> cloud: Looking up <my url>
[00:00:17.206,054] <inf> cloud: getaddrinfo() successful.
[00:00:17.206,329] <inf> cloud: Socket created.
[00:00:17.206,359] <inf> cloud: Socket options set.
[00:00:17.206,390] <inf> cloud: Socket TX successful.
[00:00:17.206,756] <inf> cloud: TLS setup complete.
[00:00:22.207,305] <err> cloud: Unable to connect. Err: -116 - Connection timed                                                                         out
[00:00:22.207,366] <inf> cloud: Free addr info
[00:00:22.208,709] <err> cloud: Unable to setup socket. Err: -116
[00:00:22.208,709] <err> main: Unable to publish. Err: -116

2) Press the reset button on the feather board, no other changes, did not move the board or antenna, Log output:

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,676] <inf> app_startup: *** Vsys Current Limit: 1000 mA ***
[00:00:02.255,828] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.600,189] <inf> cloud: Certificate match
[00:00:14.566,650] <inf> cloud: Publish path: <my url>/api/device/da                                                                        ta
[00:00:14.566,802] <inf> cloud: Payload: {"do_something":true}
[00:00:14.566,833] <inf> cloud: Looking up <my url>
[00:00:15.202,117] <inf> cloud: getaddrinfo() successful.
[00:00:15.202,392] <inf> cloud: Socket created.
[00:00:15.202,392] <inf> cloud: Socket options set.
[00:00:15.202,423] <inf> cloud: Socket TX successful.
[00:00:15.202,819] <inf> cloud: TLS setup complete.
[00:00:19.718,414] <inf> cloud: Connected!
[00:00:19.718,444] <inf> cloud: Free addr info
[00:00:19.718,475] <inf> cloud: Socket setup complete
[00:00:21.369,201] <inf> cloud: HTTP Status 200
[00:00:21.369,354] <inf> cloud: HTTP Status 200
[00:00:21.369,384] <inf> cloud: Response data
                                22 73 74 61 74 75 73 22  3a 22 73 75 63 63 65 73                                                                         |"status" :"succes
                                73 22 2c 22 74 69 6d 65  73 74 61 6d 70 22 3a 22                                                                         |s","time stamp":"
                                32 30 32 35 2d 31 32 2d  30 39 54 31 39 3a 30 39                                                                         |2025-12- 09T19:09
                                3a 32 36 2e 38 35 37 5a  22 7d 65 6e 67 74 68 3a                                                                         |:26.857Z "}ength:
                                20 35 39 0d 0a 43 6f 6e  74 65 6e 74 2d 54 79 70                                                                         | 59..Con tent-Typ
                                65 3a 20 61 70 70 6c 69  63 61 74 69 6f 6e 2f 6a                                                                         |e: appli cation/j
                                73 6f 6e 3b 20 63 68 61  72 73 65 74 3d 75 74 66                                                                         |son; cha rset=utf
                                2d 38 0d 0a 44 61 74 65  3a 20 54 75 65 2c 20 30                                                                         |-8..Date : Tue, 0
                                39 20 44 65 63 20 32 30  32 35 20 31 39 3a 30 39                                                                         |9 Dec 20 25 19:09
                                3a 32 36 20 47 4d 54 0d  0a 45 74 61 67 3a 20 57                                                                         |:26 GMT. .Etag: W
                                2f 22 33 62 2d 53 34 4d  6d 74 50 65 67 70 46 64                                                                         |/"3b-S4M mtPegpFd
                                31 41 4d 57 5a 59 36 6d  2b 52 67 6e 46 46 37 41                                                                         |1AMWZY6m +RgnFF7A
                                22 0d 0a 56 69 61 3a 20  31 2e 31 20 43 61 64 64                                                                         |"..Via:  1.1 Cadd
                                79 0d 0a 58 2d 50 6f 77  65 72 65 64 2d 42 79 3a                                                                         |y..X-Pow ered-By:
                                20 45 78 70 72 65 73 73  0d 0a 43 6f 6e 6e 65 63                                                                         | Express ..Connec
                                74 69 6f 6e 3a 20 63 6c  6f 73 65 0d 0a 0d 0a 7b                                                                         |tion: cl ose....{
[00:00:21.369,415] <inf> main: Cloud callback
[00:00:21.371,582] <inf> cloud: Data sent to cloud

3) Press the reset button a second time, did not move the board or antenna, log output:

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,645] <inf> app_startup: *** Vsys Current Limit: 1000 mA ***
[00:00:02.255,828] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.599,731] <inf> cloud: Certificate match
[00:00:15.519,836] <inf> cloud: Publish path: <my url>/api/device/data
[00:00:15.519,989] <inf> cloud: Payload: {"do_something":true}
[00:00:15.520,050] <inf> cloud: Looking up <my url>
[00:00:16.075,347] <inf> cloud: getaddrinfo() successful.
[00:00:16.075,592] <inf> cloud: Socket created.
[00:00:16.075,622] <inf> cloud: Socket options set.
[00:00:16.075,653] <inf> cloud: Socket TX successful.
[00:00:16.076,019] <inf> cloud: TLS setup complete.
[00:00:21.076,538] <err> cloud: Unable to connect. Err: -116 - Connection timed out
[00:00:21.076,568] <inf> cloud: Free addr info
[00:00:21.077,758] <err> cloud: Unable to setup socket. Err: -116
[00:00:21.077,758] <err> main: Unable to publish. Err: -116

4) Tried a fourth time, moved the antenna a bit, log output:

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,676] <inf> app_startup: *** Vsys Current Limit: 1000 mA ***
[00:00:02.255,828] <inf> main: HTTPS Sample. Board: circuitdojo_feather_nrf9151
[00:00:02.599,792] <inf> cloud: Certificate match
[00:00:13.922,821] <inf> cloud: Publish path: <my url>/api/device/data
[00:00:13.922,973] <inf> cloud: Payload: {"do_something":true}
[00:00:13.923,004] <inf> cloud: Looking up <my url>
[00:00:14.808,319] <inf> cloud: getaddrinfo() successful.
[00:00:14.808,563] <inf> cloud: Socket created.
[00:00:14.808,593] <inf> cloud: Socket options set.
[00:00:14.808,624] <inf> cloud: Socket TX successful.
[00:00:14.809,051] <inf> cloud: TLS setup complete.
[00:00:19.715,637] <inf> cloud: Connected!
[00:00:19.715,667] <inf> cloud: Free addr info
[00:00:19.715,698] <inf> cloud: Socket setup complete
[00:00:21.284,362] <inf> cloud: HTTP Status 200
[00:00:21.284,515] <inf> cloud: HTTP Status 200
[00:00:21.284,545] <inf> cloud: Response data
                                22 73 74 61 74 75 73 22  3a 22 73 75 63 63 65 73 |"status" :"succes
                                73 22 2c 22 74 69 6d 65  73 74 61 6d 70 22 3a 22 |s","time stamp":"
                                32 30 32 35 2d 31 32 2d  30 39 54 31 39 3a 32 32 |2025-12- 09T19:22
                                3a 30 31 2e 35 38 37 5a  22 7d 65 6e 67 74 68 3a |:01.587Z "}ength:
                                20 35 39 0d 0a 43 6f 6e  74 65 6e 74 2d 54 79 70 | 59..Con tent-Typ
                                65 3a 20 61 70 70 6c 69  63 61 74 69 6f 6e 2f 6a |e: appli cation/j
                                73 6f 6e 3b 20 63 68 61  72 73 65 74 3d 75 74 66 |son; cha rset=utf
                                2d 38 0d 0a 44 61 74 65  3a 20 54 75 65 2c 20 30 |-8..Date : Tue, 0
                                39 20 44 65 63 20 32 30  32 35 20 31 39 3a 32 32 |9 Dec 20 25 19:22
                                3a 30 31 20 47 4d 54 0d  0a 45 74 61 67 3a 20 57 |:01 GMT. .Etag: W
                                2f 22 33 62 2d 6a 50 78  33 65 74 45 69 32 75 43 |/"3b-jPx 3etEi2uC
                                67 6c 4e 6c 32 59 50 67  72 35 48 68 36 41 51 41 |glNl2YPg r5Hh6AQA
                                22 0d 0a 56 69 61 3a 20  31 2e 31 20 43 61 64 64 |"..Via:  1.1 Cadd
                                79 0d 0a 58 2d 50 6f 77  65 72 65 64 2d 42 79 3a |y..X-Pow ered-By:
                                20 45 78 70 72 65 73 73  0d 0a 43 6f 6e 6e 65 63 | Express ..Connec
                                74 69 6f 6e 3a 20 63 6c  6f 73 65 0d 0a 0d 0a 7b |tion: cl ose....{
[00:00:21.284,576] <inf> main: Cloud callback
[00:00:21.286,499] <inf> cloud: Data sent to cloud
``` 
So either the modem setup isn't really succeeding or there is something wrong with the setup that the call to 
`err = connect(fd, res->ai_addr, sizeof(struct sockaddr_in));` randomly fails. Is the antenna also quite sensitive? I imagine it should be a bit more robust given it's size, and where I'm physically located in the central business district at the moment, and should have a lot better coverage than my home

marjonz

So I got access to the Onemondo dashboard for the SIM card, and I got the logs (as PCAP files) and fed them to wireshark. I was able to get logs when the device fails the connection, and once when it succeeded. Correct me if I’m wrong, but as far as I follow with the logs, it looks like it was the feather device side that gave up on the connection.
I am attaching the snapshots of the successful attempt vs the failed attempt.

Looking closely at about entry 63, the device side sent a FIN to the server side, after a new session ticket was created, when the connection is considered a failure.
But when it is successful, the device will actually send “application data”.
As far as inspecting the code, it boils down to the call to connect() (which is actually the zsock_connect()) that fails or succeeds. Thoughts on how reliable this call is?

I have added a check for the LTE network status: lte_lc_nw_reg_status_get(&network_status); and that returns

	/** Registered, roaming. */
	LTE_LC_NW_REG_REGISTERED_ROAMING	= 5,

in both cases, so I am sure the LTE connection does not seem to be the problem here.

AchimKraus

What I miss is some information about the signal strength (RSRP) and quality (RSRQ). But maybe I have overseen it (there quite a lot of comments above).
There are some studies (non public), which came to the conclusion, that using TCP/TLS vs. UDP/DTLS requires about 10 dBm more signal strength for the same reliability. Therefore it’s especially for TCP based communication very important to know that signal numbers. I guess you will also find out, that there are some locations, where all works reliable, others with issues, and also others with bigger problems. Let’s see, if you get also a relation of the RSRP/Q and the reliability of TCP/TLS.

Just to add:
I use UDP (CoAP/DTLS 1.2 CID) on a couple for nRF9160/51 feathers and the devices are working very good in the field, even on poor signals. But that’s what CoAP is for.

marjonz

That is very insightful. Would be great to make those information public if possible to help the community.

I will try and print out the RSSI and see if there is any correlation between signal strength and my success rate.

The problem seems to boil down to one line of code which is the zsock_connect and it seems to timeout, which causes everything to fail. I will post more info tomorrow.

AchimKraus

make those information public

Unfortunately it’s not my research.

I will try and print out the RSSI and see if there is any correlation between signal strength and my success rate.

Just to mention:
the RSRP/Q will usually swing. I observe a RSRP range of about 10 dBm at the same location over the time. Let me therefore recommend, to collect not just a few samples (3-6), I would got for more than 10, if possible.

jaredwolff

It’s also possible that the device is simply not waiting long enough. This sample is a generic sample, it’s not tailored specifically to one use case, server type, etc.

In socket_setup() you could increase which may help with the issue you’re seeing @marjonz:

    struct timeval recv_timeout = {
        .tv_sec = 5};

    err = setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &recv_timeout, sizeof(recv_timeout));
    if (err != 0)
    {
        err = -errno;
        LOG_ERR("Set receive timeout failed, error: %d, errno: %d", err, errno);
        goto clean_up;
    }

    struct timeval send_timeout = {
        .tv_sec = 5};

    err = setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &send_timeout, sizeof(send_timeout));
    if (err)
    {
        err = -errno;
        LOG_ERR("Set transmit timeout failed, error: %d, errno: %d", err, errno);
        goto clean_up;
    }

I have seen this previously with lambda functions not staying warm and taking slightly too long and thus getting rejected. (I know your case is not that). Did you check the server logs and Caddy logs for any insights?

marjonz

jaredwolff Yes, I have a shell doing a tail on the caddy logs, when it fails, there is nothing, when it succeeds, I do get an entry with the proper timestamp. I will try and increase the timeout, start at doubling it and see how reliable that gets to.

jaredwolff

@marjonz are you using dyndns or do you have the url set to a static IP?

This behavior is very characteristic of something going wrong during the TLS negotiation. I had this happen once when the certificate wasn’t being written to the certificate store. There’s no logic preventing that here since you have

[00:00:02.599,731] <inf> cloud: Certificate match

So that’s not the issue in this case. (Plus it would fail every time not just occasionally) Can you confirm your setup and how you have things configured?

My guess is:

Firewall -> Caddy -> Node.js server
And dyndns for setting DNS

Btw the sample relies on a specific cipher that I know that Caddy supports – TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b). If the right cipher suite is not chosen it could cause issues like this as well.

You could also remove this section in tls_setup:

	err = setsockopt(fd, SOL_TLS, TLS_PEER_VERIFY, &verify, sizeof(verify));
	if (err) {
		printk("Failed to setup peer verification, err %d, %s\n", errno, strerror(errno));
		return err;
	}

If you get better performance with that removed it’s a DNS issue. The server name/DNS does not match what the client expects.

marjonz

jaredwolff
1) Yes, I am using a dynamic IP, but that rarely changes even with the router reboots. My URL is setup to update if and when the router reboots (daily at 3am). And I don’t really test until about 9am or so. I think that should have given enough time (if the IP did change) for the DNS entries to have been updated.
And as you mentioned, the Certificate matches entry, so it looks to have been happy.
2) Router (also has a firewall) -> port forward to a local machine running linux -> machine running caddy and node.js server. And Let’s Encrypt for the DNS.
3) If the timeout change does not improve things, I will comment out the verify line to test. I will post results here (for the next person that encounters these issues).

« Previous Page Next Page »