From owner-freebsd-net Thu Dec 13 14:53:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 3024937B417 for ; Thu, 13 Dec 2001 14:53:08 -0800 (PST) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id fBDMr7S42070 for freebsd-net@freebsd.org; Thu, 13 Dec 2001 16:53:07 -0600 (CST) (envelope-from tinguely) Date: Thu, 13 Dec 2001 16:53:07 -0600 (CST) From: mark tinguely Message-Id: <200112132253.fBDMr7S42070@web.cs.ndsu.nodak.edu> To: freebsd-net@freebsd.org Subject: TCP snd_recover Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am playing with RFC 3042 and notice some strange dupacks count sequences. One place I see a problem is with snd_recover and newreno: if (tcp_do_newreno && SEQ_LT(th->th_ack, tp->snd_recover)) { if th->th_ack > 0x7fffffff and snd_recover has not been initialized, the problem results in a ACK loop that continues until a rexmt timer expires, and a side effect of timer, the snd_recover is finally set. from looking things over, this could happen from wrapping sequences also since we do not check if snd_una <= snd_recover <= snd_max, but less likely. I have not caught this in a trace yet. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message