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
prev 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).