T5 handshaker software#

I can provide much more information about exactly what is happening during the TLS handshake, but for now I'll save that for someone who is interested.Ĭan anyone suggest features or behavior of the HughesNet Gen5 service that might be contributing to this TLS handshake failure? What is the best method for getting the attention of technical engineers at HughesNet that could help diagnose and solve this problem? Any ideas that could help me chase down and solve this problem would be appreciated. The TLS handshake is performed using the Mbed TLS library ( ) which is solid and commonly used on embedded IoT products for encryption. Basic communication with the server at Amazon is not a problem by the time the TLS handshake fails, there have already been several rounds of back-and-forth communication with the server. I've tested our device on a HughesNet Gen4 connection and it works just fine, so the hangup appears to be specific to the Gen5 platform. So far, I've proven that network latency is not a contributing factor, DNS lookups are not part of the problem, and the state of the firewall and web acceleration features on the HT2000W have no effect on the problem.

The problem only happens over a HughesNet satellite link, so we purchased Gen5 equipment and entered a two-year HughesNet contract specifically to diagnose this problem. The TLS encryption handshake gets about 80% of the way through the process and then stops when an expected response from AWS never arrives. We have several customers that use HughesNet Gen5 HT2000W equipment where our product cannot communicate with AWS.

( ) The core of the system is a WiFi-enabled hub that communicates with Amazon's AWS IoT Core product.

T5 handshaker software#

keytool -import -alias gateway-identity -keyalg RSA -keystore gateway.jks -trustcacerts -file /etc/pki/tls/certs/Prod-A-HostFQDN.cer -storepass -import -alias gateway-identity -keyalg RSA -keystore gateway.jks -file /etc/pki/tls/certs/Prod-A-HostFQDN.cer -storepass -import -alias gateway-identity -keystore gateway.jks -file /etc/pki/tls/certs/Prod-A-HostFQDN.I am a software developer building an IoT water treatment product that is currently in soft release. All following are tried but I get the same error. Here is the command(s) I used to import Host specific certificate in the jks. 15:29:23,969 DEBUG nio.ssl (SslConnection.java:wrap(475)) - SSL NEED_WRAP i/o/u=0/0/0 ishut=false oshut=false no cipher suites in commonĪt .checkThrown(Handshaker.java:1431)Īt .checkTaskThrown(SSLEngineImpl.java:535)Īt .writeAppRecord(SSLEngineImpl.java:1214)Īt .wrap(SSLEngineImpl.java:1186)Īt .wrap(SSLEngine.java:469)Īt .(SslConnection.java:460)Īt .(SslConnection.java:386)Īt .$900(SslConnection.java:48)Īt .nio.SslConnection$SslEndPoint.fill(SslConnection.java:678)Īt .HttpParser.fill(HttpParser.java:1044)Īt .HttpParser.parseNext(HttpParser.java:280)Īt .HttpParser.parseAvailable(HttpParser.java:235)Īt .AsyncHttpConnection.handle(AsyncHttpConnection.java:82)Īt .(SslConnection.java:196)Īt .(SelectChannelEndPoint.java:667)Īt .nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)Īt .(QueuedThreadPool.java:608)Īt .thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)Ĭaused by: : no cipher suites in commonĪt .getSSLException(Alerts.java:192)Īt .fatal(SSLEngineImpl.java:1666)Īt .fatalSE(Handshaker.java:304)Īt .fatalSE(Handshaker.java:292)Īt .chooseCipherSuite(ServerHandshaker.java:1035)Īt .clientHello(ServerHandshaker.java:738)Īt .processMessage(ServerHandshaker.java:221)Īt .processLoop(Handshaker.java:979)Īt $1.run(Handshaker.java:919)Īt $1.run(Handshaker.java:916)Īt (Native Method)Īt $n(Handshaker.java:1369)Īt .(SslConnection.java:375)

Everything was working fine, when you start through Ambari but when I try to connect to Knox it doesn't work.Ĭhecked in the gateway.jsk under knox/data/security/keystore, it has a valid chain of certs. We have knox version 2.4.2.0-258 deployed in two environments.