Decryption key not yet available

[tomdk]

I had everything working and then suddenly everything got encrypted.. :) I added a rs232 cable, read my key and generated my key file.

Now when I execute the same command, with adding the -k option ofcourse, it doesn't work anymore but I see a message "Decryption key not yet available".

What does this mean? Currently I retrieve the data via a tcpdump on my gateway triggered remotely from a raspberry pi.

ssh user@172.16.100.1 "sudo /usr/sbin/tcpdump -i eth1 -U 'tcp and host 172.16.100.16' -w -" | python semonitor.py -k 73224C4A.key -

[tomdk]

Example

dataLen: 002c dataLenInv: ffd3 sequence: 01bd source: 73114c4a dest: fffffffe function: 003d Discarding 140 extra bytes data: 5b 24 d6 c7 00 0a 84 7f 00 00 00 36 00 00 00 36 data: 00 27 02 11 4c 4a 78 8a 20 7e 8c b3 08 00 45 00 data: 00 28 7e df 40 00 39 06 b2 31 b9 79 47 25 ac 10 data: 64 10 56 ce 05 61 cb 2f 88 e5 00 01 ce 7b 50 10 data: ff 70 20 e3 00 00 5b 24 d7 3f 00 0a 38 6e 00 00 data: 00 78 00 00 00 78 78 8a 20 7e 8c b3 00 27 02 11 data: 4c 4a 08 00 45 00 00 6a 03 a7 00 00 40 06 66 28 data: ac 10 64 10 b9 79 47 25 05 61 56 ce 00 01 ce 7b data: cb 2f 89 27 50 10 08 68 13 a2 00 00 Decryption key not yet available Ignoring this message

[jbuehl]

The inverter periodically sends out a message that contains part of the key needed for decryption. If you start monitoring the data between these messages you will see the "Decryption key not yet available" message until the key message is received. At some point you should see a message that says "Creating decryption object with key" after which it should start decrypting the data. I forget how often the message is sent, but it shouldn't be longer than a minute or two.

[tomdk]

@jbuehl is the way that I want it to work ever going to work then? I'm feeding all tcp traffic that I find directly to semonitor.py. I feel like it's always going to have just parts of the messages then?

[jbuehl]

You can do passive ethernet monitoring like you want. You just have to wait a few minutes before the data is able to be decrypted. Note that you should not feed the captured data directly into semonitor.py without filtering out the TCP stream containing the SolarEdge data. If having the 'tcp and host 172.16.100.16' filtering on the tcpdump command doesn't work, you could try using a utility such as tshark as noted in the README.

tcpdump -i eth1 -U 'tcp and host 172.16.100.16' -w - | tshark -r infile.pcap -T fields -e data | ./utilities/unhexlify.py | ./semonitor.py -k 73224C4A.key -