fd leak with https_port enabled (sockets to :80 in CLOSE_WAIT)

[shasta123]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

Describe the bug

Hi,

After upgrading to 2.32.5 and running deconz with
/usr/bin/deCONZ --platform minimal --http-port=80 --https-port=443 --auto-connect=1 --device...

I noticed the process consuming a significant number of fd, eventually crashing with too many open files.

Running deconz for a couple of minutes I saw >200 sockets from 127.0.0.1:* -> 127.0.0.1:80 hanging in CLOSE_WAIT

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 1 0 127.0.0.1:44430 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
tcp 1 0 127.0.0.1:60954 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
tcp 1 0 127.0.0.1:57714 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
tcp 1 0 127.0.0.1:44444 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
tcp 1 0 127.0.0.1:58022 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
tcp 1 0 127.0.0.1:58184 127.0.0.1:80 CLOSE_WAIT 363462/deCONZ
[...]

It seems deconz itself is connecting to localhost:

1:57:21.656222 IP 127.0.0.1.34180 > 127.0.0.1.80: Flags [SEW], seq 2278738155, win 65495, options [mss 65495,sackOK,TS val 2669637931 ecr 0,nop,wscale 7], length 0
21:57:21.656253 IP 127.0.0.1.80 > 127.0.0.1.34180: Flags [S.E], seq 4205519716, ack 2278738156, win 65483, options [mss 65495,sackOK,TS val 2669637931 ecr 2669637931,nop,wscale 7], length 0
21:57:21.656284 IP 127.0.0.1.34180 > 127.0.0.1.80: Flags [.], ack 1, win 512, options [nop,nop,TS val 2669637931 ecr 2669637931], length 0
21:57:31.282721 IP 127.0.0.1.80 > 127.0.0.1.34176: Flags [F.], seq 1, ack 1, win 512, options [nop,nop,TS val 2669647557 ecr 2669637411], length 0
21:57:31.282817 IP 127.0.0.1.80 > 127.0.0.1.34180: Flags [F.], seq 1, ack 1, win 512, options [nop,nop,TS val 2669647557 ecr 2669637931], length 0
[...]

When I disable HTTPS (just using 443 for ws) it seems to work stable (although this config will trigger the delays with Alexa):

usr/bin/deCONZ --platform minimal --http-port=80 --https-port=0 --ws-port=443 --auto-connect=1

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 373263/deCONZ
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 373263/deCONZ
tcp 0 0 xxx.xx.xxx.97:443 192.168.164.251:56942 ESTABLISHED 373263/deCONZ
tcp 0 0 xxx.xx.xxx.97:443 192.168.164.251:56940 ESTABLISHED 373263/deCONZ
tcp 0 0 xxx.xx.xxx.97:80 xxx.xx.xxx.65:36468 ESTABLISHED 373263/deCONZ
tcp 0 0 xxx.xx.xxx.97:80 xxx.xx.xxx.97:33226 ESTABLISHED 373263/deCONZ

Cheers,
Michael

Steps to reproduce the behavior

Specify HTTP+HTTPS Port
Wait for process to fail

Expected behavior

No dangling sockets

Screenshots

No response

Environment

• PC
• Debian Trixie 13.3
• deCONZ 2.32.5
• Device: ConBee II

deCONZ Logs

No response

Additional context

No response

[Smanar]

--http-port=80 --https-port=443

And you can try with only https-port ?
With both it seem deconz is using 443 but third app 80 if I have understand ?

[manup]

Thanks for the report, I can reproduce this and have an idea what's the cause.
Internally incoming connections are forwarded/proxied and here the the shutdown of a socket seems to be incomplete.

Working on a fix now.

[manup]

I've added two fixes to solve the CLOSE_WAIT state problem dresden-elektronik/deconz@fab9a4f and dresden-elektronik/deconz-lib@0167f6b

Surprisingly clients hand this differently while curl rejects a self signed certificate (without the -k parameter) but otherwise doesn't abort the handshake and cleanly closes the TCP connection websocat aborts earlier during the SSL handshake.

[xfirf]

Thanks for this report. That issue is driving me nuts too. :-)