["Marco Rommelse" <m.rommelse@xxxxxxxxx>]

Tom,

This is my view:

1  C TCP  2394 > http [SYN] Seq=1716877397 Ack=0 Win=65535 Len=0
2  S TCP  http > 2394 [SYN, ACK] Seq=9296 Ack=1716877398 Win=2048 Len=0
3  C TCP  2394 > http [ACK] Seq=1716877398 Ack=9297 Win=65535 Len=0
4  C HTTP GET /titleMIH.gif HTTP/1.1
5  S TCP  http > 2394 [FIN, ACK] Seq=9297 Ack=1716877398 Win=2048 Len=0
6  C TCP  2394 > http [ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
7  C TCP  2394 > http [FIN, ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
8  S TCP  http > 2394 [ACK] Seq=9298 Ack=1716877398 Win=2048 Len=0
9  C HTTP GET /titleMIH.gif HTTP/1.1
10 S TCP  http > 2394 [ACK] Seq=9298 Ack=1716877667 Win=2048 Len=0
11 C TCP  2394 > http [FIN, ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
12 S TCP  http > 2394 [RST, ACK] Seq=9299 Ack=1716877668 Win=2048 Len=0

1,2,3: Normal syn, syn/ack, ack behaviour. It is mandatory in tcp to count 1
byte for the recieved syn/ack packet.

4: Client sends get request of about 269 bytes.

5: Server probably didn't get the data, sends a fin with the old ack no.
Without time indication it is hard to tell if this could simply be caused by
a time-out.

6: Client ack's the Fin packet, letting the server know that it got the fin
packet it by counting 1 byte to the seq.no. of the server. Note that the
client is showing the normal seq.no.

7: Now the client Fin's the connection.

8: The server ack's, but doesn't ack the fin of the client. Note the
ack.no.: this is the tcp way of letting the other end know that it has lost
packets.

9: The client resends the Get request.

10: The Get request is recieved by the server and is acked.

11: Since the first Fin/ack packet sent by the client (packet 7) wasn't
acked by the server, the client is also resending this one.

12: The server now resets the connection after recieving the fin/ack,
cleaning up the connection.

Hope this helps.
Marco Rommelse


----- Original Message ----- 
From: "Tom C. Barker" <TomBarker@xxxxxxxxxxxx>
To: <ethereal-users@xxxxxxxxxxxx>
Sent: Tuesday, January 13, 2004 12:44 AM
Subject: [Ethereal-users] Advice on an HTTP request


> Hello,
>
> Following is an Ethereal dump of an HTTP request for a graphic. The
browser
> requesting the file is IE 6.01, but I have seen this on Netscape also.
> In line 4, "C HTTP GET /titleMIH.gif HTTP/1.1" was corrupted at reception
> and did not pass the checksum routine (ok, fine). Next the connection
> closes.
> Curiously, the client asks for the file again, without ever setting up the
> connection (so it seems to me). The server then ACKS, I think (8), and
then
> the conversation ends.
>
> Could someone offer me an explanation as to what might be happening here
> and if there is any necessary tweaking that might go on in the server code
> to recover? Is this conversation proper in light of the fact the the
second
> request may have been dropped at the hardware also? Any comments to the
> appropriateness of how the browser is acting in this conversation is
> certainly
> welcome.
>
> Thanks,
> Tom Barker
>
>
> 1  C TCP  2394 > http [SYN] Seq=1716877397 Ack=0 Win=65535 Len=0
> 2  S TCP  http > 2394 [SYN, ACK] Seq=9296 Ack=1716877398 Win=2048 Len=0
> 3  C TCP  2394 > http [ACK] Seq=1716877398 Ack=9297 Win=65535 Len=0
> 4  C HTTP GET /titleMIH.gif HTTP/1.1
> 5  S TCP  http > 2394 [FIN, ACK] Seq=9297 Ack=1716877398 Win=2048 Len=0
> 6  C TCP  2394 > http [ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
> 7  C TCP  2394 > http [FIN, ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
> 8  S TCP  http > 2394 [ACK] Seq=9298 Ack=1716877398 Win=2048 Len=0
> 9  C HTTP GET /titleMIH.gif HTTP/1.1
> 10 S TCP  http > 2394 [ACK] Seq=9298 Ack=1716877667 Win=2048 Len=0
> 11 C TCP  2394 > http [FIN, ACK] Seq=1716877667 Ack=9298 Win=65535 Len=0
> 12 S TCP  http > 2394 [RST, ACK] Seq=9299 Ack=1716877668 Win=2048 Len=0
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>