From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1649 invoked by alias); 10 Aug 2012 09:57:45 -0000 Received: (qmail 1642 invoked by uid 22791); 10 Aug 2012 09:57:44 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Aug 2012 09:57:31 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id 5CF212F78005; Fri, 10 Aug 2012 10:57:30 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001522] Array index out of bounds in tftp_server.c X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: TCP/IP X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: bernd.edlinger@hotmail.de X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 10 Aug 2012 09:57:00 -0000 Message-Id: <20120810095727.AB73A2F78009@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2012/txt/msg01159.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001522 --- Comment #13 from Bernd Edlinger 2012-08-10 10:57:17 BST --- (In reply to comment #12) > I'm afraid I'm not. I don't use tftp and don't even have any > filesystem which it could access. I only stumbled across the original > bug because I was getting sick of wasting so much time sorting through > all the compiler warnings trying figure out which ones mattered and > which ones didn't. I do completely agree with you. > I think the existing code is rather badly and fundamentally broken. > If I were going to re-write it I'd probably throw out the whole > multi-thread prallel operation business and do a single-threaded, one > transfer at a time version that's as simple to understand and as > obviously correct as possible. > I don't know what the use case is for multiple parallel transfers. If > I _were_ to use tftp it would be for firmware updates which I'd force > to be a single transfer at a time anyway. True. Maybe this multi-threaded feature should be off by default in the cdl file. It is nearly impossible to fix it, because if every thread opens its own socket, the tcp stack does not know which one will be ready to handle the packet. Therefore I think, it is better to just fix the warning, by _not_ sending an error packet in the multi threaded operation. Nevertheless, i spent some effort to fix the error handling. However I found more subtle glitches in the error handling logic, than I had expected! I tested with the tftp_server_test, with and without multi-thread. Of course I did just send valid tftp packets with the windows tftp client, so the default case in the switch was never executed. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.