This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Configuring the NDK to work with DHCP

Other Parts Discussed in Thread: TMS320C6455

My customer has the following issue

We’re using TI Code Composer 3.3 with the Network Development Kit.  The NDK’s .tci file has this version in comments at the top: 

TCP/IP_Network_Developers_Kit 1.93.00.09 08-16-2007 (ndk-c09)

 We’ve been successfully using it with a static IP addresses for some time, but we need to transition to DHCP to support program testing efforts.  We’ve seen our units obtain an IP address using DHCP on our corporate network, which has Microsoft’s DHCP server software running on a dedicated computer.  Our test environment will be a small local network using something like a Linksys router or Microsoft’s Internet Connection Sharing (ICS) for DHCP to provide IP addresses.  We’ve tried both scenarios and from packet-sniffing we can tell that our unit is sending a DHCP request, but nothing comes back from the server.  We’ve tested both setups by plugging in other DHCP client devices, and they obtain IP addresses, so we know the basic setup works.  It seems like the DHCP server is ignoring our requests for some reason, perhaps an option is missing in the request?

 We’d like to know: are there any app notes with additional information about configuring the NDK to work with DHCP?  Any insight you can provide would be greatly appreciated, thanks!

Thanks Todd

  • Todd,

     

    What device is the customer using?

    Can you please ask them to try running the NDK example "client" on their set up?  The client example uses DHCP to obtain an IP address.

    The testing we did for NDK 1.93 was insided a corporate network, but both the test PC and target device were hooked up to a router (most likely a linksys one).

     

    Steve

  • Steve,

        They are using the TMS320C6455.  I have asked them to client example.

    Todd

  • From the customer;

    I ran the example with our corporate server and got:

                   TCP/IP Stack Example Client

    Using MAC Address: 00-00-00-00-02-00

    Service Status: DHCPC    : Enabled  :          : 000

    Service Status: Telnet   : Enabled  :          : 000

    Service Status: HTTP     : Enabled  :          : 000

    Service Status: DHCPC    : Enabled  : Running  : 000

    Link Status: 100Mb/s Full Duplex on PHY 0

    Network Added: If-1:166.20.139.250

    Service Status: DHCPC    : Enabled  : Running  : 017

     

    System could be pinged at the assigned IP address.  Then I ran it with the Linksys router and got:

     

    TCP/IP Stack Example Client

    Using MAC Address: 00-00-00-00-02-00

    Service Status: DHCPC    : Enabled  :          : 000

    Service Status: Telnet   : Enabled  :          : 000

    Service Status: HTTP     : Enabled  :          : 000

    Service Status: DHCPC    : Enabled  : Running  : 000

    Link Status: 100Mb/s Full Duplex on PHY 0

     

    Wireshark shows periodic “DHCP discover” requests from the DSP but no response from the router (using a Linksys BEFSX41 with default settings).

     

    I notice when my laptop gets an address it starts off with a “DHCP request”.  Perhaps when we’re talking to the simple DHCP servers there’s a state we need to skip?

  • Todd,

    As Steve said, NDK out-of-the-box client example is preconfigured for DHCP and throughout the years I haven't had any major troubles using it with standard off-the-shelf routers' DHCP server.

    However I noticed something strange. Although you can connect to the corporate router, the output message seems to indicate there is something terribly wrong with the MAC address of your customer's board - 00:00:00:00:02:00 is really an unusual address (the first three bytes indicate the PHY manufacturer, and 00:00:00 is allocated to Xerox corp).

    In a contained network where all IP addresses are static you should have no issues, but the off-the-shelf router may be acting "smart" and is filtering ranges of odd MAC addresses - don't ask why; I've seen several cases strange behaviour caused by the built-in firewall and other securiy-improvement features. Corporate routers are way more configurable and therefore less prone to hidden features.

    In this case, I would try first to run the same client example in a DSK or EVM board with the proper GEL files (they influence reading the MAC address registers); then I would assign a different MAC address to the board and see if this works. If this is not possible, I would do trial-and-error and test different brands of routers.

    Hope this helps,

    Rafael

     

  • Todd,

    I had the same issue on our DM642 products.  Check out the thread below for my solution:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6182/226520.aspx?PageIndex=1

    I had to rebuild part of the NDK, but it did get DHCP working.  I think some DHCP servers may be more sensitive to an improperly formatted DHCP DISCOVER message, so some people see this problem and some don't.

    Paul Randall