This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TShark not finding http traffic

0

Hi.

I'm new to Wireshark, so be warned that this is a newbie question.

I'm using Wireshark on an Ubuntu server, and have enabled dumpcap to collect raw data and store to files:

/usr/bin/dumpcap -i eth1 -w /var/tracefiles/eth1.pcap -b duration:3600

When trying to analyze the files produced, I would for instance like to see http requests and the resulting status code. I think I have found an example on how to do this on 1:

tshark -R http.response \ -z "proto,colinfo,http.content_length,http.content_length" \ -z "proto,colinfo,http.content_type,http.content_type" \ -r <myfile.pcap>

This produces nothing. I have actually tried a number of examples, but it seems I can never use any application level filters, as they produce nothing.

Anything obvious I'm missing here?

Best regards, Chocolate Eater

asked 05 Jun '12, 03:35

Chocolate%20Eater's gravatar image

Chocolate Eater
1114
accept rate: 0%

edited 05 Jun '12, 16:04

helloworld's gravatar image

helloworld
3.1k42041

Couple of questions:

  1. Are you sure your capture contains http responses?
  2. What is the version of tshark you are using?
(05 Jun '12, 04:28) grahamb ♦

Hi, Grahamb.

  1. Not exactly. The packets coming in on eth1 is from a span containing tx and rx packets, in other words everything. Do I need to set any specific options on dumpcap? This is from a dump of one of the pcaps:

3516 13.944675 207.x.x.x -> 192.168.20.101 TCP 1506 http > 57010 [ACK] Seq=1765050 Ack=1 Win=64912 Len=1452 3517 13.944724 192.168.20.101 -> 207.x.x.x TCP 60 57010 > http [ACK] Seq=1 Ack=1765050 Win=65340 Len=0

Don't know if it's relevant. Goes on and on.

  1. Version 1.6.7.
(05 Jun '12, 04:51) Chocolate Eater

re Q1, I'm trying to confirm the capture actually has the data you're looking for, i.e. http responses, as the -R http.response part of the command is a filter that will only use packets that contain an http.response field.

The command string works fine for me on trunk (1.7.2) on a capture with http responses in it.

(05 Jun '12, 05:01) grahamb ♦

I fired up wireshark with the exact same file as I tried parsing with tshark. I can actually see that it lists an HTTP/1.1 200 OK (text/html), and I can also browse into the details on it.

Could there be something with tshark? Maybe I should go ahead and try the trunk version.

(05 Jun '12, 12:11) Chocolate Eater

Try removing the -z options to check you can see the http response codes.

(05 Jun '12, 12:40) grahamb ♦

Ran this command:

tshark -r eth1_00258_20120605185617.pcap -R http.response

No output...

(05 Jun '12, 12:44) Chocolate Eater

I can't think what's wrong here unless your capture really doesn't have any http responses. If the capture doesn't contain sensitive info can you post the capture on CloudShark and give us a link to it?

(05 Jun '12, 13:33) grahamb ♦

I really appreciate you helping, grahamb.

The file is unfortunately quite large, and may contain some sensitive data. If I could e-mail you a link though, I can make the file available for download from one of my web servers.

(05 Jun '12, 14:26) Chocolate Eater
showing 5 of 8 show 3 more comments

2 Answers:

1

One thing that might be causing these troubles is that somehow the reassembly of the HTTP PDU's is not working (this might happen when using a snap length). If Wireshark (or Tshark) has reassembly enabled, sees part of the HTTP protocol, but is not able to reconstruct the full PDU's, then all data will be listed as "[TCP segment of a reassembled PDU]" and all the HTTP filters won't work.

You may try the following to check whether the HTTP responses are indeed recognized without reassembly enabled:

tshark -r <file> -o tcp.desegment_tcp_streams:FALSE -R http.response

If this command does show output, then we need to find out why reassembly is failing in your case...

answered 05 Jun '12, 15:25

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

The OP reported teh captures being made with:

/usr/bin/dumpcap -i eth1 -w /var/tracefiles/eth1.pcap -b duration:3600

Would that have a reduced snaplen?

(05 Jun '12, 23:43) grahamb ♦

@Graham, AFAIK dumpcap uses snaplength 0, so with the mentioned command all data should be there. But there are other causes for reassembly to fail, I just mentioned snaplength as a possible cause :-)

(07 Jun '12, 04:51) SYN-bit ♦♦

0

May be you wana try this.

tshark.exe -r capturee.pcap -T fields -e http.request.method -e http.response.code > test.txt

answered 05 Jun '12, 06:39

Deepak's gravatar image

Deepak
31225
accept rate: 25%

This actually produces a large, blank file. It contains only line breaks, as far as I can see.

(05 Jun '12, 12:00) Chocolate Eater