Connection to Tesla Powerwall not possible anymore after Powerwall update

[moritzlerch]

Hey, any updates on this? I'm getting an _wait_for_handshake: failed unfortunately, too. Please look at this:

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: ESP-12F
• Core Version: SDK:2.2.2-dev(38a443e)/Core:3.0.1=30001000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-48-g7421258/BearSSL:c0b69df
• Development Env: Platformio
• Operating System: Windows

Settings in IDE

• Module: Wemos D1 mini r2
• Flash Mode: qio
• Flash Size: 4MB
• lwip Variant: v2 Lower Memory
• Reset Method: ck
• Flash Frequency: [40Mhz]
• CPU Frequency: 80Mhz
• Upload Using: SERIAL
• Upload Speed: 115200

Problem Description

So I got problems to do the handshake with my tesla powerwall (solar battery storage system) which I'm doing a project with. The powerwall did an update and unfortunately as described I can not connect to it anymore. I'm getting the _wait_for_handshake: failed error. However, if I try that request with curl on my PC it works just fine. Raspberry Pi also works. So problem has to have to do with the BearSSL-WifiClientSecure library.

Getting stuck here:

(In my project in lib/Powerwall/Powerwall.h:54)

powerwall_ip = "192.168.178.38"

WiFiClientSecure httpsClient;
httpsClient.setInsecure();
httpsClient.setTimeout(10000);
int retry = 0;

while ((!httpsClient.connect(powerwall_ip, 443)) && (retry < 15)) {
    delay(100);
    Serial.print(".");
    retry++;
}

if (retry >= 15) {
    return ("CONN-FAIL");
}

Debug Messages

(DEV: doing GET-request to 192.168.178.38/api/system_status/soe)
:ref 1
BSSL:_connectSSL: start connection

_iobuf_in:       0x3fff1744
_iobuf_out:      0x3fffb2a4
_iobuf_in_size:  16709
_iobuf_out_size: 597
:wr 137 0
:wrc 137 137 0
:ack 137
:rcl pb=0 sz=-1
:abort

BSSL:_wait_for_handshake: failed
BSSL:Couldn't connect. Error = 'Unknown error code.'
.:ur 1
:dsrcv 0
:del

Debugging

I did some debugging with a friend and from the _wait_for_handshake function (bool) in the WifiClientSecure-class we got to the _run_until function and searched for the -1. We found out the connection is crashing here:

if (!(_client->state() == ESTABLISHED) && !WiFiClient::available()) {
  return (state & target) ? 0 : -1;
}

After this we just outputted the values of state and target via DEBUG_BSSL and found out they were 4 and 8. So they are not matching with the binary-and (&) so this has to be the problem.

These would be the two values:

/** \brief SSL engine state: engine may receive records from the peer. */
#define BR_SSL_RECVREC   0x0004
/** \brief SSL engine state: engine may accept application data to send. */
#define BR_SSL_SENDAPP   0x0008

Probably someone can help.

[earlephilhower]

Try running at 160MHz, not 80. The powerwall may be dropping the connection before the ESP8266 has had a chance to respond.

[moritzlerch]

I already tried that. It talked with a few people and we think it could be SNI. What do you think about that?

[earlephilhower]

You'll have to capture the network packets to dig into it, then. There is a netdump library you can pull in, see the examples. A full MCVE and dump w/full debugging enabled on the 8266 could be interesting. You might have some other problem in the code unrelated to SSL (OOM, etc.) where it's now failing.

If you're crapping out on the 1st packet sent to the powerwall it's not SNI because that would happen later. The 1st message is a ClientHello which has very limited info in it (see https://datatracker.ietf.org/doc/html/rfc6101) related to supported TLS versions, ciphers, etc. After the ServerHello response, then the client would send something related to SNI etc.

You could also use WireShark on the RPI and capture the curl handshake and trace what's going on in a successful connection and correlate to BSSL. WireShark can parse the TLS handshake sequence nicely, saving you the trouble of manually digging out bitfields.

[earlephilhower]

@moritzlerch any info or update?

[moritzlerch]

No, not yet. I got home from vacation yesterday. Maybe I'll try doing your recommendations tomorrow.

[gemu2015]

i also have this issue. Like @moritzlerch i did query the powerwall api successfully for about a year (however with an ESP32) i get the very same error on connecting. i struggled a long time to get WLAN traffic captured with no success. now i bought an ethernet esp32 board and could finally capture the traffic between ESP and powerwall. however i can't figure out what goes wrong. i append the Wireshark capture file in the hope that somebody can help here.
powerwall.pcap.zip

[HKropfeld]

Since I tried to access the Powerwall 2 API with an ESP32 (Arduino IDE), I got to the same problem.
After analysation of different Wireshark protocols, I figured out that the extension "server_name" in the TLS1.2 Client Hello message of the ESP's has an issue. This extension is used to tell the server the server name that shall be contacted within the IP address of the server.
You and me tried to contact the Powerwall via its IP address, not with its name.
Browsers like Firefox do not send the server_name extension in the Client Hello in this case. But the ESP32 fills the server_name extension field with the IP address of the Powerwall. I tried again with the hostname of the Powerwall instead (my local router Fritzbox acts as nameserver), and guess:
The Tesla Powerwall replies to the Client Hello with Server Hello, and the complete TLS1.2 handshake continues. :-)

[gemu2015]

@HKropfeld
thanks for this hint! this indeed did solve the problem with ESP32.
on ESP8266 however the problem persists with the same error condition.
do you have an idea where to change code to solve this also ?

[HKropfeld]

Unfortunately, I only have a ESP32, using Arduino IDE 2.0.4 with library "esp32 by Espressif" version 2.0.7. This library uses MBedTLS.
Some months ago, I borrowed an ESP8266 board, used the library "esp8266 by ESP8266 community" which uses the BearSSL for SSL connections. I figured out that both implementations create different TLS1.2 Client Hello messages, but I failed with both because I used the IP address of the Tesla gateway instead of a name.
Therefore, when I succeeded on my ESP32, I guessed it would also succeed on a ESP8266. If not, you would have to do further investigation on the network protocol with Wireshark.