tcpflow nulls out packets labeled "IP bad-len 0" by tcpdump

[twoi]

I've stripped down a pcap where tcpflow emits x null bytes for an ip packet of length x. There are 3 packets in dump123.pcap:

 #   len  tcp payload len 
--------------------------
 1   242              188 
 2  1560             1506 
 3  1468             1414 

All packets are interpreted fine by wireshark (which I used to take the dump, and save it as tcpdump pcap, i.e. not wireshark's pcapng), however when doing tcpdump -xnr dump123.pcap, it complains about the bad length of packet 2 (because the length is > 1500 perhaps?). But it still prints its full payload correctly:

14:01:08.664814 IP 192.168.20.54.64261 > 192.168.20.56.20008: Flags [P.], seq 596495993:596496181, ack 2601804460, win 51200, length 188
        0x0000:  4500 00e4 7879 4000 8006 d7db c0a8 1436
        0x0010:  c0a8 1438 fb05 4e28 238d ce79 9b14 62ac
        0x0020:  5018 c800 677b 0000 0000 0000 b400 0000
        0x0030:  0301 0800 0000 1400 0000 4653 4045 4036
        0x0040:  3530 3140 5440 4d5f 5453 455f 4653 1200
        0x0050:  0000 5140 4540 3635 3031 4054 404d 5f54
        0x0060:  5345 5f51 1400 0000 5441 4045 4036 3530
        0x0070:  3140 5440 4d5f 5453 455f 5441 0d00 0000
        0x0080:  4440 4540 3635 3031 4054 4048 6414 0000
        0x0090:  0046 5340 4540 3637 3538 4054 404d 5f54
        0x00a0:  5345 5f46 5312 0000 0051 4045 4036 3735
        0x00b0:  3840 5440 4d5f 5453 455f 5114 0000 0054
        0x00c0:  4140 4540 3637 3538 4054 404d 5f54 5345
        0x00d0:  5f54 410d 0000 0044 4045 4036 3735 3840
        0x00e0:  5440 4864
14:01:08.666155 IP bad-len 0
        0x0000:  4500 0000 787a 4000 8006 ddee c0a8 1436
        0x0010:  c0a8 1438 fb05 4e28 238d cf35 9b14 62ac
        0x0020:  5018 c800 65a3 0000 0100 0000 b400 0000
...

When doing tcpflow -r dump123.pcap I get a file of size 188+1506+1414, but the 1506 bytes of packet 2 are all nulls bytes.

Just to test tcpflow's behavior, I also created files with just one or two of those 3 packets:

• dump2.pcap
• dump12.pcap
• dump23.pcap

For all of these pcaps, tcpflow creates files with no output at all for packet 2, i.e. for dump2.pcap no file gets created, and for the other two dumps, the sizes are 188 and 1414, respectively.

[simsong]

Thanks! I will look into this I love test cases.

On Nov 21, 2018, at 6:19 PM, twoi [email protected] wrote:

I've stripped down a pcap where tcpflow emits x null bytes for an ip packet of length x. There are 3 packets in dump123.pcap https://github.com/simsong/tcpflow/files/2606190/dump123.zip:

len tcp payload len

---

1 242 188 2 1560 1506 3 1468 1414 All packets are interpreted fine by wireshark (which I used to take the dump, and save it as tcpdump pcap, i.e. not wireshark's pcapng), however when doing tcpdump -xnr dump123.pcap, it complains about the bad length of packet 2 (because the length is > 1500 perhaps?). But it still prints its full payload correctly:

14:01:08.664814 IP 192.168.20.54.64261 > 192.168.20.56.20008: Flags [P.], seq 596495993:596496181, ack 2601804460, win 51200, length 188 0x0000: 4500 00e4 7879 4000 8006 d7db c0a8 1436 0x0010: c0a8 1438 fb05 4e28 238d ce79 9b14 62ac 0x0020: 5018 c800 677b 0000 0000 0000 b400 0000 0x0030: 0301 0800 0000 1400 0000 4653 4045 4036 0x0040: 3530 3140 5440 4d5f 5453 455f 4653 1200 0x0050: 0000 5140 4540 3635 3031 4054 404d 5f54 0x0060: 5345 5f51 1400 0000 5441 4045 4036 3530 0x0070: 3140 5440 4d5f 5453 455f 5441 0d00 0000 0x0080: 4440 4540 3635 3031 4054 4048 6414 0000 0x0090: 0046 5340 4540 3637 3538 4054 404d 5f54 0x00a0: 5345 5f46 5312 0000 0051 4045 4036 3735 0x00b0: 3840 5440 4d5f 5453 455f 5114 0000 0054 0x00c0: 4140 4540 3637 3538 4054 404d 5f54 5345 0x00d0: 5f54 410d 0000 0044 4045 4036 3735 3840 0x00e0: 5440 4864 14:01:08.666155 IP bad-len 0 0x0000: 4500 0000 787a 4000 8006 ddee c0a8 1436 0x0010: c0a8 1438 fb05 4e28 238d cf35 9b14 62ac 0x0020: 5018 c800 65a3 0000 0100 0000 b400 0000 ... When doing tcpflow -r dump123.pcap I get a file of size 188+1506+1414, but the 1506 bytes of packet 2 are all nulls bytes.

Just to test tcpflow's behavior, I also created files with just one or two of those 3 packets:

dump2.pcap dump12.pcap dump23.pcap For all of these pcaps, tcpflow creates files with no output at all for packet 2, i.e. for dump2.pcap no file gets created, and for the other two dumps, the sizes are 188 and 1414, respectively.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/simsong/tcpflow/issues/197, or mute the thread https://github.com/notifications/unsubscribe-auth/ABhTrOUuKBySZreHHVTmpkD5xFMIFabjks5uxe2OgaJpZM4YudmA.

[twoi]

@simsong Awesome! It's good to see when the time stripping a case down and trying to document it as simple as possible is actually worth it!

Btw I'm using

tcpflow: TCPFLOW version 1.4.5 

on Debian (of course! ;).

[simsong]

By the way, do you have a preferred way for doing unit tests in C++? I've been mostly programming in Python for the past few years, and py.test really rocks; I don't know of anything like it in the C++ world, do you?