Ask the appliance for its DTLS port before sweeping for it

[QuiteYellow]

Discovery now reads the device's own /oic/res directory first and takes the secure port from it. That resource is mandatory on every OCF device and must be reachable without DTLS, so one exchange yields the port. Two other fixes come with it: a probe bug that let a wrong port pass as proven, and a handshake collision that was reported as a fault.

Six commits, each standing alone. Validated on a dryer and an oven over several stop/start cycles.

The probe was counting the wrong port

probe_dtls_ports read "a reply arrived after dialling port N" as proof a DTLS server listens on N. An OCF stack binds its DTLS socket to port 0 and answers a first flight from that ephemeral port whatever port was addressed, and the probe's socket filters inbound on host only, so every port dialled looked live. Docker's bridge NAT had been discarding the mismatched replies and standing in for a correctness check the probe never had.

Selection now runs on the port a reply came from (responder_port). Measured port by port, exactly two ports answer on each appliance here: the standard CoAPS port 5684 and the ephemeral DTLS port, both replying from the ephemeral one. TizenRT's iotivity_1.2-rel fork, which these appliances run, binds 5684 as its secure multicast socket on INADDR_ANY (caipadapter.c:206 at pin e590f30ab), so a unicast ClientHello addressed there lands on that socket and is answered from the ephemeral secure one. The old code called those two separate listeners and reported 5684 for an appliance whose port is 49155.

Ask before sweeping

_resolve_port now runs pinned OCF_PORT → cached port → /oic/res on 5683 → band sweep, and every tier's answer goes through the same probe_dtls_ports gate, so an advertisement is only dialled once it has answered one. That matters: a live read here has returned sec: true, port: 0, because the stack binds port 0 and learns the assignment afterwards.

The band stays. 5683 is mandated only as the multicast listen port; it answers unicast because every OCF stack read here, classic included, wildcard-binds that socket, which is a strong convention with no clause behind it. And a device whose plaintext port is not 5683 has no directory for this tier to read. On the bench the fallback earned its keep unprompted: after one dropout the dryer's plaintext port stayed silent while its DTLS port recovered, and the sweep is what found it. Blocking the route to 5683 makes that path deterministic rather than opportunistic: both appliances log no_ocf_response after four attempts and resolve on the sweep, so a dead directory costs one bounded read and falls through.

_ports_from_links also now reads both advertised forms from one answer. Both appliances here are OIC 1.1, answer 4.06 to an OCF 1.0 Accept, and carry no eps key anywhere, so the real port arrives only as p.sec/port on the doxm link. The old split looked for eps on the first read and p.sec/port only on a second, filtered one, so every such device paid a wasted round trip. The doxm narrowing is unchanged and is the point: an eps URI is validated against the address the response came from, where a bare p.port integer carries no address, so it is read only from the link that has to describe the device's own secure endpoint. Nothing here has produced an eps entry, on hardware or in a report, so that path stays unexercised.

Say which tier chose the port

Four paths can pick it and only one logged anything. Each now names itself (configured OCF_PORT, cached from an earlier connect, advertised by /oic/res on 5683, found by sweeping the OCF band), because a swept port means the directory read got nothing out of that device, and that is the detail a bug report turns on.

A peer that opens its own handshake is not a fault

After the bridge has been away, the dryer answers its ClientHello with a ClientHello of its own, and OpenSSL, being the client, rejects it. That read as session error: session operation failed, a warning, an error_count bump and a backoff, for something that clears itself in about two seconds.

These appliances run TizenRT's iotivity_1.2-rel fork, which their own device log names. There, CAencryptSsl opens a session itself when it has a message for an endpoint it holds no peer for. That is how an appliance comes to dial the bridge: it still holds the fixed local port from the previous session. GetSslPeer keys the peer table on address and port with no role, so the bridge's ClientHello is stepped into that client-role context, and the failure path skips the alert for MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO and removes the peer. The device answers with silence and drops its half, which is why the next handshake succeeds. A per-record trace confirmed the prediction: the peer's ClientHello arrived and no alert came back.

connect() now raises PeerInitiatedHandshakeError when an inbound epoch-0 ClientHello preceded the failure, logging at info, and the bridge retries after 0.5s without touching error_count or growing the backoff.

Dropping the peer's ClientHello and carrying on was tried and rejected: the device sends nothing once it has consumed the bridge's, so recovery would still wait on OpenSSL's retransmit. It was armed on hardware for two cycles and never fired.

The demo bridge moves to host networking

Bridge NAT keys its conntrack entry on the port dialled, so a reply from any other port reads as an unrelated new inbound flow and the kernel drops it. That silently rules out the 5683 path, which is how standard-port firmware and non-Samsung OCF devices are reached. Symmetric DTLS to a known port traverses NAT fine, which is why this ran bridged for so long with the gap staying hidden. Safe only because of the responder-port fix, so the commit order matters.

Notes

• 824 tests pass, 20 added. docs/api.md is regenerated; PeerInitiatedHandshakeError is in tools/api_contract.py because callers catch it by name to drive the retry.
• docs/appliance-compatibility.md, docs/ocf-pki-laundry.md and docs/bridge-demo.md are corrected in the last commit. They told readers that a reply after dialling a port proved a listener on it, and described discovery as a sweep of the band. The compatibility page now also says that a silent 5683 is worth a second look, since the answer comes from another source port.
• Hardware here is two OIC 1.1 appliances. The 5684 observation and the directory shape are n=2, and no standard-port or newer-PKI device has been tested.

Since the first push

Review of the branch found five things. The first three are fixed in 86ab57d, the fourth in a448a5b, the fifth in a3d6b5f.

The peer-initiated retry had no cap. An appliance that kept refusing drove a 2 Hz handshake loop for as long as it kept refusing, with error_count at zero throughout, so the health topic reported a healthy bridge. 200 consecutive collisions through the loop harness gave 200 immediate retries. Four still take the fast path, and past that a collision counts as a fault and takes the jittered backoff; a session that runs clears the count.

The fixed DTLS source port moves from 49700 to 26849. Host networking binds it on the host, and 49700 sits inside the default net.ipv4.ip_local_port_range of 32768-60999, where an unrelated process can hold it and the bind fails EADDRINUSE. Under bridge networking that bind was isolated in the container's namespace, which is why the old base was fine until this commit and is not after it.

A reply whose source port went unrecorded fell back to the port dialled. That fallback could not be reached through the real socket, and its only behaviour was to restore the rule this branch replaced, so it now reports unreachable. Two tests that selected on the dialled port went with it, each already having a counterpart written for the responder rule.

Both comments explaining the fixed DTLS source port credited RFC 6347 §4.2.8 eviction, where a re-handshake on the old 5-tuple makes the device discard a stale association that a device-side timer would otherwise reap. That mechanism is tinydtls's. The firmware these appliances run has neither the path nor the timer; what it has is a peer table with no cap, no idle timeout and no LRU, so the argument for one fixed port is the opposite shape. Reconnecting from a fresh ephemeral port each time leaves the old entry live and piles up mbedTLS contexts. Reconnecting over an entry the device still holds destroys the stale peer, since a ClientHello is not application data it can read, and that was measured at one extra ClientHello on the dryer and nothing on the oven. The dtls_session comment also credited the oven result to RT-OCF, which is not the stack that oven runs. The behaviour is unchanged either way.

The comment on the peer-initiated handshake cited IoTivity classic ca_adapter_net_ssl.c:1520 CAencryptSsl. 1520 is the upstream number, and in the fork these appliances run CAencryptSsl is at 2010 with its InitiateTlsHandshake call at 2040, so following that citation into the right tree landed hundreds of lines away. GetSslPeer (1074) and SSL_CHECK_FAIL (215, with the BAD_HS_CLIENT_HELLO test at 247) now carry numbers too. The family label was the other half of the problem: upstream sets VERIFY_REQUIRED and carries no ECDHE-ECDSA-AES128-GCM-SHA256, yet these appliances complete a session on an empty client certificate using exactly that suite, so upstream answers this question wrongly. Two mentions of the stack in this description are corrected the same way.

825 tests pass, which corrects the count above.

Since the rebase

Rebased onto main. The fork-naming pass merged there in the meantime reached the same dtls_session comment this branch rewrites, so the two collided; the resolution keeps this branch's text. That comment used to close on two corrections, and main has since made the RT-OCF half itself, so the note now states only the RFC 6347 §4.2.8 one.

Two comments this branch had left misplaced are tidied with it. The jitter note in run_forever sat above the immediate-retry branch, several lines away from the wait it describes. The new paragraph on the fixed source port ran straight into the one explaining why the base sits below 32768.

871 tests pass, 27 of them added here. The counts earlier in this description predate the rebase.