Hi, I have a case example of a connection that I thought would be a great way to start learning Wireshark. However I have a number of questions. First of the issue is when trying to download an image from a webserver it takes an extremely long time. This connection is however going through an F5. If : I download the image directly from the server it is fine. If I download the image via a VIP it takes a long time. Now on digging about I found that the issue was because one of the ports was at half duplex. This was changed and everything was fine. But for the sake of learning I thought Id look into why one connection was fine and one was not. I have an output of the connection that was failing. Based on the above I have 3 questions (based on the above) : 1) What would cause the HTTP get to be shown in the wrong position/sequence (poss corrupt seq number ?) 2) Though Im seeing a huge difference in time stamps, there appears to be not retransmissions or duplicate ACKs showing any sign of packet loss ? 3) Finally is this actually a window update. The amount of traffic being sent compared to the window size doesn't seem to correlate ? If anyone can shed any light of this it would be greatly appreciated. Thanks, asked 19 Nov '12, 01:14  bart80 edited 19 Nov '12, 01:15 |
One Answer:
Hi bart80, First, it looks like you're showing two different conversations: 172.16.1.100 (or a node in the path) seem to be limiting it's TCP MSS to 1260 bytes. Are you using both relative and absolute sequence numbers? Line 5 and 6 are two different conversations, so the 8 second delay is not path delay for instance. Doesn't look like it. Yes the receiver window is oddly small.. Are the window sizes showing as calculated (since you seem to support window scaling)? For simpler analysis, open the packet capture in Wireshark, right click on a conversation of interest and select "Follow TCP Stream" or something, save that file, run it through a pcap-anonymizer and upload it to Cloudshark. answered 20 Nov '12, 04:08  holmahenkel edited 20 Nov '12, 04:11 Thanks, for your updates. I`ll look over these points and try to get a file up to cloud shark. One point I wanted to ask, is that I checked the calculated window size. For the ACK it shows win=260 with 260 also for the calculated side. But for each TCP segment (data) is shows a Window size of 2053. Is the Window showing in the packet for the receive window for the source it is coming from. The reason I ask is that 2 1260 byte (tcp.len) packets are sent from the server even though the window is 2053 ? Thanks again... (20 Nov '12, 04:47) bart80 Ah, yes a window size is advertised in both directions, so if 172.16.1.100 (sender) where to send data to 8.8.8.8 (receiver) it would know that 8.8.8.8's advertised window (rwnd) is 2053 bytes. In your example 8.8.8.8 is sending data to 172.16.1.100, so 8.8.8.8 only worries about 172.16.1.100's advertised window of 260[*] bytes. Hopes this makes sense :-D
http://tools.ietf.org/html/rfc793#page-4 - "Flow Control" have some more information regarding windows. (20 Nov '12, 06:28) holmahenkel Thanks for your response but using the following example -- 172.16.1.100.51825 > 8.8.8.8.http: . ack 4139 win 260 (04 Dec '12, 01:01) bart80 |
ASCII dumps of traces are pretty hard to read, so if you can, upload the file/excerpt to www.cloudshark.org and post the link.
Yep I appreciate that. The problem I have is that the captures are from a customer so I have to do a find and replace on the IP`s. Which wouldnt be so easy within a capture. Are there no pointers you can provide based on just the above ??