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

• [x] This issue complies with the issue POLICY doc.
• [x] I have read the documentation at readthedocs and the issue is not addressed there.
• [x] I have tested that the issue is present in current master branch (aka latest git).
• [x] I have searched the issue tracker for a similar issue.
• [x] If there is a stack dump, I have decoded it.
• [x] 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