TCP Keep-Alive carrying data

[gyl30]

I recently discovered an interesting phenomenon in a customer environment where TCP Keep-Alive packets appear every second or so and carry a byte of data, these Keep-Alive packets carry data that is intermingled with the normal data and can be passed through TcpReassembly. do we have a way to deal with this situation at PcapPlusPlus? Do we have a way in PcapPlusPlus to handle this situation? I have a screenshot here of Keep-Alive and HTTP data together, causing an error in HTTP parsing.

[gyl30]

I forgot to mention that all the TCP Keep-Alive packets I've observed in my environment carry one byte of data at 0x00.

[tigercosmos]

It sounds like an edge case. I don't know if it is general enough to modify the TcpReassembly. I also wonder if it's a bug of TcpReassembly. In this case, perhaps you may want to handle the packets yourself.

[gyl30]

Everyone who encounters this situation with PcapPlusPlus could benefit if it was handled within PcapPlusPlus. I see herethat it is possible to filter out such packets using the bpf filtering rule, but not when using dpdk Using bpf filtering rules

[seladb]

@gyl30 is there a pcap file you can share that includes this phenomenon?

[gyl30]

@seladb
Sorry, the packet capture file involves client information that I can't provide, however, we should be able to reproduce this problem by writing a simple tcp program and setting SO_KEEP* related options

[tigercosmos]

@gyl30 I think it's possible to reproduce through a unit test. Probably you can consider providing a minimum reproducible test case.

[hidd3ncod3s]

It is a common windows behaviour
https://osqa-ask.wireshark.org/questions/44609/wireshark-tcp-keep-alive-detection/

[seladb]

It is a common windows behaviour
https://osqa-ask.wireshark.org/questions/44609/wireshark-tcp-keep-alive-detection/

@hidd3ncod3s there is a link to a pcapng flie, but unfortunately it's broken 😕

@seladb Sorry, the packet capture file involves client information that I can't provide, however, we should be able to reproduce this problem by writing a simple tcp program and setting SO_KEEP* related options

@gyl30 maybe you can write such program, record the TCP traffic, and attach a pcap file to this issue?

[gyl30]

@seladb @hidd3ncod3s @tigercosmos
I've investigated this issue carefully and we probably can't fix it because the first packet received is a TCP Keep-Alive packet. This packet capture file reproduces the problem. Please change the filename suffix to pcapng
Keep-Alive.zip

[gyl30]

It is a common windows behaviour https://osqa-ask.wireshark.org/questions/44609/wireshark-tcp-keep-alive-detection/

Same problem, I should have caught it earlier

[seladb]

@gyl30 how come the TCP flow doesn't start with SYN? 🤔

[gyl30]

@gyl30 how come the TCP flow doesn't start with SYN? 🤔为什么 TCP 流不以 SYN 开头？ 🤔

PcapPlusPlus works fine if you start from the SYN of the TCP stream, the problem I encountered in my client environment did not capture the SYN of the TCP stream for some unknown reason.Keep-Alive.zip was intentionally caused by me in order to reproduce the problem. I now know that this phenomenon is not a problem. This issue can be closed now.