• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 903 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

NDK DHCP client does not work with linksys router

cobsonchael
Mastermind 7930 points
Other Parts Discussed in Thread: SYSBIOS

So here is what i am using.

CCSv5.2.1

SYSBIOS 6.33.7.53

NDK 2.21.1.38

Linksys WRT54G2 v1.5 router

When i run the DHCP client there is no response to the DHCP discover packets. i wiresharked it and the router does not respond. i tried it with a computer and the router works fine, power cycled it and everything. i tried the DHCP client with an older linksys router and it works fine.  

then i remember a problem we used to have with the NDK and linksys routers.  for some reason the NDK pads the DHCP packets with as many 0s as possible and linksys routers don't seem to like this. so i went to ndk_2_21_01_38\packages\ti\ndk\nettools\dhcp and i opened dhcp.h, line 56 and changed the SZOPTIONS back to 312. i rebuilt the NDK and it worked.

SO somebody must have a bug.  i am doing a firmware update on the router and changing the dhcp client back to normal to see if it is linksys.

  • 0
    Mastermind 7930 points

    i updated the router and it is still broken. so who's at fault here?

    is this a known issue with this version of router?

  • 0 in reply to cobsonchael
    TI__Mastermind 45025 points

    Mike,

    I've been looking into this issue.  From what I've seen on the forums, some routers are able to handle the larger option size, however others (as in your case) will drop the DHCP discover packet.

    In short, it's looking like a bug in the NDK.  I think the value of SZOPTIONS should be changed back to be 312.  For now I think you should stick with your workaround.

    For the record, a number of years ago the value of SZOPTIONS was increased to 576 in order to fix the following bug:

    CQ15114 - "NDK does not send host names longer than 19 characters on
        the DHCP request packet"

    So the options size was increased to be able to handle a longer host name.  However, RFC 2131 may have been misinterpreted.

    I've filed a bug for this:

    SDOCM00095765 DHCP option size should be reduced back to 312 as size of 512 causes discover packet to be dropped on some routers

    Also, there are some related posts on this:

    http://e2e.ti.com/support/embedded/bios/f/355/p/168357/615772.aspx#615772

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/6182.aspx?PageIndex=2

    http://e2e.ti.com/support/embedded/bios/f/355/t/168357.aspx#614776

    Steve

  • 0 in reply to Steven Connell
    Prodigy 90 points

    Hello,

    I ran into a similar problem with my concerto board,

    the truth is I am not confortable with the rebluiding of the libraries (I tried to follow the step provided here: http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Building_CSL_and_the_Low_Level_Device_Drivers but for the third item I didn't found the ccs project file for my library "In the Select search-directory: enter C:\Program Files\Texas Instruments\pdk_C667##_#_#_#_##\packages\ti\platform\evmc667#l\platform_lib and hit Browse. See Import Project Settings. This will import platform_lib_evmc667## into the workspace. In the Select search-directory: enter C:\Program Files\Texas Instruments\pdk_C667##_#_#_#_##\packages\ti\platform\evmc667#l\platform_lib and hit Browse. See Import Project Settings. This will import platform_lib_evmc667## into the workspace. ")

    I wonder, in place of going back to 312, could this parameter not be accessible from cfg/dhcp client settings with its default value either 312 or 576, so that one can easily select its prefered size without the bother of rebuilding its library?

    Thank you

    Laurent

  • 0 in reply to Laurent Gelbgras
    TI__Mastermind 45025 points

    Hi Laurent,

    First, I want to make sure you are using all the correct software.  You are using Concerto? (i.e. M3 ARM processor and or C28x processor?)

    If so, the BIOS MCSDK and PDK software you are referencing is not for that hardware.  That software is for the C6000 family of (multi-core) processors and are not the correct instructions for rebuilding the NDK (that's here: http://processors.wiki.ti.com/index.php/Rebuilding_The_NDK_Core_Using_Gmake)

    If you're on Concerto, you would need to use TI-RTOS (a.k.a. MCUSDK ... very similar name to the C6x MCSDK, I know).  You can download the latest version of TI-RTOS here:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/mcusdk/index.html

    Laurent Gelbgras said:
    I wonder, in place of going back to 312, could this parameter not be accessible from cfg/dhcp client settings with its default value either 312 or 576, so that one can easily select its prefered size without the bother of rebuilding its library?

    Unfortunately the fix is not that simple to make that parameter configurable (it would require some code generation and link order tricks that could become messy).  The good news, however, is that the bug mentioned here has actually been fixed in the latest NDK release.  So if you grab the latest NDK you'll have the library already built with size 312.

    You can grab the latest NDK release from here:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html

    Steve

  • 0 in reply to Steven Connell
    Prodigy 90 points

    I am indeed using the concerto F28M35H52C1, I use MCUSDK 1.00.01.74 on M3 side (ndk 2.21.01.38)  and bios 6.34.02.18 on C28.

    I found this post and the proposed solution while "google browsing" the forum for error dhcp '002', I just assumed I could do a similar manipulation with MCUSDK (but well, I can't say I'm too familiar with TiRTOS and all its possibilities yet!.)

    using DHCP was simply easier with the 'classical' network environement of my compagny, but the hardware we develop will live in a closed/controlled environement. It is thus possible to use static IP without problem.

    I will download this new version of ndk and see If I am abble to get the Ip address!

    Thank you for your kind reply

    [ edit: sorry I can't verify your answer / don't see the button]

    Laurent