Re: Question regd timestamp option

From: Chuck Swiger (cswiger_at_mac.com)
Date: 08/12/05

  • Next message: Julian Elischer: "Re: 5.4 -- bridging, ipfw, dot1q" 
    Date: Fri, 12 Aug 2005 17:14:59 -0400
To: Miku Jha <jha_miku@yahoo.com>

    Miku Jha wrote:
    [ ... ]
    > The situation is that if the client crashes, the server eventually sends a
    > RST (10.39.53) Following this RST, the client comes back in lets say around
    > 2-3 minutes. Now when the client sends a SYN(10.42.23), there is no
    > timestamp option.

    If the client opens a connection and both sides exchange packets with
    timestamps, you'll probably end up seeing "NNT" in all packets during the first
    session. This right?

    Now if you open a second connection, while things are still OK, do you see the
    SYN packet contain all options as normal? I assume the client is opening
    connections to the server? And it is a FreeBSD box...?

    Showing tcpdump data (or putting on a website somewhere) would help understand
    the issue...

    > Is there some requirement that RST needs to be ACKED
    > or RST flag will remain set for some time window
    > within which if SYN is send, timestamp option will not
    > be set.

    A RST to a closed or listening socket will be ignored (dropped), a RST which
    matches an established connection will flush and close that connection but will
    not be ACKed itself. 

    -- 
-Chuck
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: 5.4 -- bridging, ipfw, dot1q"

    Relevant Pages

    • Re: Socket weirdness
      ... If RST is at the top of the stack before the ... RST is not "seen" by the client until the first ACK to client *after ... a Shutdown.Receive by the server. ... some N factor of stocks or time and closes socket. ...
      (microsoft.public.dotnet.framework)
    • Re: Socket weirdness
      ... why RST is not set in the header of outgoing data if the server does a send after Receive is closed? ... Or why the server even lets you do a send after a Shutdown.Receive if ultimately it forces both sides of the client down anyway? ... Server cannot send RST on send after shutdown on its receive part because it would violate the TCP standard. ... The problem when you do Shutdown.Recv is what TCP stack should do when it receives data on this connection anyway? ...
      (microsoft.public.dotnet.framework)
    • Re: Socket Connections - never seem to close
      ... > explicitly invoking the java.net.Socket.closemethod, the Server ... > socket connections in the ESTABLISHED state, whereas on the client ... > end 'netstat' shows no trace of the socket connections. ... abortive close segment - RST rather than FIN. ...
      (comp.sys.hp.hpux)
    • Re: TCP reset caused by socket.py
      ... with the connection, usually a half-open connection. ... | Reset Generation ... Instead I see the server send data to the client and then a RST, ...
      (comp.lang.python)
    • Re: Socket weirdness
      ... If RST is at the top of the stack before the ... RST is not "seen" by the client until the first ACK to client *after ... a Shutdown.Receive by the server. ... some N factor of stocks or time and closes socket. ...
      (microsoft.public.dotnet.framework)