A way to exclude protocol headers out of data dump is needed

[Hi-Angel]

There's an option -X which says

-X     When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex and ASCII. This is very handy for analysing new protocols.

It would indeed be handy for analysing a protocol, except that its hex dump still includes tcp headers, which makes it very hard to see the actual data.

There's this question with 21.5k views which suggests it's a very popular problem.

[guyharris]

Actually, the right way to handle the issue in the question is probably to have tcpdump print port 6667 traffic as a text protocol, the way it prints port 80 traffic, for example.

But, yes, the ability to limit the hex and ASCII dumps might be useful. Unfortunately, -XX prints more than -X does, so -XXX, over and above bringing to mind either port or Vin Diesel, might suggest printing more data, not less.

So what might be useful is a flag that 1) affects -A, -x and -X and 2) has multiple values, to say "everything", "start at the link-layer payload", "start at the transport layer payload", "skip all forms of tunneling and start at...", and so on.

[infrastation]

Just an idea: maybe something like --skip-headers=n, with each subsequent protocol printer either printing the data if n == 0 or calling the nested protocol decoder with n - 1? That said, this will not work quite as expected when someone is looking for SMTP and that SMTP comes both as plain IPv4 and as IPv4 inside a tunnel, for example.

[guyharris]

If you want to see SMTP, current versions of tcpdump should just dump it as text:

06:41:50.976827 IP {client}.{port} > {server}.25: Flags [S], seq 9129424, win 8192, options [mss 1460], length 0
06:41:50.977500 IP {server}.25 > {client}.{port}: Flags [S.], seq 62020503, ack 9129425, win 8760, options [mss 1460], length 0
06:41:50.981288 IP {client}.{port} > {server}.25: Flags [.], ack 1, win 8760, length 0
06:41:54.768061 IP {server}.25 > {client}.{port}: Flags [P.], seq 1:91, ack 1, win 8760, length 90: SMTP: 220 mailserver.example.com ESMTP Sendmail 8.8.8/8.8.8; Thu, 27 Apr 2000 10:41:54 -0400 (EDT)
06:41:54.772070 IP {client}.{port} > {server}.25: Flags [P.], seq 1:18, ack 91, win 8670, length 17: SMTP: HELO {client}
06:41:54.773105 IP {server}.25 > {client}.{port}: Flags [P.], seq 91:159, ack 18, win 8760, length 68: SMTP: 250 example.com Hello [{client}], pleased to meet you
06:41:54.776533 IP {client}.{port} > {server}.25: Flags [P.], seq 18:68, ack 159, win 8602, length 50: SMTP: MAIL FROM:"User Name"<username@user.example.com>
06:41:54.820745 IP {server}.25 > {client}.{port}: Flags [.], ack 68, win 8760, length 0
06:41:55.233341 IP {server}.25 > {client}.{port}: Flags [P.], seq 159:261, ack 68, win 8760, length 102: SMTP: 501 "User Name"<username@user.example.com>... illegal MAIL FROM:User Name<username@user.example.com>
06:41:55.337365 IP {client}.{port} > {server}.25: Flags [.], ack 261, win 8500, length 0
06:42:02.308405 IP {client}.{port} > {server}.25: Flags [P.], seq 68:74, ack 261, win 8500, length 6: SMTP: QUIT
06:42:02.309791 IP {server}.25 > {client}.{port}: Flags [P.], seq 261:304, ack 74, win 8760, length 43: SMTP: 221 mailserver.example.com closing connection
06:42:02.311712 IP {server}.25 > {client}.{port}: Flags [F.], seq 304, ack 74, win 8760, length 0
06:42:02.315136 IP {client}.{port} > {server}.25: Flags [.], ack 305, win 8457, length 0
06:42:02.324783 IP {client}.{port} > {server}.25: Flags [F.], seq 74, ack 305, win 8457, length 0
06:42:02.327473 IP {server}.25 > {client}.{port}: Flags [.], ack 75, win 8760, length 0

[guyharris]

when someone is looking for SMTP and that SMTP comes both as plain IPv4 and as IPv4 inside a tunnel

A "show me the transport-layer payload" option would handle that - print-udp.c and print-tcp.c would set a "transport-layer payload offset" value in the netdissect_options structure, so the transport layer at the top of the stack would win.

[infrastation]

Yes, that's correct. But I meant to suggest that the action the original requestor wanted (hexdump) could only happen after the parameter has been decremented n times, regardless of particular protocol. It just crossed my mind as I was reading through the comments, so I decided to write it down before I forget. Feel free to disregard.

[infrastation]

Skipping a specified number of (potentially variable-sized) headers might be more useful than skipping a specified amount of bytes (as discussed in #427). Anyway, would anybody like to work on such a feature anytime soon?