Ask Your Question

tshark tcp stream Raw data is not output to the end

asked 2019-09-08 06:34:14 +0000

kkk666 gravatar image

updated 2019-09-09 13:05:07 +0000

Raw data is not output to the end.

command:tshark -r in.pcap -z follow,tcp,raw,0 > f

・It is different from the result executed by this method.  ->wireshark GUI -> Follow TCP Stream -> Save As [Raw]

・The output result is different between windows version tshark and Linux version tshark.

・windows version is output correctly.

・windows version is wireshark and tshark results together.

Is tshark outputting raw data? Or is it a library loaded by tshark? Is it related to libpcap, for example?

Version number



edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2019-09-08 09:18:46 +0000

grahamb gravatar image

There are a number of issues here, firstly your use of tshark to get the raw data and then slight differences in the output format.

To save the raw data from tshark don't (-w) write to a capture file, instead redirect the output to the file, e,g.

tshark -r in.pcap -q -z follow,tcp,raw,0 > f

Note the addition of -q to suppress the dissection of the packets.

The slight differences in the output (should be, see note 1) is that tshark adds a header and trailer to the data:

Follow: tcp,raw
Filter: eq 0
Node 0:
Node 1:

... hex data

and that each new packet in the tshark output for the 2nd node (node 1) is preceded by a tab character.

Note 1: Testing with the current development buld (3.1.x) and selecting raw mode seems to save the stream data in the same format as the ASCII mode. This seems to be a bug to me.

edit flag offensive delete link more


thank you. Executed with the command you taught me. However, it could not be solved.

tshark -r in.pcap -q -z follow,tcp,raw,0 > f

Here are some more details.

Follow: tcp,raw
Filter: eq 0
Node 0:
Node 1:

Follow: tcp,raw
Filter: eq 0
Node 0:
Node 1:
  • ・For example,0 and 1 indicate raw data.
  • ・Actually more data is output.
  • ・11111.... is output in the Windows version, but not in the Linux version
  • ・The following error was output to the corresponding TCP STREAM.
  • If this error is output, is there a possibility that it cannot be read correctly?

    [TCP Previous segment not captured]

    [TCP Dup ACK XXX#N]

    [TCP Out-Of-Order]

    [TCP Retransmission]

kkk666 gravatar imagekkk666 ( 2019-09-08 11:07:04 +0000 )edit

So the issue seems to be a difference between the output from the Linux and Windows versions using the same capture file?

Is there a reason you can't use the current stable release (3.0.3) on Windows to minimise any code differences?

Different configurations might cause different output, although I think that tshark, unless specified otherwise, will use the default configuration. IS it possible that you've modified the default config?

Is it possible to share your capture file?

grahamb gravatar imagegrahamb ( 2019-09-08 12:57:33 +0000 )edit

At first, I tried on WINDOWS and LINUX with the same version. However, because only the LINUX output results were different, only the LINUX version was upgraded. But the problem was not solved. The default settings have not been changed. When I checked for any differences, the WINDOWS version used WINPCAP, and LINUX used libpcap. Regarding the difference in the output of raw data, I asked whether it was related to the difference in the library. Please wait for a while to share the capture file.

kkk666 gravatar imagekkk666 ( 2019-09-08 14:47:02 +0000 )edit

The "capture" library, Winpcap, or npcap for newer versions on Windows or libpcap, makes no difference at all to dissection, it's purely for capture.

grahamb gravatar imagegrahamb ( 2019-09-08 15:54:01 +0000 )edit

Thank you very much. understood. Are there other libraries and settings and configs to check?

kkk666 gravatar imagekkk666 ( 2019-09-09 00:03:03 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-09-08 06:34:14 +0000

Seen: 2,606 times

Last updated: Sep 09 '19