From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26792 invoked by alias); 19 Oct 2005 18:01:25 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 26779 invoked by uid 22791); 19 Oct 2005 18:01:22 -0000 Received: from sta-204-188-98-138.rockynet.com (HELO hermes.chez-thomas.org) (204.188.98.138) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 19 Oct 2005 18:01:22 +0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id DA7682C87DA31; Wed, 19 Oct 2005 12:00:59 -0600 (MDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id 3958E2C8C3512; Wed, 19 Oct 2005 12:00:56 -0600 (MDT) From: Gary Thomas To: Barry Wealand Cc: eCos Discussion In-Reply-To: <43561EFF.8030200@lmco.com> References: <43561EFF.8030200@lmco.com> Content-Type: text/plain Date: Wed, 19 Oct 2005 18:01:00 -0000 Message-Id: <1129744855.9769.7.camel@hermes> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] [Fwd: FreeBSD network stack question] X-SW-Source: 2005-10/txt/msg00141.txt.bz2 On Wed, 2005-10-19 at 10:25 +0000, Barry Wealand wrote: > Hello - > > We're working with a MIPS-like target, eCos 2.0, and the FreeBSD network > stack. I have a simple application that sends UDP messages to a host > server process, which sends back a short acknowledgement for each. > Message size can be varied - for the present problem, we're using a size > of 2K bytes. Of course, such messages must be fragmented before being > transmitted over an ethernet link. > > If we collect a packet trace with tcpdump, we see an ARP request and ARP > reply, then we see the 2nd segment of the first message - the first > segment of the first message is never transmitted. A little tracing > with GDB has shown that: > > 1. udp_output calls ip_output > 2. ip_output calls ether_output > 3. ether_output calls arpresolve > 4. arpresolve calls arprequest > 5. arprequest sends the ARP request message (recurses into > ether_output), then returns to arpresolve. > 6. arpresolve apparently operates asynchronously, and returns 0, > indicating that address resolution is not yet complete. (Meanwhile, in > due time, an ARP reply is received, providing the needed remote host's > ethernet address.) > 7. ether_output returns 0 to ip_output, indicating no errors. In > effect, the first segment has been dropped. > 8. ip_output believes that all is well with the first segment and > proceeds to send the second. By now, the ARP resolution process has > completed, and the second segment is transmitted normally. > > Is this normal? If not, do you have any idea what we might we be doing > wrong that could lead to this behavior? I don't think this is normal, but UDP is by design not guaranteed reliable. Would it be possible to post your program(s) so they could be tested on other systems? n.b. eCos 2.0 is now more than 3 years old - quite a lot has happened in the meantime :-) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss