ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 2883] Timing of packets in a mess

Date: Mon, 22 Sep 2008 13:58:09 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2883





--- Comment #5 from Sake <sake@xxxxxxxxxx>  2008-09-22 13:58:08 PDT ---
(In reply to comment #4)
> Ok then the problem is the reassembled TCP stream : the reassembly is
> timestamped+numbered
> at the last packet's recieve time, which confused me.

Being confused is good :-)

> Is there a good reason
> for doing so ? (some special needs for a particular protocol ?) 

Asking questions is good :-)

> I think, it
> would be more logical to tag the reassembly like the first reassembled packet,
> so in http it would say the http/1.1 200 ok (text/html) reply would come before
> css-queries depending of it...

Trying to help improve Wireshark is also good :-)

Opening bug-reports with a harsh title like "Timing of packets in a mess" is
not so good, as it does not exactly trigger me to take you seriously. But that
might just be my reaction...


Back to your question (which would fit the wireshark-users list just fine),
there is good reason for doing so, based on the way Wireshark works. It needs
to  see all segments of the PDU it tries to re-assemble, before it can actually
do so. Of course one could throw in the argument that Wireshark could first
re-assemble the PDU ahead and then show the re-assembled PDU with the first
packet that contains a segment of the PDU. But, since Wireshark and Tshark use
the same library for dissection, they must do it in the same manner. Tshark
loops through the packets only once, making it impossible to show the
re-assembled PDU on the packet that contains the first segment of the PDU.

That is why protocol preferences are your friend, you can make Wireshark show
you all the information you need in the way you need to see it.

As for the original question about the order in which http-requests were made,
a binary tracefile would really help us helping you. My guess would be that the
client used to fetch the website is actually requesting the embedded sources as
it is still reading the (master) html page. This would improve user-experience
and so it does make sense to me :-)

Cheers,
    Sake


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