Data corruption due to packets with padding (1.6.1)

[Dimon160]

Short TCP4 packets with Ethernet padding and no stream data (window manipulation, etc.) may corrupt output files, because of incorrect length using.
Also, tcpflow creates 2-3 unwanted files, contain only two zero bytes.
In my case, I get regular one corrupted byte, every ~350Mbytes.

Attached patch fix both problems.

patch-tcpdemux-cpp.txt

[simsong]

That is great! Can you please submit this as a pull request? Even better, do you have a PCAP file that demonstrates this problem? If so, please submit that too, so that we can add a unit test for it.

[Dimon160]

Thanks for your quick response!
I'm sorry, I not fully understand how to do pull request and short unit test.

I'm upload archive (~800Mbytes) contain PCAP file, that demonstrates the problem.
https://easyupload.io/5c26a9 (stored for 30 days)
With a patch, stream restored correctly,
MD5: 3f19c1510bf5ac6f8874ae34c6ec1966
Without a patch, restored stream is corrupted,
MD5: ffc7a3711353aa5929be6b2f6456e7c1
Different bytes is:
153850CF: 9C 00
2A6FCE9B: DD 00
Original file from stream, can be downloaded from:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.3/FreeBSD-13.3-RELEASE-amd64-memstick.img.xz
MD5: 3f19c1510bf5ac6f8874ae34c6ec1966

[simsong]

I can make a pull request. Can you make a smaller PCAP file? Ideally 10-100kb?

[Dimon160]

It seems to do it.
Following archive, contain very small PCAP file, that demonstrates two stream decoding errors, and one unwanted file.
Maybe it's similar to #253 and #258 issues.

pcap.zip