TCP

[Shiyaoy-Smile]

The TCP three-way handshake failed. The charging pile received the ACK, but it still keeps sending SYN-ACK repeatedly.

[uhi22]

A pcap could help to analyze the topic. Which OS is the charging pile running?

[Shiyaoy-Smile]

A pcap could help to analyze the topic. Which OS is the charging pile running?

I don't know what operating system this charging pile uses, but it can charge other vehicles. Our self-developed EVCC has this problem now. SLAC and SDP are both normal. This issue occurs during the TCP handshake.

[uhi22]

How do you see that the charging pile receives the ACK? Can you run wireshark or tcpdump on the pile? Do you have a log from Clara?

[Shiyaoy-Smile]

How do you see that the charging pile receives the ACK? Can you run wireshark or tcpdump on the pile? Do you have a log from Clara?

Yes, I tested the EVCC with the charging pile end simulator. The charging pile end simulator can use Wireshark to capture packets and it shows that the ACK was received. I'll send you the picture.

[uhi22]

Three remarks:

1. Are you sure that ccs32clara is the EV side of this trace? Clara would use port 59220 (and upwards) for TCP, but we see port 55057.
2. The first TCP message after the three-way-handshake is much longer than the message Clara would produce.
3. I do not see a reason for the retransmission of the SYN,ACK. Maybe a bug of the TCP in the charging pile. Or a wrong format of the ACK. You need to check with a TCP expert.
4. Providing a screen shot of a wireshark is not the best idea. The pcapng file would allow much more analysis.

[uhi22]

For comparision, added a log file of Clara (with pyPLC as EVSE) here: https://github.com/uhi22/clara-logs/blob/main/2025-07-16_Foccci_v3_with_pyPLC.pcapng

[Shiyaoy-Smile]

三点意见:

1. 您确定ccs32clara是此跟踪的EV侧吗？Clara会使用端口59220（及更高）进行TCP，但我们看到端口55057。
2. 三方握手后的第一个TCP消息比Clara生成的消息要长得多。
3. 我看不出重新传输SYN，ACK的原因。也许是充电桩中的TCP错误。或者ACK格式错误。你需要向TCP专家检查。
4. 提供Wireshark的屏幕截图并不是最好的主意。pcapng文件可以进行更多的分析。

Initially, the port number and IP address we used were those in ccs32clara. Later, due to the failure of TCP connection, we attempted to change the port number and IP address, but it didn't work either. The first TCP data packet after the three-way handshake was long because we added an extra protocol. 70121 and 15118. Thank you for the data file. I will carefully compare and check it tomorrow.

[jsphuebner]

Please share you code on github, otherwise it becomes a cumbersome experience to help out.

[Shiyaoy-Smile]

Please share you code on github, otherwise it becomes a cumbersome experience to help out.

The code we are currently using at EVCC is ccs32clara, with almost no modifications. During the testing process, we only replaced the port number, MAC address, and IP address for testing purposes.

[uhi22]

This sounds like "almost nothing but a lot". Also the message length. Nobody knows what else. You may want to start from a clean basis and check which of the changes causes the SECC to send the retransmission.

[Shiyaoy-Smile]

This sounds like "almost nothing but a lot". Also the message length. Nobody knows what else. You may want to start from a clean basis and check which of the changes causes the SECC to send the retransmission.

I've reverted the code to be the same as that of ccs32clara, but the TCP connection failure issue still persists. Since I took more photos, I can't transfer the Wireshark data to my personal device. Please take a look. Thank you.

[osexpert]

Since it is a ACK problem....it may have to do with SACK?

https://chatgpt.com/share/6892f5aa-df0c-8012-8a0d-454047540dd4

Since using data captured from a "real" tcp stack, the bytes in tcp_connect may not be valid for the current tcp code?
Eg. it claim to support SACK, but AFAICS, it does not? So I can suggest to test this code, that remove declared SACK support:

void tcp_connect(void)
{
   addToTrace(MOD_TCP, "[TCP] Checkpoint301: connecting");
   setCheckpoint(301);

   // TCP Options (8 bytes total)
   TcpTransmitPacket[20] = 0x02; // Kind: 2 = Maximum Segment Size (MSS)
   TcpTransmitPacket[21] = 0x04; // Length: 4
   TcpTransmitPacket[22] = 0x05; // MSS = 0x05A0 = 1440 bytes
   TcpTransmitPacket[23] = 0xA0;

   TcpTransmitPacket[24] = 0x01; // Kind: 1 = NOP
   TcpTransmitPacket[25] = 0x03; // Kind: 3 = Window Scale
   TcpTransmitPacket[26] = 0x03; // Length: 3
   TcpTransmitPacket[27] = 0x08; // Shift count = 8 (2^8 = 256x window)

   tcpHeaderLen = 28;      // 20 bytes header + 8 bytes options
   tcpPayloadLen = 0;      // No data in SYN
   tcp_prepareTcpHeader(TCP_FLAG_SYN);
   tcp_packRequestIntoIp();
   tcpState = TCP_STATE_SYN_SENT;
}

[ax-iv]

Some stations give an error when the TCP session is terminated without receiving a FIN+ACK packet from Clara. I fixed the tcp_reset method by changing the line tcp_prepareTcpHeader(TCP_FLAG_RST) to tcp_prepareTcpHeader(TCP_FLAG_FIN+TCP_FLAG_ACK); (#define TCP_FLAG_FIN 0x01). And it worked

[osexpert]

So I am guessing charger is confused from the previous session and somehow has lingering state related to the MAC? (and I assume a new client port is used). Everyone is breaking tcp in their own ways, it seems.

I added the RST to at least try to do the right thing, but maybe just ghosting the connection was actually the best.

Edit: but FIN+ACK may be good too, allthou it may create a new problem, that some chargers may complain if their FIN is not acked, so possibly need to add handling of this too:-)
Edit2: I have been working on a quick and dirt tcp fin here: https://github.com/osexpert/ccs32clara-chademo/tree/debug/tcp_fin_experiment
And from the info here, it seems tcp RST is completely off the table:-) Good to know, so its either ghosting or FIN then:-)
Edit3: or is this 2 different issues? Is the SYN problem really related to RST?
Edit4: If the same client port is reused for every session, problems are expected. The last used port should be persisted between sessions or randomized. Starting at 59219 every time will create problems for some chargers, no matter if the connection is ghosted or RST, and maybe even if FIN'ed.

[ax-iv]

In my case, the charging station gave an error specifically for an improperly terminated TCP session. The dump of the exchange confirms this: the station sends a FIN+ACK, does not wait for a response (at least an ACK), and sends another FIN+ACK, after which it gives an error for the TCP session.