This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
[Fwd: FreeBSD network stack question]
- From: Barry Wealand <barry dot wealand at lmco dot com>
- To: ecos-discuss at sourceware dot org
- Date: Wed, 19 Oct 2005 10:25:03 +0000
- Subject: [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