Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3785] Some HTTP responses don't decode with TCP reassembly

Date: Sat, 27 Feb 2010 21:39:05 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3785

--- Comment #6 from Chris Costa <chcosta75@xxxxxxxxxxx> 2010-02-27 21:38:49 PST ---
First of all, thanks for the feedback!

I started to take a look into this latest problem, but I'm finding I can't
reproduce it.  I executed the same tshark command on my patched version, but I
was seeing both http responses, as expected:

C:\wireshark\wireshark-gtk2>tshark -n -o "tcp.desegment_tcp_streams:TRUE" -o
"http.desegment_headers:TRUE" -o "http.desegment_body:TRUE" -r
C:\Users\Chris\Desktop\two-get-1-resp.pcap -R "http.request.method != 0 or
http.response.code != 0"
  4   0.173513 192.168.2.200 -> 195.20.242.89 HTTP GET
/pool/updates/main/b/bind9/bind9-host_9.5.1.dfsg.P3-1+lenny1_amd64.deb HTTP/1.1
GET /pool/updates/main/b/bind9/dnsutils_9.5.1.dfsg.P3-1+lenny1_amd64.deb
HTTP/1.1  428
 85   1.352351 195.20.242.89 -> 192.168.2.200 HTTP HTTP/1.1 200 OK 
(application/x-debian-package) 1506
257   1.916961 195.20.242.89 -> 192.168.2.200 HTTP HTTP/1.1 200 OK 
(application/x-debian-package) 1365 

Just to confirm the version I used was indeed properly patched, I ran the same
command on the "broken" capture I attached before, and I can see the response
properly decoded (meaning, the patch is applied):

C:\wireshark\wireshark-gtk2>tshark -n -o "tcp.desegment_tcp_streams:TRUE" -o
"http.desegment_headers:TRUE" -o "http.desegment_body:TRUE" -R
"http.request.method != 0 or http.response.code != 0" -r
c:\Users\Chris\Desktop\broken_http_response.cap
  2   0.101563  10.10.1.189 -> 10.10.1.90   HTTP HTTP/1.1 404 Not Found 
(application/octet-stream) 232

Are there any additional configuration requirements in order to experience the
problem?  Or, some other prerequisite step I may have failed to execute?

One thing I noticed about the way you ran your test, was that you seemed to be
accessing a different capture file during each test (same filename, different
path).  During your first (patched) test you used:

-r two-get-1-resp.pcap

... during your second (unpatched) test you used:

-r /usr/local/src/pcap/two-get-1-resp.pcap

Was the same file being accessed in both tests, and not two different files
that happen to share the same name?  Just wanted to make sure...

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.