DHCP Fault 002

Anyone?

Did you take a look at the NDK wiki?

Some possible related issues:

http://tiexpressdsp.com/index.php/Network_Developers_Kit_FAQ#Q:_What_are_the_numbers_shown_in_the_Service_report_messages_for_the_DHCP.3F

http://tiexpressdsp.com/index.php/Network_Developers_Kit_FAQ#Q:_Why_does_the_DHCP_client_seems_to_give_up_after_a_certain_period_of_time_if_the_Ethernet_cable_is_disconnected_when_the_NDK_boots_up.3F

I did, thank you.  I was not able to resolve the problem though.  I just get stuck with the fault.

well, as you probably already saw:

The Fault : 002 is a state error code from the DHCP client, and usually occurs when the DHCP server is not ACKing the IP request from NDK - it may be offline or disconnected from the subnet.

So it could be an issue with your DHCP server.

Some customer have had problems with DM648 and DHCP if they do not use a GEL file to connect to the board. Can you check that?

Yeah, I've got the gel file

Okay... so I rolled back from ndk 2 to ndk 1.92 and it works perfectly, though I did have to change to clock frequency to 125MHz.  Any ideas why ndk 2 fails to get an ip address?

I do not know, but I will give feedback about this internally.

Thanks,

Greatly appreciated!

Was there ever a response to this? I am having the same issue on 674x, and have verified the DHCP works on all other devices but the NDK. It seems the recv() never gets the DISCOVER response.

I'm using NDK 2.0 on DSK6455.  I'm seeing the fault 2 on both my app and the example "client" app.

Can someone from TI please address why NDK 2 is behaving this way?

Secondary question:  What was patched on NDK 2.0?  I have installed the patch and read the README.  But, I don't find any notes in "ethrdriver.c".

Miriana

Where to get the latest DM648EVM gel file? If you have, would you please past it on the forum?

Hi,

I have just run into this same issue after upgrading to NDK 2.0.0.  I am running on a custom board with a DM642 processor.

With Wireshark, I can see our board send out a DHCP DISCOVER broadcast, but it never seems to get a response.

Has anyone else been able to resolve this problem?

Paul Randall

Hi,

There is a known issue on DM648 with connecting to 10/100 Mbps network. Please check if you are also facing a similar issue or not.

Please see the link below  which explains the issue with the solution to it -

http://e2e.ti.com/support/embedded/f/355/p/57649/205966.aspx

Thanks,

Prathap.

Can we please get a response to this? I am still not having any luck on the 6747 with the NDK 2.0 DHCP client. And here are a few people here having the same issues with other platforms, so there is something going on.

I have been waiting for an answer for a while and am officially stuck. Thanks.

BTW debugging the DHCPC code it looks like the packet is formed and send, but the recv() call fails with -1. So is there a bug with sockets that do not have IP associated yet?

Ok, I think I have found out why I was getting the DHCP fault.

Using Wireshark, I captured the DHCP DISCOVER message generated by the old NDK (which the DCHP server responds to) and then again by the NDK 2.0 (which the server does not respond to).  The DISCOVER messages were identical, except for the fact that the old NDK Ethernet frame size for the message was 590 bytes and the NDK 2.0 frame size was 854.  The NDK 2.0 DISCOVER message had many more zeros of padding.  I suspected that it was the extra length of the DISCOVER message was causing our DHCP server (a Netgear FVS318) to discard the message for some reason.

I started looking into the NDK source and found the following code in dhcp.h:

/*
 *  Size of DHCP options field.  576 bytes is the maximum per RFC 2131; the
 *  minimum is 312 bytes, and was the previous value.
 */
#define SZOPTIONS           576

I then looked at RFC 2131 and it says the following regarding the options field:

   The 'options' field is now variable length. A DHCP client must be
   prepared to receive DHCP messages with an 'options' field of at least
   length 312 octets.  This requirement implies that a DHCP client must
   be prepared to receive a message of up to 576 octets, the minimum IP
   datagram size an IP host must be prepared to accept [3].  DHCP
   clients may negotiate the use of larger DHCP messages through the
   'maximum DHCP message size' option.  The options field may be further
   extended into the 'file' and 'sname' fields.

It looks like the SZOPTIONS field was incorrectly increased from 312 to 576 in the NDK 2.0. The 576 bytes is the maximum DHCP DISCOVER message size, not the maximum options size.

I recompiled the nettools library with the SZOPTIONS changed to 312 and DHCP worked!

I think some DHCP might be able to accept DHCP DISCOVER messages larger than 576 bytes, while some discard them which is why some people see this problem and some don't.

I suggest the NDK be fixed in the next release to set SZOPTIONS back to 312.

Paul

Thank you so much for taking the time and posting what you found. I was about to start chasing down this exact issue, after multiple support posts and calls to TI about DHCP not working.

I generally am very pleased with TI support and products, but some issues like this, when reported over and over and ignored, yet are so much a big part of the usability of the TI parts, can leave some of us hanging. If it wasn't for the great people in these forums.

I still can not perform the initial test from the quick start guide.  I keep coming again and again fail 002.

anyone know where I can find a video of the first part?

Mauricio J.

maurojv@hotmail.com