From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16210 invoked by alias); 18 May 2006 13:40:04 -0000 Received: (qmail 16192 invoked by uid 22791); 18 May 2006 13:40:03 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,TW_WP X-Spam-Check-By: sourceware.org Received: from dns2-chi.paetec.net (HELO dns2-chi.paetec.net) (64.80.249.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 May 2006 13:40:00 +0000 Received: from dtcsrvr09.dtccom.com ([66.153.88.146]) by dns2-chi.paetec.net (8.13.6/8.13.6) with ESMTP id k4IDdjax004036; Thu, 18 May 2006 09:39:50 -0400 (EDT) Received: by dtcsrvr09.dtccom.com with Internet Mail Service (5.5.2658.3) id ; Thu, 18 May 2006 09:39:12 -0400 Message-ID: From: "Doyle, Patrick" To: "'Andrew Lunn'" Cc: "'ecos-devel@sources.redhat.com'" , "'Andrew Dyer'" Subject: RE: RedBoot patches regarding redboot_getc_terminate Date: Thu, 18 May 2006 13:40:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2006-05/txt/msg00017.txt.bz2 > > What happens to TFTP transfers with your change? Are they terminated > gracefully? Or do they hang around until the server times out and > kills them? > > Andrew > Unfortunately, I don't have any means to check that. Which is why I brought it up as a topic for discussion. Then I realized that it would be easier to discuss if somebody who _did_ have a means to check that checked that, which led to me posting the patch :-) IIRC, a TFTP server will keep spewing out packets until it has sent the whole file, and will retry and retransmit if the client stops responding. So, it guess it depends on what the TFTP transport stream (implemented in code somewhere in RedBoot) does when it gets a "terminate" call that isn't an abort... Hmmm... looking at the code, I see something that looks like: if (abort) tftp_error_ack(...) else tftp_ack(...) which looks to me like TFTP folks would be getting some sort of similar error message for TFTP transfers. I wonder why I'm the only one whose noticed this? (he asks in a plaintive, "why do these things always happen to me" voice) --wpd