SSL Handshake Error when trying to Sync

[ShaneIsrael]

handshake result -26624 mbedtls_ssl_handshake FAILED -26624 Last error was: -26624 - SSL - The operation timed out

When I try to sync, I get that error. I installed the visual studio redist and downloaded the latest release. Nothing I try will get it to work.

[BradyBrenot]

entertainment.cpp:372 mbedtls_ssl_conf_handshake_timeout(&conf, 400, 1000);

That's the start and end handshake timeout, in milliseconds. mbedTLS tries to complete the handshake in 400ms; if it can't, it tries again with increasingly longer timeouts until it eventually exceeds 1000ms and gives up.

Try increasing the max from 1000 to something even higher. The call to re-set the values to the library's default would be mbedtls_ssl_conf_handshake_timeout(&conf, 1000, 60000);

But when I tested on my LAN, even over wifi, I found this timeout was way too long. If the handshake takes more than 1000ms it's probably never going to complete. Maybe my LAN isn't representative enough though.

See also mbedTLS' documentation: https://tls.mbed.org/api/ssl_8h.html#a6625bc4e7ffd535900ef53259cc21651

[BradyBrenot]

It's also possible that the bridge is refusing to listen because the connection attempt is coming too long after EntertainmentGroup::askBridgeToToggleStreaming told the Bridge to enable streaming, or something is just plain wrong with the request to enable streaming. I'm not sure how / why either situation would be happening.

It's also possible that the bridge isn't listening because the firmware needs to be updated or it's a gen 1 bridge -- and thus doesn't support Entertainment at all -- but I'm hoping you already ruled that out? 🤷

[ShaneIsrael]

I am definitely on a 2.0 bridge I made sure. I also updated the firmware to the latest and still got the same issue. I tried both connecting to my 2.4ghz and 5ghz network and neither made a difference.

The program connects to the bridge just fine and shows my entertainment groups but as soon as I try to sync it fails that handshake. Is there any reason it needs to do a handshake before sync'ing and not before connecting to the bridge or retrieving the entertainment groups?

[BradyBrenot]

To use the Entertainment API, you:

1. Locate the bridge, register on it if necessary.
2. Tell the bridge to to enable streaming for an entertainment group. This uses a normal old RESTful HTTP API.
3. Within maybe a minute of doing (2.), make a DTLS "connection" by completing a handshake with the bridge. Use the key you got when you registered with the bridge in (1.)
4. Stream light data over UDP (encrypted with DTLS) until you're done
5. Tell the bridge you're done, or simply stop streaming for a couple minutes or so.

So what's succeeding is the plain old HTTP connection (TCP, port 80), what's failing is the UDP / DTLS portion. For some reason.

[ShaneIsrael]

Hmm. I wonder if its a router issue. Im using a netgear nighthawk x6. Maybe for some reason udp traffic is blocked. Ill have to check when I get home.

On Mar 19, 2018 5:06 PM, "Brady Brenot" notifications@github.com wrote:

To use the Entertainment API, you:

1. Locate the bridge, register on it if necessary.
2. Tell the bridge to to enable streaming for an entertainment group. This uses a normal old RESTful HTTP API.
3. Within maybe a minute of doing (2.), make a DTLS "connection" by completing a handshake with the bridge. Use the key you got when you registered with the bridge in (1.)
4. Stream light data over UDP (encrypted with DTLS) until you're done
5. Tell the bridge you're done, or simply stop streaming for a couple minutes or so.

So what's succeeding is the plain old HTTP connection (TCP, port 80), what's failing is the UDP / DTLS portion. For some reason.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BradyBrenot/huestacean/issues/59#issuecomment-374415898, or mute the thread https://github.com/notifications/unsubscribe-auth/ABmXj0rukZWYxc9LiMblpYsVlhG78LeGks5tgDn9gaJpZM4SvhNu .