public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Arnaud Chataignier" <achataignier@neotion.com>
To: "'Barry Wealand'" <barry.wealand@lmco.com>,
	<ecos-discuss@sourceware.org>
Subject: [ECOS] RE : [ECOS] [Fwd: FreeBSD network stack question]
Date: Fri, 21 Oct 2005 12:04:00 -0000	[thread overview]
Message-ID: <013301c5d637$8e504de0$140032be@ArnaudC> (raw)
In-Reply-To: <43561EFF.8030200@lmco.com>

May be you should try this patch, it may be related to your problem. I
think it has been incorporated in CVS from then , but may be you don't
have the latest version ?

http://sourceware.org/ml/ecos-patches/2005-06/msg00041.html

Regards,
Arnaud.

-----Message d'origine-----
De : ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] De la part de Barry
Wealand
Envoyé : mercredi 19 octobre 2005 12:25
À : ecos-discuss@sourceware.org
Objet : [ECOS] [Fwd: FreeBSD network stack question]



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?

Thanks!!

Barry Wealand
barry.wealand@lmco.com




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

      parent reply	other threads:[~2005-10-21 12:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-19 17:26 Barry Wealand
2005-10-19 18:01 ` Daniel Helgason
2005-10-19 18:01 ` Gary Thomas
2005-10-19 19:11   ` Barry Wealand
2005-10-19 18:20 ` [ECOS] " Grant Edwards
2005-10-19 20:57   ` Andrew Lunn
2005-10-19 21:16     ` Grant Edwards
2005-10-21 12:04 ` Arnaud Chataignier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='013301c5d637$8e504de0$140032be@ArnaudC' \
    --to=achataignier@neotion.com \
    --cc=barry.wealand@lmco.com \
    --cc=ecos-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).