HTTP/1.1 200 OK appears before HTTP GET

retag add tags

I am running tshark on Ubuntu server continuously to perform real-time analysis on all the HTTP GET and HTTP 200 OK packets to calculate the time between them (since the request until the response). I am aware this is not the most accurate way to compute the exact time. The issue here that approximately 1.5% of the GET & OK packets appears out of order; I.e, the response appear before the request. I tried using reordercap but nothing changed at all. How can I solve this? I am fine with using other tools if this can be solved.

I am attaching a pcap file (https://tinyurl.com/outoforderpcap) showing this issue. The packet number 444 shows the HTTP 200 OK for the file file_103.odt while the packet number 448 shows the HTTP GET for the same file! FYI, this pcap file has already gone through reordercap.

Here is my setup: Ubuntu Server (running tshark) on VirtualBox running under MacOS

The client (downloading the files) were: 1- Android mobile. and/or 2- The host itself (MacOS).

ipqtr

asked 2019-12-29 09:08:33 +0000

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

Having briefly looked at the capture file, one thing pops out to me and that is that the determinations you've made are probably based on information presented in square brackets. This information is based not on data in the packets themselves but derived by Wireshark from the context it creates when dissecting other packets.

Initially when loading the file (so, going sequential in packet / time order) the context is created / updated as time progresses. But when you click on individual packets these individual packets are dissected again, to present details.

Now in this case it seems as though the context is being updated as well, in the order you click the packets, so out of order, giving you a false sense of the actual context at the time of previous packets in the capture.

You can see this by using the generated frame links in the HTTP packets. Packet 384 has the original request for file_1.odt (click this packet to see the Full request URI in the HTTP packet). The corresponding response is in packet 444. Click that packet and you'll see the Request URI being for file_1.odt. Now click on packet 448 and check the Full request URI, it's for file_103.odt. Click on packet 444 again and see the Request URI changed to file_103.odt. That's a bug, this change of the Request URI should not have taken place.

Not sure if there is already a bug report on this (haven't searched), but if there isn't you should file one.

13.7k

Jaap

answered 2019-12-29 11:38:14 +0000

edit flag offensive 0 remove flag delete link

Comments

Thank you for your reply. I am setting the duration for tshark as 1 second (create new file every second). Would this be the culprit due to the limited context on each file; do you suggest other configurations? Like make it size based instead (every 1 MB) or every 5 seconds instead of every 1 second?

ipqtr (2019-12-29 15:49:46 +0000) edit

Doesn't matter for this, what's relevant is the order in which the packets are dissected, Initially during loading this is sequential, when selecting random packets in the list the order is, well, random.

Jaap (2019-12-30 05:26:55 +0000) edit

@Jaap Thank you Mr. Jaap for your reply. My ultimate goal now to calculate the time of downloading the file ( I am currently using the elapsed time between the GET and the HTTP 200 OK). With this phenomena happening, is there a way to calculate the time? I am also open to adapt other ways for calculating the time for each file.

ipqtr (2019-12-30 06:14:43 +0000) edit

add a comment see more comments

HTTP/1.1 200 OK appears before HTTP GET

Comments

1 Answer

Comments

Your Answer

HTTP/1.1 200 OK appears before HTTP GET edit

Comments

1 Answer

Comments

Your Answer

HTTP/1.1 200 OK appears before HTTP GET