From owner-freebsd-net Tue Aug 14 2:57:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by hub.freebsd.org (Postfix) with ESMTP id D300637B407 for ; Tue, 14 Aug 2001 02:57:45 -0700 (PDT) (envelope-from gerhard.butscher@esk.fhg.de) Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id f7E9vgt11998; Tue, 14 Aug 2001 11:57:42 +0200 (MET DST) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id f7E9vfW11994; Tue, 14 Aug 2001 11:57:41 +0200 (MET DST) Received: from esk.fhg.de (host5-14 [192.168.5.14]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id LAA03444; Tue, 14 Aug 2001 11:57:39 +0200 (MET DST) Message-ID: <3B78F5E1.475FF891@esk.fhg.de> Date: Tue, 14 Aug 2001 11:56:49 +0200 From: Gerhard Butscher Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de,fr MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: syslinux@linux.kernel.org, net@FreeBSD.ORG Subject: TFTP sorcerer's apprentice syndrome Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Hello, I am using the linux (SuSE 7.0) tftp server with an embedded tftp client (running on an embedded target). I changed that client code and caused by that change a considerable amount of delay. And the Sorcerer's Apprentice Syndrome appeared: From that point where the server has sent a duplicate data packet (after the client's ACK timed out), there were always duplicate data (and of course ACK) packets until the end of the file transfer. I am not a protocol expert nor a unix programming expert but as far as I understand the tftp server code (e.g. tftp-hpa-0.21) there is a handling for duplicate ACK packets. But (maybe) not exactly the handling proposed by the RFC 1350. On paget 7 of RFC 1350 it is said: "All packets other than duplicate ACK's and those used for termination are acknowledged unless a timeout occcurs." So the strategy would be to discard the duplicate ACK and let the timer keep running. Not repeating the previous data packet - which I think is done in the existing code. The data packet would only be repeated in case of a timeout. I would appreciate if you could write a comment whether I am right or wrong or something in between. Best regards, Gerhard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message