⚠ Gateway software version 21.20.2 seems to break the Powerwall plugin on Linux

[Dr. McKay]

This post will contain some speculation.

My gateway received version 21.20.2 today, and the HS plugin stopped working. Every request resulted in this error message: "Authentication failed because the remote party has closed the transport stream."

I'm using mono 6.12.0.90 on Ubuntu 20, but the plugin still worked for me on Windows. All signs pointed to a TLS incompatibility, but the plugin was already using TLS v1.2 and .NET has supported TLS v1.2 for years at this point.

I ran tcpdump to capture the TLS handshake, and found that the gateway closed the TCP connection immediately after the TLS Client Hello message, meaning that the gateway didn't like something in the hello. I also noticed that while the TLS version in the handshake was 1.2, the version in the record layer was 1.0.


I also ran Wireshark on Windows to see if this was different, and it was:



So I checked into why this might be the case, and whether it's possible to change this. I came across this issue on GitHub, where an OpenSSL team member explains that it's perfectly valid to use an older version in the record layer, and that the version in the handshake is the version that should be treated as authoritative. So, it seems to me that Tesla's software is improperly checking the version in the record layer and rejecting older, insecure TLS versions, despite the fact that those connections are in fact valid and secure TLS 1.2 connections.

I was able to establish a connection using curl (which is built against openssl), so it does seem as though openssl matches the versions in the two layers, but I suppose that the BoringSSL fork of openssl mono is using hasn't received that change. Which means, as far as I can tell, that it's not going to be possible to get this working again on Linux unless Tesla fixes their problem.

I will continue to investigate workarounds for this, but in the meantime I suggest that if you're experiencing this problem and you're able to, run the plugin on a Windows PC. Here's how you can do that:

1. Download the latest release from GitHub
2. Unzip the file you downloaded
3. Download the support files: Support files.zip
4. Unzip the support files into the same folder as HSPI_TeslaPowerwall.exe
5. Right-click inside that folder and choose New > Shortcut
6. Browse to HSPI_TeslaPowerwall.exe
7. Once you've selected HSPI_TeslaPowerwall.exe, before you click next, click in the text box and after the last quotation mark, enter: server=1.2.3.4
   • Replace 1.2.3.4 with your HomeSeer server's IP address
   • You can find your HS server's IP address in HS4 by going to Tools > Help, and check the "Lan IP" under the help desk section
   • Refer to this image to see how your shortcut should look
8. Click next, then finish
9. To start the plugin, double-click on your new shortcut

Once you run the shortcut, a console window will open with output similar to this:

Connecting to HomeSeer...
Connected to HomeSeer
Waiting for initialization...

If you see that, then go into HS and check to make sure the plugin is working. Don't close the console window, as that will stop the plugin.

I realize this is all really inconvenient, and I'm looking into workarounds.

[Dr. McKay]

Update: Looks like some of my assumptions were incorrect. It doesn't appear to actually have anything to do with the TLS version passed in the record layer; instead it appears that the gateway is rejecting connections bearing SNI. More info available at this thread on TMC.

So now I'm looking into whether it's possible to disable SNI. I have my doubts, since it appears that it's not a standard .NET thing, as .NET on Windows is not sending SNI for IP addresses while mono is.

[dwolf725]

Any updates on this? Are the tls proxy steps the only option?

[Dr. McKay]

For now, the proxy is the only option while we hope that Tesla fixes it on their end.