This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: No joy on the network so far
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Chuck McManis <ecos at mcmanis dot com>
- Cc: ECOS Discussion Group <ecos-discuss at sources dot redhat dot com>
- Date: 15 Feb 2006 12:40:05 +0000
- Subject: Re: [ECOS] No joy on the network so far
- References: <6.1.2.0.2.20060215040442.02accec0@66.125.189.29>
Chuck McManis <ecos@mcmanis.com> writes:
> Well, its curiouser and curiouser ;-)
>
> Ok, so I've got my new driver written. Started with the rhine driver
> but pretty much replaced everything except the buffer handling code.
>
> I added some instrumentation to see packets being transmitted as well
> as packets being received. I've got tcpdump of course.
>
> In order to simplify things I configured redboot to NOT use bootp and
> instead merely assign the address 192.168.110.177 directly.
>
> It does, and it comes up to the redboot prompt, but if I try to ping
> my server (on the same subnet) it can't see it. Now tcpdump(8) can see
> my target board send out an ARP request for the server, and it sees
> the response. The printf's in the ethernet driver are showing that the
> ethernet chip is seeing those packets as well and fetching them in the
> _recv() function. But they never seem to make up into the networking
> stack where they belong.
>
> The weird thing is that with teh FXP driver configured this thing
> works entirely as expected so I don't think there are issues with my
> repository being out of date or something.
>
> What information can I provide that might give someone a clue about
> what is going on here?
Have you tried pinging your target board from your host. I usually
find this is a easier way of testing basic ethernet functionality.
You may need to trace the received packets further up into the redboot
IP stack. One possibility is that there's a fencepost problem and
something like the checksum is failing. Printing out whole packets
using diag_dump_buf() in the driver can often show where data is being
scrambled -- although this does require a bit of familiarity with
ethernet and IP packet formats.
It is almost certain to be a problem in the ethernet driver, but you
need to find out why the packets are being dropped in the IP stack to
find out what is going wrong lower down.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
Besuchen Sie uns vom 14.-16.02.06 auf der Embedded World 2006, Stand 11-222
Visit us at Embedded World 2006, NÃrnberg, Germany, 14-16 Feb, Stand 11-222
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss