tcpflow nulls out packets labeled "IP bad-len 0" by tcpdump #197
Comments
|
Thanks! I will look into this
I love test cases.
… On Nov 21, 2018, at 6:19 PM, twoi ***@***.***> 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 <#197>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhTrOUuKBySZreHHVTmpkD5xFMIFabjks5uxe2OgaJpZM4YudmA>.
|
|
@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 on Debian (of course! ;). |
|
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? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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:When doing
tcpflow -r dump123.pcapI 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:
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.
The text was updated successfully, but these errors were encountered: