aiocoap / DTLS error

[pedolsky]

The problem

I can't do much with this error, but it has been appearing since 2022.5.x beta:

[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py:162: UserWarning: DTLS module did not shut down the DTLSSocket perfectly; it still tried to call _write in vain
  warnings.warn("DTLS module did not shut down the DTLSSocket "
Exception ignored in: <function DTLSClientConnection.__del__ at 0x7f49cffc3280>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py", line 252, in __del__
  File "/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py", line 235, in shutdown
AttributeError: 'DTLSClientConnection' object has no attribute '_retransmission_task'
Exception ignored in: <function DTLSClientConnection.__del__ at 0x7f49cffc3280>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py", line 252, in __del__
  File "/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py", line 235, in shutdown
AttributeError: 'DTLSClientConnection' object has no attribute '_retransmission_task'
[finish] process exit code 0
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.

What version of Home Assistant Core has the issue?

core-2022.5.0b4

What was the last working version of Home Assistant Core?

core-2022.4.7

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

Tradfri

Link to integration documentation on our website

https://www.home-assistant.io/integrations/tradfri/

Diagnostics information

{
  "home_assistant": {
    "installation_type": "Home Assistant Supervised",
    "version": "2022.5.0b5",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.9.9",
    "docker": true,
    "arch": "x86_64",
    "timezone": "Europe/Berlin",
    "os_name": "Linux",
    "os_version": "5.10.0-13-amd64",
    "supervisor": "2022.04.0",
    "host_os": "Debian GNU/Linux 11 (bullseye)",
    "docker_version": "20.10.14",
    "chassis": "laptop",
    "run_as_root": true
  },
  "custom_components": {
    "alexa_media": {
      "version": "3.11.3",
      "requirements": [
        "alexapy==1.25.5",
        "packaging>=20.3",
        "wrapt>=1.12.1"
      ]
    }
  },
  "integration_manifest": {
    "domain": "tradfri",
    "name": "IKEA TR\u00c5DFRI",
    "config_flow": true,
    "documentation": "https://www.home-assistant.io/integrations/tradfri",
    "requirements": [
      "pytradfri[async]==9.0.0"
    ],
    "homekit": {
      "models": [
        "TRADFRI"
      ]
    },
    "codeowners": [],
    "iot_class": "local_polling",
    "loggers": [
      "pytradfri"
    ],
    "is_built_in": true
  },
  "data": {
    "gateway_version": "1.17.44",
    "device_data": [
      "FYRTUR block-out roller blind",
      "TRADFRI Driver 10W",
      "TRADFRI Driver 30W",
      "TRADFRI Signal Repeater",
      "TRADFRI bulb E14 WS opal 600lm",
      "TRADFRI bulb E14 WS opal 600lm",
      "TRADFRI bulb E14 WS opal 600lm",
      "TRADFRI open/close remote"
    ]
  }
}

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

~$ ha info
arch: amd64
channel: stable
docker: 20.10.14
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
hassos: null
homeassistant: 2022.5.0b5
hostname: xxxx
logging: info
machine: qemux86-64
operating_system: Debian GNU/Linux 11 (bullseye)
state: running
supervisor: 2022.04.0
supported: true
supported_arch:
- amd64
- i386
timezone: Europe/Berlin

[probot-home-assistant]

tradfri documentation
tradfri source
_{^{(message by IssueLinks)}}

[ggravlingen]

@frenck is this a known issue caused by something else in the system? Can't see we've changed anything in the Tradfri platform recently that would cause this? Also, I don't see this in 2022.5.0.b4

[frenck]

@ggravlingen Not that I'm aware of. I honestly don't see what could possibly cause this.

@pedolsky Could you provide the output of the ha info command from a terminal? (Or, alternatively, the data that is presented in system health)

[ggravlingen]

@frenck this is odd indeed.

@pedolsky in addition to the request from @frenck, can you please provide the diagnostics file output for Tradfri? You'll find it under the triple dots in Tradfri under the integrations page.

[ggravlingen]

@pedolsky please also try restarting the gateway and then restarting Home Assistant. If you haven't already, I recommend using a fixed IP for your gateway.

[pedolsky]

Added the required information under "Diagnostics information" and "Additional information".

Thank you for your quick response, very appreciated! I only assume that the Tradfri integration causes this error because I couldn’t find any other hint to aiocoap, but I can be wrong.

[ggravlingen]

Thanks for the extra info. If you're using a fixed IP and rebooted the gateway before rebooting HA, there's not much more advise I can give I'm afraid. Those errors normally occurs when there's something in the local environment that's out of order.

[ggravlingen]

I just updated to b5 from b4 and my Tradfri system still works as expected.

Ping @frenck: I'd say this error is unrelated to 2022.5.

[pedolsky]

Small update: The error occurs each time after restarting HA. Could this be IPv6 related? But I disabled it on my host system.

[thecode]

Small update: The error occurs each time after restarting HA. Could this be IPv6 related? But I disabled it on my host system.

The issue is related to the shutdown itself:
UserWarning: DTLS module did not shut down the DTLSSocket perfectly; it still tried to call _write in vain warnings.warn("DTLS module did not shut down the DTLSSocket "

Probably something leaves a DTSL socket open, although it is an annoying warning and should be fixed, it doesn't have any impact on the system, I have seen similar errors for other integrations in the past.

[pedolsky]

it doesn't have any impact on the system

That's right. And I'm not concerned about it, unless you find that a security issue or something would be the reason.
I'm using beta on my main system for the first time, so I followed the invitation "If you encounter any problems with the beta, please report them on GitHub:"
I just wanted to report what I noticed.

[ggravlingen]

@pedolsky sorry, I misunderstood you here. Thank you for reporting the issue!

[pedolsky]

Is there a better channel for reporting? I didn't want to make so much noise.
Anyway, 2022.5 is really fun, thanks to all of you!

[thecode]

@pedolsky this is the best place to report issues with core and your issue contains all the information needed.
I just wrote that you should not be worried by this issue impacting your system.
Running beta releases and reporting issues is highly valued and helps resolving issues before it has larger impact, many thanks for that.