Can't connect to BespokeAI Washer/Dryer

[maxromanovsky]

Thank you very much for the library that should save many of us lots of money on subscription costs for the devices we've already purchased.

Unfortunately, atm it doesn't work for me for BespokeAI Washer/Dryer.

Model numbers:

• Washer: WW11BB534DAWS6
• Dryer: DV90BB5245AWS6

Are there any troubleshooting tips you can share?

I've tried

• power cycling both appliances
• force closing SmartThings mobile app
• pressing the smart control button on the appliances (all stuff below was tested with smart control on and off couple of times)
• connecting to them via HACS localthings
• running test script (if smart control was on, the icon on the appliance was blinking when the script was running)
• running coap_sec_probe.py from Newer Samsung firmware uses standard OCF ports (5683/5684) + non-AC14K_M trust anchor #16 (if smart control was on, the icon on the appliance was blinking when the script was running)

I'm connected to the same VLAN/subnet as Home Assistant & Samsung appliances. There are no firewall rules, and mobile app works.

Appliances work fine with the mobile app.

Everything below is for my washer.

$ wget https://raw.githubusercontent.com/QuiteYellow/SmartThings-Local/refs/heads/main/setup_cert.py
--2026-08-01 16:58:50--  https://raw.githubusercontent.com/QuiteYellow/SmartThings-Local/refs/heads/main/setup_cert.py
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.110.133, 185.199.109.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20512 (20K) [text/plain]
Saving to: ‘setup_cert.py’

setup_cert.py                                        100%[===================================================================================================================>]  20.03K  --.-KB/s    in 0.004s

2026-08-01 16:58:50 (5.13 MB/s) - ‘setup_cert.py’ saved [20512/20512]

$ python setup_cert.py
============================================================
Phase 1: AC14K_M signing materials
============================================================
  Fetching AC14K_M bundle...
  AC14K_M cert: certs/.bundle/ac14k_m.pem
  AC14K_M key:  certs/.bundle/ac14k_m.key
  chain:        4 certs (cert_1.pem, cert_2.pem, cert_3.pem, cert_4.pem)
  cert/key modulus pair OK

============================================================
Phase 2: identify peer UUID
============================================================
  Fetching from connect-v2.samsungiotcloud.com:443...
  Extracted UUID: ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9
  Saved server leaf cert to certs/samsung_cloud_leaf.pem

============================================================
Phase 3: mint client cert with UUID ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9
============================================================
  key:       certs/client.key
  leaf:      certs/client.pem
  fullchain: certs/client_fullchain.pem
  Subject: OU=uuid:ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9, CN=urn:uuid:ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9, O=Samsung Electronics, C=KR

============================================================
Done. Output dir: /Users/max/Downloads/certs
============================================================

$ python -m venv venv

$ source venv/bin/activate

$ pip install smartthings-local

$ sudo nmap -Pn -sU -p 49152-49160 "192.168.4.27"
Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-01 16:09 +0200
Nmap scan report for Samsung-Washer.iot (192.168.4.27)
Host is up (0.51s latency).

PORT      STATE         SERVICE
49152/udp closed        unknown
49153/udp open|filtered unknown
49154/udp open          unknown
49155/udp closed        unknown
49156/udp closed        unknown
49157/udp closed        unknown
49158/udp closed        unknown
49159/udp closed        unknown
49160/udp closed        unknown
MAC Address: [REDACTED] (SJI Industry Company)

Nmap done: 1 IP address (1 host up) scanned in 5.58 seconds

$ python coap_sec_probe.py 192.168.4.27
=== Plain CoAP security probe of <target-ip>:5683 (no DTLS, no cert) ===

-> /oic/res (resource + sec-flag enumeration)  (plain CoAP GET /oic/res to <target-ip>:5683)
   <- mid=0x4001 tok=01 type=ACK code=2.05 1024B [MATCH]
      strings: ['bdix$<uuid-redacted>elinks', 'dhrefm/oic/sec/doxmbrt', 'joic.r.doxmbif', 'ooic.if.baselineap', 'csec', 'dport', 'rx.org.iotivity.tls', 'dhrefn/oic/sec/pstatbrt', 'koic.r.pstatbif', 'ooic.if.baselineap', 'csec', 'dport', 'rx.org.iotivity.tls', 'dhreff/oic/dbrt', 'hoic.wk.dloic.d.washerbif', 'ooic.if.baselinehoic.if.rap', 'csec', 'rx.org.iotivity.tcp', 'dhreff/oic/pbrt', 'hoic.wk.pbif', 'ooic.if.baselinehoic.if.rap', 'csec', 'rx.org.iotivity.tcp', 'dhrefq/multidevice/vs/0brt', 'x.com.samsung.da.multidevicebif', 'ooic.if.baselinehoic.if.aap', 'csec', 'rx.org.iotivity.tcp', 'dhrefs/file/transfer/vs/0brt', 'x.com.samsung.file.transferbif', 'ooic.if.baselinehoic.if.aap', 'csec', 'rx.org.iotivity.tcp', 'dhrefo/file/list/vs/0brt', 'wx.com.samsung.file.listbif', 'ooic.if.baselinehoic.if.sap', 'csec', 'rx.org.iotivity.tcp', 'dhrefp/hass/state/vs/0brt', 'x.com.samsung.da.hass.statebif', 'ooic.if.baselinehoic.if.aap', 'csec', 'rx.org.iotivity.tcp', 'dhrefr/hass/command/vs/0brt', 'x.com.samsung.da.hass.commandbif', 'ooic.if.baselinehoic.if.aap', 'csec', 'rx.org.iotivity.tcp']

-> /oic/sec/doxm (owner + UUID; often world-readable)  (plain CoAP GET /oic/sec/doxm to <target-ip>:5683)
   <- mid=0x4002 tok=02 type=ACK code=2.05 215B [MATCH]
      {'oxms': [65282], 'oxmsel': 0, 'sct': 8, 'owned': False, 'deviceuuid': '<uuid-redacted>', 'devowneruuid': '<uuid-redacted>', 'rowneruuid': '<uuid-redacted>', 'rt': ['oic.r.doxm'], 'if': ['oic.if.baseline']}

-> /oic/sec/pstat (provisioning/onboarding state)  (plain CoAP GET /oic/sec/pstat to <target-ip>:5683)
   <- mid=0x4003 tok=03 type=ACK code=2.05 157B [MATCH]
      {'isop': False, 'cm': 2, 'tm': 10, 'om': 4, 'sm': 4, 'deviceuuid': '<uuid-redacted>', 'rowneruuid': '<uuid-redacted>', 'rt': ['oic.r.pstat'], 'if': ['oic.if.baseline']}

$ python test.py
Traceback (most recent call last):
  File "/Users/max/Downloads/test.py", line 9, in <module>
    sess.connect()
    ~~~~~~~~~~~~^^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/smartthings_local/protocol/dtls_session.py", line 243, in connect
    raise TimeoutError(
        f"DTLS handshake timeout to {self.host}:{self.port}")
TimeoutError: DTLS handshake timeout to 192.168.4.27:49154

$ python test.py
Traceback (most recent call last):
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/smartthings_local/protocol/dtls_session.py", line 220, in connect
    conn.do_handshake()
    ~~~~~~~~~~~~~~~~~^^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/OpenSSL/SSL.py", line 2487, in do_handshake
    self._raise_ssl_error(self._ssl, result)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/OpenSSL/SSL.py", line 2090, in _raise_ssl_error
    _openssl_assert(
    ~~~~~~~~~~~~~~~^
        reason == _lib.SSL_R_UNEXPECTED_EOF_WHILE_READING
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/OpenSSL/_util.py", line 73, in openssl_assert
    exception_from_error_queue(error)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/OpenSSL/_util.py", line 59, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.SSL.Error: [('SSL routines', '', 'tls alert handshake failure')]

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/max/Downloads/test.py", line 9, in <module>
    sess.connect()
    ~~~~~~~~~~~~^^
  File "/Users/max/Downloads/venv/lib/python3.14/site-packages/smartthings_local/protocol/dtls_session.py", line 226, in connect
    raise ConnectionError(f"DTLS handshake error: {e}") from e
ConnectionError: DTLS handshake error: [('SSL routines', '', 'tls alert handshake failure')]

The script:

import cbor2
from smartthings_local.protocol.dtls_session import DtlsCoapSession

sess = DtlsCoapSession(
    "192.168.4.27", 49154,
    cert_path="certs/client_fullchain.pem",
    key_path="certs/client.key",
)
sess.connect()
sess.start_reader()

code, body = sess.get(["device", "0"])                       # Block2-aware read
sess.close()

[maxromanovsky]

I have also tried this:

$ TARGET_IP=192.168.4.27 python setup_cert.py --test
============================================================
Phase 1: AC14K_M signing materials
============================================================
  Fetching AC14K_M bundle...
  AC14K_M cert: certs/.bundle/ac14k_m.pem
  AC14K_M key:  certs/.bundle/ac14k_m.key
  chain:        4 certs (cert_1.pem, cert_2.pem, cert_3.pem, cert_4.pem)
  cert/key modulus pair OK

============================================================
Phase 2: identify peer UUID
============================================================
  Fetching from connect-v2.samsungiotcloud.com:443...
  Extracted UUID: ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9
  Saved server leaf cert to certs/samsung_cloud_leaf.pem

============================================================
Phase 3: mint client cert with UUID ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9
============================================================
  key:       certs/client.key
  leaf:      certs/client.pem
  fullchain: certs/client_fullchain.pem
  Subject: OU=uuid:ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9, CN=urn:uuid:ab0b0ac4-aae9-4958-a04d-8ec36fe1b2f9, O=Samsung Electronics, C=KR

============================================================
Phase 4: verify cert against target appliance
============================================================
[+] DTLS handshake to 192.168.4.27:49154...
    handshake TIMEOUT after 12.3s

  Cert failed verification. Check target IP/port and try again.

[maxromanovsky]

In case if it's important, I am using Ubiquiti UniFi, and IoT devices are on a dedicated VLAN, alongside with the Home Assistant itself. Laptop was connected to the same VLAN during the tests. VLAN has IPv4 and IPv6 (for Matter).

[maxromanovsky]

And via openssl, as in mbillow/localthings#179

$ cd certs
$ openssl s_client -dtls -cert_chain ./client_fullchain.pem -key ./client.key -connect 192.168.4.27:49154
Connecting to 192.168.4.27
CONNECTED(00000003)
80A1C7F701000000:error:0A000410:SSL routines:dtls1_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_d1.c:448:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 75 bytes and written 469 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: DTLSv1.2
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : DTLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1785654215
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
80A1C7F701000000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2804:

$ openssl s_client -dtls -cert_chain ./client_fullchain.pem -key ./client.key -connect 192.168.4.27:49153
Connecting to 192.168.4.27
CONNECTED(00000003)
^C

Last command hanged for over a minute

[QuiteYellow]

@maxromanovsky, sorry for the silence.

Your openssl output says No client certificate CA names sent and read 75 bytes and written 469. That is a HelloVerifyRequest plus an alert, with no ServerHello and no CertificateRequest in it, so the device rejected your ClientHello. Your certificate never went on the wire. #16's units reject a certificate they did read, with alert 48; yours is alert 40 and never got that far. Your device also answers on the legacy 4915x range, where #16's units are silent.

Two things in the invocation. You did not restrict the cipher list, and this firmware's mbedtls rejects long multi-cipher ClientHellos before evaluating anything in them. You also passed -cert_chain with no -cert, so there was no leaf for OpenSSL to send regardless.

One clean attempt on a freshly power-cycled unit:

openssl s_client -connect 192.168.4.27:49154 -dtls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256@SECLEVEL=0' \
  -cert certs/client.pem -key certs/client.key \
  -cert_chain certs/client_fullchain.pem -msg 2>&1 | head -60

If a ServerHello and a CertificateRequest come back, the cipher list was the problem.

Check the port too. Your probe output shows the device advertising dport, but it prints raw CBOR without decoding the value, and you are dialling 49154 because nmap showed it open. On a unit in #16 the advertised port was 46060, then 39181 five days later. If yours differs, that alone explains the library's timeout.

Keeping this open and separate from #16.

[maxromanovsky]

@QuiteYellow

Thank you for your response. I am no expert in these protocols, so I am just guessing here. Haven't tried it with the AI yet.

Here's the output from openssl after power cycling:

openssl port 49154

$ openssl s_client -connect 192.168.4.27:49154 -dtls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256@SECLEVEL=0' \
  -cert certs/client.pem -key certs/client.key \
  -cert_chain certs/client_fullchain.pem -msg 2>&1 | head -60
Connecting to 192.168.4.27
CONNECTED(00000003)
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 00 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd 58 a9
    96 d8 c2 a7 da 5d ef 21 66 05 09 b4 b4 5e 3f 38
    99 12 10 e3 fa 9c c2 2e 2d eb 08 74 1b a8 00 00
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
<<< Not TLS data or unknown version (version=65277, content_type=256) [length 000d]
    16 fe fd 00 00 00 00 00 00 00 00 00 2f
<<< Not TLS data or unknown version (version=65277, content_type=22) [length 002f]
    03 00 00 23 00 00 00 00 00 00 00 23 fe fd 20 6a
    8b 18 ab d3 d4 dc e9 c0 af 37 3f 36 fb 66 1d 09
    f1 13 e1 8e 3d 14 13 2a c0 61 51 59 2c c7 47
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 01 00 b3
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 00b3]
    01 00 00 a7 00 01 00 00 00 00 00 a7 fe fd 58 a9
    96 d8 c2 a7 da 5d ef 21 66 05 09 b4 b4 5e 3f 38
    99 12 10 e3 fa 9c c2 2e 2d eb 08 74 1b a8 00 20
    6a 8b 18 ab d3 d4 dc e9 c0 af 37 3f 36 fb 66 1d
    09 f1 13 e1 8e 3d 14 13 2a c0 61 51 59 2c c7 47
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
<<< Not TLS data or unknown version (version=65277, content_type=256) [length 000d]
    16 fe fd 00 00 00 00 00 00 00 00 00 2f
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 02 00 b3
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 00b3]
    01 00 00 a7 00 01 00 00 00 00 00 a7 fe fd 58 a9
    96 d8 c2 a7 da 5d ef 21 66 05 09 b4 b4 5e 3f 38
    99 12 10 e3 fa 9c c2 2e 2d eb 08 74 1b a8 00 20
    6a 8b 18 ab d3 d4 dc e9 c0 af 37 3f 36 fb 66 1d
    09 f1 13 e1 8e 3d 14 13 2a c0 61 51 59 2c c7 47
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 03 00 b3
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 00b3]
    01 00 00 a7 00 01 00 00 00 00 00 a7 fe fd 58 a9
    96 d8 c2 a7 da 5d ef 21 66 05 09 b4 b4 5e 3f 38
    99 12 10 e3 fa 9c c2 2e 2d eb 08 74 1b a8 00 20
    6a 8b 18 ab d3 d4 dc e9 c0 af 37 3f 36 fb 66 1d

Then I ran the script on the main branch:

from smartthings_local.protocol.ocf_multicast import (
    discover_ocf_responder_ports,
)

result = discover_ocf_responder_ports(
    "192.168.4.27",
    interface_address="192.168.4.149",
)


print(result.ports)

It returned (49153,)

So I ran OpenSSL again:

openssl port 49153

$ openssl s_client -connect 192.168.4.27:49153 -dtls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256@SECLEVEL=0' \
  -cert certs/client.pem -key certs/client.key \
  -cert_chain certs/client_fullchain.pem -msg 2>&1 | head -60
Connecting to 192.168.4.27
CONNECTED(00000003)
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 00 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd ba f4
    6b 52 9a b0 cc 1b a2 06 f2 3f c7 4f c7 49 90 2d
    ce d9 87 fb cf 15 fe 59 57 82 06 3d 38 57 00 00
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 01 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd ba f4
    6b 52 9a b0 cc 1b a2 06 f2 3f c7 4f c7 49 90 2d
    ce d9 87 fb cf 15 fe 59 57 82 06 3d 38 57 00 00
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 02 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd ba f4
    6b 52 9a b0 cc 1b a2 06 f2 3f c7 4f c7 49 90 2d
    ce d9 87 fb cf 15 fe 59 57 82 06 3d 38 57 00 00
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 03 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd ba f4
    6b 52 9a b0 cc 1b a2 06 f2 3f c7 4f c7 49 90 2d
    ce d9 87 fb cf 15 fe 59 57 82 06 3d 38 57 00 00
    00 02 c0 2b 01 00 00 5b ff 01 00 01 00 00 0b 00
    02 01 00 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
    18 00 19 00 23 00 00 00 16 00 00 00 17 00 00 00
    0d 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08
    09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
    01 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05
    02 06 02
>>> DTLS 1.0, RecordHeader [length 000d]
    16 fe ff 00 00 00 00 00 00 00 04 00 93
>>> Not TLS data or unknown version (version=65277, content_type=22) [length 0093]
    01 00 00 87 00 00 00 00 00 00 00 87 fe fd ba f4
    6b 52 9a b0 cc 1b a2 06 f2 3f c7 4f c7 49 90 2d
    ce d9 87 fb cf 15 fe 59 57 82 06 3d 38 57 00 00


^C

Trying the previous script with sess.connect() on the discovered port fails differently:

Traceback (most recent call last):
  File "/Users/max/Downloads/samsung_iot/SmartThings-Local/test.py", line 25, in <module>
    sess.connect()
    ~~~~~~~~~~~~^^
  File "/Users/max/Downloads/samsung_iot/SmartThings-Local/smartthings_local/protocol/dtls_session.py", line 455, in connect
    raise SessionTimeoutError()
smartthings_local.errors.SessionTimeoutError: session operation timed out

[QuiteYellow]

@maxromanovsky, that capture was the thing I needed, and it points away from your certificate. Your certificate has still never been sent to the washer, so none of this is a certificate problem yet.

The cipher change worked. The washer is talking to you now.

What happens after that is a loop. The washer asks your laptop to prove who it is, your laptop answers, the washer asks again, your laptop sends the same answer, and around it goes until openssl gives up. That is the wall of repeated blocks at the end of your output.

To find out why, I need to see a detail that openssl refuses to print, however much of its output you keep. I checked that by rebuilding your exact situation on my own machine, so please do not spend time re-running it. A packet capture will show the detail:

sudo tcpdump -i any -n -s0 -X 'host 192.168.4.27 and udp port 49154' -w washer.pcap

Start that, run the same openssl command in a second terminal, then stop tcpdump after about ten seconds and attach washer.pcap here.

One other thing, and it may save you the capture entirely. You are using port 49154 because nmap showed it open. The washer publishes its own port, and the earlier probe only read the first chunk of that answer before stopping, so nobody has actually looked at it:

from smartthings_local.protocol.ocf_discovery import discover_ocf_secure_ports
print(discover_ocf_secure_ports("192.168.4.27"))

If that prints a port other than 49154, that alone could be the whole problem.