Wierd networking.

I have been looking at the following snippet of packets (under FreeBSD 6.1).

This makes IE7 fail (but not IE6) with a generic error.

We see lots of strange things here.. (like, why does the RST
go to a different sequence number?)

What we are having problems with is:

What SHOULD the server be doing in response to the extra 2 bytes
it receives after it has sent the FIN?

I would LIKE to be able to make this work, but I don't personally
have the influence to fix IE7 so I'm left to do what I can on the server (port 3128) end.

The FIN from the server is generated when the server closes the socket.






Attachment: IE7.pcap
Description: Binary data

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Wierd networking.
    ... This makes IE7 fail with a generic error. ... (like, why does the RST ... have the influence to fix IE7 so I'm left to do what I can on the server end. ... The FIN from the server is generated when the server closes the socket. ...
    (freebsd-net)
  • Re: Redhat Enterprise 4 and 15 second delays with NFS via TCP
    ... if the server and client had the same value for the connection ... By making the server idle timer much ... >>> the connection as in send a FIN? ...
    (comp.protocols.nfs)
  • Re: httplib continuation packets
    ... Guess I'll have to use Perl. ... It really does seem quite bizarre that a server should respond differently to the same TCP request when it is split differently into IP datagrams. ... There really is nothing wrong with sending FIN with your last data segment. ... FIN means "I guarantee to send no more data, and will continue to acknowledge your segments until I see your FIN". ...
    (comp.lang.python)
  • Re: FIN_WAIT_2 status at Client side
    ... sent a FIN, received an ACK of the FIN, and you're waiting for the other ... The server, ... The client has to respond with ACK and then sends its own FIN which then requires a last ACK from the server side. ... The state that the connection is in during the period between when the server gets the ACK from the client and the server gets the FIN from the client is known as FIN_WAIT_2. ...
    (comp.unix.aix)
  • Re: TCP socket close problem
    ... This FIN is ignored by the server. ... If closewas called, the second packet would _NOT_ be ACKed, the ... stack should go "immediately" to sending a RST. ...
    (comp.unix.bsd.freebsd.misc)