My hub is in a constant boot loop I can see it go red, banking blue light, steady blue light for a while and then continue the process. Happened yesterday while my family was sleeping I got a SMS the hub was disconnected and with so many status messages about problems I ignored it until I tried to change status. Tried changing the USB cable, power brick, ethernet cable, connected directly to the modem, I can see it gets an IP. Will put a TAP and do a packet capture next. Is it possible to JTAG it and ten a console to look at messages? Contacted support and they went through the same steps as I and said they did all they could. I emailed support and going again through the same stars just slower than in chat. Hope I can get it replaced, been less than year and the 2.0 hub is not out yet.
an a packet capture and I see TLS 1.2 error 21 reported, that error means:
Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.
I can see the hub get an IP, do an ARP for the its gateway, do a NTP request and update its time, make the DNS lookup for the smartthings server. gets the CNAME for it, resolves the CNAME, does a TLS 1.2 handshake and then fail with the error 21.
Wonder if they did some bad OpenSSL patching.
Interesting, as bad patch would effect everyone… my hubs not rebooting.
Too bad there isn’t a way to force a firmware reload, that I know of anyway.
sen the PCAP to support no clue what they will make of it or if they will offer to replace my hub under warranty since it has less than a year with me. I even have more Z-Wave gear arriving next week
5 day down, they say it is a networking issue on their end and that they are looking in to it. Hope it gets fixed soon.
Seems I’m down the creek without a paddle, 3 weeks down, replaced hub, replaced cable modem and even replaced all cabling and nothing. Provided Smartthings support with PCAPs showing I can reach the servers and connected on another ISP but when I do the same from mine I see it connect, negotiated, talk and end the connection. If initial connection is made on another ISP and I do not let the hub reboot and connect it to my ISP it works like a charm until something happened in the AM that resets the connect always close to midnight PST. Provided them my IP range. Not much else I can do sad I can not pay for faster dedicated support to get it fixed.
Just curious, which ISP are you using?
ok I think problem may be NTP, I asked the ISP to check if they are blocking it. On my neighbors ISP where it works:
On my ISP where it fails
so far a hunch, I know NTP is used in DoS attacks and I do not know if it is blocked by my ISP or someone further upstream since it is common when DoS attacks happens like what happened to GitHub. sent info to support but they have had it for a while no clue if they saw that or if it is relevant waiting for them to reply via email.
Looks like your neighbors ISP is using a smarter approach to limiting NTP DoS attacks by using DSCP 12 tagging, vs your ISP that’s decided to just drop it. Are any devices in your network able to sync with NTP?, can you alias the ST NTP server to another one that it allowed?
I just started having this issue today. I power cycled my hub as instructed by the SmartThings support page for troubleshooting Philips Hue. Since then, solid blue light. I tried moving my hub’s IP into my router’s DMZ, still solid blue. I’ve rebooted dozens of times. Finally I moved the hub to a managed switch and with port mirroring I’ve been getting full PCAPs. It appears to be the same issue your faced (which I don’t believe has anything to do with NTP servers). I’m getting the SSL handshake terminated prematurely by the far end (Amazon EC2 / SmartThings). I get a TLS alert 21, followed by a TCP FIN, ACK, then two TCP RSTs which end the communication.
Update, the far end is fw-update.smartthings.com. 60 IN A 22.214.171.124 So this could be related to a failed attempt to check for new firmware.
After being offline for over hours, hub came back 6 minutes ago (12:10AM Eastern, 2017.02.01). My Hub was running version 000.016.00009 (16.9) when the issue occurred. As many of you know, this version had a backup battery drain bug, so Samsung rushed out a fix in 16.12. “On Monday, January 30, between 11:00 am EST and 2:00 pm EST, we will automatically update your SmartThings Hub to the latest firmware (version 0.16.12)” (that’s yesterday for me). Lo and behold, my hub is now running a previously unannounced firmware version 000.016.00013 (16.13). My conclusion? The update process for 16.12 failed and nearly bricked my (and probably other peoples’) hubs, and they patched the problem in 16.13.