Open source CCS using AR7420

[uhi22]

I have a couple of questions about sniffing if you're able to help. When you sniffed traffic, did you sniff it encrypted, then decrypt later. or did you sniff the network key, and quickly install it into the chip in order to sniff the rest of the communication?

Hi, I was long time not here and see a good progress, thanks for this
The sniffing on my side only turned-out the unencrypted traffic. This means, I see the SLAC sequence, but nothing more. This is clear, because without using the correct NMK, the adapter will not give anything of the encrypted traffic to the ethernet port.
The plan was, to extract the NMK "live" and directly write it. But the used devolo adapter seems not to support the SET_KEY. I have now a new pair of TL-PA4010P on my desk, they contain an AR7420. I'm preparing them to run on battery power and plan to give a try. What you did, looks promising, hopefully I do not have a different firmware.

[catphish]

Hi, I was long time not here and see a good progress, thanks for this
The sniffing on my side only turned-out the unencrypted traffic. This means, I see the SLAC sequence, but nothing more. This is clear, because without using the correct NMK, the adapter will not give anything of the encrypted traffic to the ethernet port.
The plan was, to extract the NMK "live" and directly write it. But the used devolo adapter seems not to support the SET_KEY. I have now a new pair of TL-PA4010P on my desk, they contain an AR7420. I'm preparing them to run on battery power and plan to give a try. What you did, looks promising, hopefully I do not have a different firmware.

Yes, if you can write the code, the correct solution is absolutely to sniff the network key from the SLAC responses, and then immediately apply it, which should then let you sniff the remaining traffic.

[uhi22]

After some experiments, I can confirm, that the "negative" response for the CM_SET_KEY is in fact a positive sign. They key is accepted, the LEDs are going off and on (looks like the device is resetting) and the CM_GET_KEY works and retrieves the same key. This is good news.
But the bad news is, that my version of the AR7420 seems not support the reception and transmission of the SLAC commands. With an old devolo adaptor, I'm able to read the SLAC procedure, but also this device does not transmit SLAC commands.
My impression is, that the AR7420 uses a "too new" firmware. The documentation of the github.com/qca/open-plc-utils contains a table (in /docbook/ch01s10.html), which mentions the slac as "deprecated". Maybe they removed it from the firmware later. Using the command int6klist -ieth0 -v my device tells me "MAC-QCA7420-1.4.0.20-00-20171027-CS". Looks like from year 2017, while the docu (/docbook/ch04s08.html) talks about a "MAC-QCA7420-2.5.14.2259-23-20110621-FINAL". Could you check, which version you have, @catphish?

[catphish]

After some experiments, I can confirm, that the "negative" response for the CM_SET_KEY is in fact a positive sign. They key is accepted, the LEDs are going off and on (looks like the device is resetting) and the CM_GET_KEY works and retrieves the same key. This is good news.
But the bad news is, that my version of the AR7420 seems not support the reception and transmission of the SLAC commands. With an old devolo adaptor, I'm able to read the SLAC procedure, but also this device does not transmit SLAC commands.

I seem to have been astonishingly negligent with my documentation here. I tried with a number of different firmwares, and I haven't made a note of which one worked. If I remember correctly, It's also necessary to explicitly configure the device's EEPROM to enable SLAC (EV or EVSE mode) before you can use it. I will find the exact firmware I'm using along with the commands to configure the PIB file appropriately and post again shortly.

The issue with the SUCCESS vs FAILURE responses is confirmed / discussed here: https://github.com/qca/open-plc-utils/issues/161

[catphish]

Here we go, I did document it, it's just buried in a code block above:

Code: Select all

charlie@charlie-ThinkPad-T14:~/open-plc-utils/slac$ plctool -aI -ienp0s31f6
enp0s31f6 00:B0:52:00:00:01 Fetch Device Attributes
enp0s31f6 14:CC:20:4D:B7:C3 QCA7420-MAC-QCA7420-1.5.0.26-02-20200114-CS (1mb)
	PIB 0-0 8836 bytes
	MAC 14:CC:20:4D:B7:C3
	DAK 91:F1:F8:7C:DD:DC:47:06:59:C1:64:BF:53:19:94:36
	NMK 3F:94:65:6F:A8:20:42:42:A0:90:26:C7:93:9F:1F:C5
	NID 44:EB:DC:73:F9:76:0B
	Security level 0
	NET Qualcomm Atheros Enabled Network
	MFG tpver_401013_171025_901
	USR PEV
	CCo Never
	MDU N/A

The version I am using is "FW-QCA7420-1.5.0.0026-02-CS-20200114" from 2020 which I believe is the latest.

Can you confirm whether you modified and re-flashed your PIB according to this procedure (from docbook/ch05s15.html)?

Code: Select all

#!/bin/sh
# file: pev.sh
# ========================================================================
# convert a factory PIB to a SLAC PEV PIB by changing these PIB settings;
# ------------------------------------------------------------------------
setpib ${1} 74 hfid "PEV"
setpib ${1} F4 byte 1
setpib ${1} 1653 byte 1
setpib ${1} 1C98 long 10240 long 102400

I'm attaching the firmware and PIB files I use (I'm not sure which of the PIB files is correct, but they all seem to have the PEV config in them). If all else fails, simply flashing your chip with one should result in a unit identical to mine (MAC address included).

Use the above command "plctool -aI -ienp0s31f6" (with your correct ethernet interface) to confirm the settings.

[uhi22]

Thanks a lot. The key was the hint with the PIB file. Reading the documentation would have helped, I was not expecting such a helpful tool chain. Now I know it better.
As fast try-out, I kept my firmware the same, and only read, patched and wrote the PIB with the settings for EVSE. And: It talks to my car. Not fully to the end of the SLAC sequence, but at least to the CM_ATTEN_CHAR.IND and RSP. This is a big progress. Many many thanks again.

[catphish]

Thanks a lot. The key was the hint with the PIB file. Reading the documentation would have helped, I was not expecting such a helpful tool chain. Now I know it better.
As fast try-out, I kept my firmware the same, and only read, patched and wrote the PIB with the settings for EVSE. And: It talks to my car. Not fully to the end of the SLAC sequence, but at least to the CM_ATTEN_CHAR.IND and RSP. This is a big progress. Many many thanks again.

Fantastic! Note that in my testing, PEV mode worked 100%, but in EVSE mode, the AR7420 could not correctly interpret the sounding messages. I had to fake the signal strength responses in CM_ATTEN_CHAR.RSP. Attached is my diff (likely only the change to evse_cm_mnbc_sound.c matters).

Good luck and let me know how far you get with it. I somewhat gave up as I have no ongoing access to either a vehicle or a charger with real CSS, but I hope someone else can pursue this now we have readily available hardware.

[uhi22]

Progress: Thanks to the valueable hints, now the communication to my car is established, it is sending UDP broadcasts to port 15118, this looks like a hint in which specification we will find the next steps. Instead of using the C code from the qca/open-plc-utils, I started from scratch in Python. For the moment, I ended up in only three not-too-complex files, instead of the hundreds. Here it is: https://github.com/uhi22/pyPLC
Different roads are still to go: Finding a way to sniff both directions of communication on a real charger with a real car. And studying the upper-level protocols...

[uhi22]

Regarding the sniffing, seems I'm stuck. Setting the NMK and NID based on the SLAC_match.confirmation works fine, the sniffer joins the network of charger and car, I can read the software versions of the QCAs of the charger and the car. This is a big step forward. But: The sniffer does NOT route the UDP/TCP traffic to its Ethernet port. It behaves like an Ethernet switch, which also routes only "relevant" traffic to each port, and clearly addressed traffic is sorted out as "not relevant" for the third participant. Bad for sniffing. There seem to be hidden options, to configure the AR7420 to route everything, but for the moment I did not find a useful hint. Maybe it is possible to read a PIB and/or sniff the configuration traffic of a professional sniffer, but I do not have one.

Regarding evse mode and pev mode, the way seems to be clear. Up to the transport protocol (TCP, UDP, V2GTP) everything is easy. Above there is the EXI (compressed XML), which is horror, but there are some existing solutions available, which may be re-used. If this is done, only some xml-composition and -decomposition, and the charging state machine is missing. From current point of view, this looks like some effort, but not like a big question mark.

[uhi22]

Short update: The EXI decoder/encoder is running quite well, and in EvseMode the project is talking to my Ioniq car until the PreCharge loop. This means, from software point of view it is not far away to charge the car. I'm not planning to construct charger hardware, so this direction of the project is near to its goal. The other direction is to implement the vehicle side of the communication, to be able to talk to a real charger. For this, the draft is implemented, some parts are still missing (SDP, filling some messages). Hope to come up with first results from a real charger in the next days.
The latest code and state is available here: https://github.com/uhi22/pyPLC

[catphish]

Short update: The EXI decoder/encoder is running quite well, and in EvseMode the project is talking to my Ioniq car until the PreCharge loop. This means, from software point of view it is not far away to charge the car. I'm not planning to construct charger hardware, so this direction of the project is near to its goal. The other direction is to implement the vehicle side of the communication, to be able to talk to a real charger. For this, the draft is implemented, some parts are still missing (SDP, filling some messages). Hope to come up with first results from a real charger in the next days.
The latest code and state is available here: https://github.com/uhi22/pyPLC

This is awesome, thank you for pursuing this! It's great to hear you were able to get the EXI encode / decode working. That part scared me!

I'm more interested in the vehicle implementation, and I'm sure others here will be interested if you get that far.

[celeron55]

I'm following with great interest. This project is going to be legendary if it succeeds.

[Pete9008]

Also following with interest!

I'd like to build a home CCS charger (only low power to avoid the need for an on board AC charger) and this would be ideal

Have you got to the point where you have a simulated EVSE talking to a simulated car yet?

[johu]

Pete wants to procrastinate more and write another simulator

[Pete9008]

It's not procrastination, it's preparation (well mostly, but it has been effective procrastination!)

Edit - and er no, I've had enough of simulators (and software) for now!

[uhi22]

Have you got to the point where you have a simulated EVSE talking to a simulated car yet?

Yes and no. The project is designed to play both roles, EVSE and car. To work on the project, I just open two console windows on the same machine, start in the first window the EVSE with "python pyPlc.py E" and in the second the PEV with "python pyPlc.py P", and see how they talk to each other. So to say the "poor mans simulation". Next level would be, to use two different machines, and connect them via the homeplug modems. And the final level would be to also add the electronics for handling of the 12V PWM. These two "enhanced simulation levels" I do not use at the moment. Just concentrating for now to get the high-level communication as good as necessary, and to try it out with real car (was successful until the precharge) and with a real charger (coming soon). And then to compare the recordings from the real-life-sessions with the simulation and improve both sides of the project.

Do we know of other simulation projects, which I could use to test against?

[Pete9008]

Thanks, sounds like both you and catphish have made excellent progress on this

Looks like I need to get a pair of TL-PA4010 modules. Are any versions better of worse suited to this, or any to avoid?

Not aware of any other simulators but then fairly new to all this so that doesn't mean much!

[catphish]

Looks like I need to get a pair of TL-PA4010 modules. Are any versions better of worse suited to this, or any to avoid?

As far as I know, all TL-PA4010 devices use the AR7420 so any will work. Just buy the cheapest pair you can find on eBay

Note that if you just want to work on the software, you don't need to disassemble them, you can just use a pair plugged into the mains, but if you want to hook them up to a car or EVSE, you will need to pull them apart and connect up a 12v power supply as shown in the photos at the top of this thread,

[uhi22]

Exactly. It even runs from a 5V USB power bank, if this makes things easier.
https://github.com/uhi22/pyPLC/blob/mas ... ardware.md
I'm using the TL-PA4010P (with P in the end). As far as I understood it is only mechanical difference, the P means "Pass-Through", it has just an AC socket on the top.

Any ideas for a hardware platform for use on car? I started at a Raspberry3, but the last time I only worked on Windows10 notebook. For sure, the current version will not work out-of-the-box on Raspberry. Would it make sense, to make it running on the Raspberry again? Or is this a dead horse, and an other platform would be better? I'm thinking into the direction, that for real-car-usage we need to measure voltages on the inlet, voltage of the battery, control the relay and most likely talk to the BMS to know the suitable current/power/voltage limits.

[uhi22]

BTW: This first test on Alpitronic high power charger showed a good progress. The SLAC is working, the network is formed, I could read-out the software version of the Alpitronics homeplug modem. The project also sends an SDP request, but no response yet. I think it was just too early, and no re-try implemented yet. I added the log file and pcap to https://github.com/uhi22/pyPLC/tree/master/results
Bugfixes and extensions are ongoing.

[catphish]

Any ideas for a hardware platform for use on car? I started at a Raspberry3, but the last time I only worked on Windows10 notebook. For sure, the current version will not work out-of-the-box on Raspberry. Would it make sense, to make it running on the Raspberry again? Or is this a dead horse, and an other platform would be better? I'm thinking into the direction, that for real-car-usage we need to measure voltages on the inlet, voltage of the battery, control the relay and most likely talk to the BMS to know the suitable current/power/voltage limits.

My assumption was that people would use a Raspberry Pi to run this. Why wouldn't your current implementation run on Pi? Are you using Windows network APIs? I would hope it'll be quite easy to port back to Linux when necessary.

The *best* solution would be to source some AR7420 chips, and build a board with the code running on a STM32, but that's a long way away from where we are right now

[johu]

May be easier on an ESP32 as that has the TCP/IP stack nicely integrated into platformio or Arduino. But that might also be the case for an STM32?

BeagleBone/Raspberry is most realistic for now

[catphish]

May be easier on an ESP32 as that has the TCP/IP stack nicely integrated into platformio or Arduino. But that might also be the case for an STM32?

BeagleBone/Raspberry is most realistic for now

I think that ultimately comes down to taste. STM32 has a library for TCP/IP, but I wouldn't suggest anyone use it unless they're comfortable programming STM32 in the first place. Personally I wouldn't use libraries like platformio / Arduino and I prefer the more official low level stuff provided by ST.

I would suggest people use what MCU and libraries they're personally comfortable with though.

Regardless of that, Raspberry Pi is the perfect system for prototyping this. It's portable, it allows a range of programming languages, it's easy to deploy for testing, with a build in Ethernet port. No need to overcomplicate before it's working.

[Pete9008]

I'm guessing that it is currently fairly reliant on the OS for the ethernet stack, python, libraries and probably lots of other bits and pieces? If so then for me linux, of any variety, would seem to be the way to go for now. That way it can be developed/tested on the laptop and then easily ported to whatever platform is wanted.

There is a linux build for the stm32 family, and the f4 and f7 devices have the ethernet port to talk to the AR7420 but it would be hard work. My vote would have to be for the Pi, it's just a much easier platform to develop on. If you wanted a more compact/rugged solution longer term you could always go for a Pi compute module coupled directly to the AR7420 chip via the RMII port?

[uhi22]

Yes, there are interesting approaches for the project after next. So for the moment the decision is to be compatible with Raspberry and Windows10. After some adjustments, it now runs on both. I plan to create a dedicated non-GUI variant, so that it runs also on "headless" Pi (without display, keyboard, mouse). And to add it to the auto-start, so that after powering-up the Pi, it would start talking.