[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5667

--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2011-02-08 23:59:07 PST ---
>From a quick look at the summary:

      4 0.027650    10.30.120.50          10.30.10.61           HTTP     GET
http://www.roscocanoes.com.au/images/Rosco-tile.jpg HTTP/1.1 
      5 0.043435    10.30.120.50          10.30.10.61           HTTP     GET
http://www.roscocanoes.com.au/images/searchbg.gif HTTP/1.1 

Requests to fetch images:

      6 0.046769    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
      7 0.047070    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
      8 0.047167    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
      9 0.047261    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     10 0.047356    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     11 0.047458    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     12 0.047554    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     13 0.047649    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     14 0.047744    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     15 0.047839    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     16 0.047934    10.30.10.61           10.30.120.50          HTTP    
HTTP/1.1 200 OK  (JPEG JFIF image)

This is probably a response to the fetch of
http://www.roscocanoes.com.au/images/Rosco-tile.jpg.  The image is probably too
big to fit in one TCP segment, so the HTTP response took 11 TCP segments.  When
the 11th segment was received, Wireshark now had all the data that constituted
the response, and reassembled all of them and dissected the entire response. 
The previous 10 segments were shown as segments of the reassembled PDU, the
"reassembled PDU' being the HTTP response.

     22 0.079197    10.30.120.50          10.30.10.61           HTTP     GET
http://www.roscocanoes.com.au/adm/thumbnailer.aspx?src=/prodImg/28212909.jpg&bgcolor=FFFFFF&width=220&height=110
HTTP/1.1 
     23 0.084028    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     24 0.084222    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]
     25 0.084320    10.30.10.61           10.30.120.50          TCP      [TCP
segment of a reassembled PDU]

That's probably  the first 3 segments of the HTTP response to the GET request
in question - if the capture had continued, there would probably have been more
segments, with the last segment causing Wireshark to reassemble the packets and
show it as an HTTP/1.1 200 OK response with a JPEG image.

With the subdissector disabled:
      1 0.000000    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
      2 0.000111    10.30.120.50          10.30.10.61           TCP      62209
> http-alt [ACK] Seq=1 Ack=4294966761 Win=62953 Len=0
      3 0.000208    10.30.120.50          10.30.10.61           TCP      62209
> http-alt [ACK] Seq=1 Ack=481 Win=64240 Len=0
      4 0.027650    10.30.120.50          10.30.10.61           HTTP     GET
http://www.roscocanoes.com.au/images/Rosco-tile.jpg HTTP/1.1 
      5 0.043435    10.30.120.50          10.30.10.61           HTTP     GET
http://www.roscocanoes.com.au/images/searchbg.gif HTTP/1.1 
      6 0.046769    10.30.10.61           10.30.120.50          HTTP    
HTTP/1.1 200 OK  (JPEG JFIF image)[Unreassembled Packet] 

OK, that's the *first* TCP segment of the response to one of the GET requests. 
Wireshark *tried* to show the entire response, complete with a dissection of
the JPEG image (Wireshark can dissect the internal structure of JPEGs to some
degree), but ran out of data, because it was told not to reassemble the
response (presumably by "with the subdissector disabled" you meant "with the
TCP preference 'Allow subdissector to reassemble TCP streams' disabled"), so it
only had the first segment's worth of data to dissect, and it ran out of data.

      7 0.047070    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
      8 0.047167    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
      9 0.047261    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     10 0.047356    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     11 0.047458    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     12 0.047554    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     13 0.047649    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     14 0.047744    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     15 0.047839    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic
     16 0.047934    10.30.10.61           10.30.120.50          HTTP    
Continuation or non-HTTP traffic

Again, it was told not to reassemble the data, so it didn't know that those
should all have been reassembled into an HTTP response.  They didn't start out
with something that looked like HTTP response data, so it guessed that it was
either a "continuation" of a previous HTTP message (which it probably was) or
some form of non-HTTP traffic (which it probably wasn't).

 So, in this case, Wireshark appears to be behaving correctly.

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