This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Some debug output
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Chuck McManis <ecos at mcmanis dot com>
- Cc: ECOS Discussion Group <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 14 Feb 2006 09:52:07 +0100
- Subject: Re: [ECOS] Some debug output
- References: <6.1.2.0.2.20060213171612.04321ec0@66.125.189.29>
>> vt8235_RxEvent
> RxEvent - CSR: 0x0003
> ##Rx packet 0 RDES 0012a6d0 stat 00409700
> RxEvent good rx - stat: 0x00409700, len: 0x0040
> RDES: 00409700 00000608 0012a710 0012a6e0
> Packet data at 0x0012a710
> ff ff ff ff ff ff 00 e0 21 00 02 d6 08 06 00 01 08 00 06 04 00 01 00 e0 21
> 00 02 d6 c0 a8 6e fe 00 00 00 00 00 00 c0 a8 6e 6c 7e 7e 7e 7e 7e 7e 7e 7e
> 7e 7e 7e 7e 7e 7e 7e 7e 7e 7e a6 4f 22 13
This looks like an ARP packet to me, not a BOOTP responce. So the
device is correct to drop it.
Your bootp/dhcp server is checking that no device is using the IP
address it is about to allocate. If it gets a responce to this message
it knows something is using the address and it needs to pick another
one.
What is more interesting is the next packet the server sends. That is
probably the bootp responce. But it looks like you do not receive any
more packets.... Maybe your receive code is not quite correct when
finishing with this receive and so it does not receive any more
packets?
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss