• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 2698 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 ARP Processing

Jason Kalin
Intellectual 295 points


 

DM6437, NDK 2.0, BIOS 5.33.

 

I am sending an IP/UDP broadcast(FF.FF.FF.FF) packet from my PC to a thread with a socket bound to INADDR_ANY.

The packet is received(and processed) by my handling thread in all cases.

If I ping the DM6437 interface first, when the thread sends it's response it succeeds.

If I don't ping the DM6437 first then the responding send() operation fails from the thread with no route found.

In either case, wireshark never observes an arp request from the DM6437 to the PC.

I have dbgprintf() fully enabled and there are no errors or warnings.

Looking at llout.c/llin.c, it would seem that in the first successful case the code takes the ARP

preceding the ping from the PC and saves an lli for the PC so the send() works.  In the 2nd

case, it would seem that I should see some sort of dbgprintf() display unless it gets all the way

to the end of LLIGenARPPacket() before it fails.  The question is - why is no ARP getting

out on the wire to the PC?

 

Beyond that, are there debug libraries available or a .pjt so I can build and step in and see why

it is failing before generating an ARP in the 2nd case?

 

Are there any known bugs outstanding with this functionality that I should be aware of?

 

Regards,

Jason Kalin

 

  • 0
    TI__Expert 4125 points

    Jason,

    Sorry, but I don't know the answer here, but we don't have any outstanding issues related to this. I can't see any obvious debug code to help out. Unfortunately, the people most likely to help will be out for Thanksgiving holiday here, so it will likely be next Monday before we can look more at this.

    Mark

  • 0
    TI__Mastermind 45025 points

    Hi Jason Kalin,

    Do you know what priority the net scheduler is running at within your program? I'm wondering if this may be a scheduling problem.  From the NDK User's Guide (spru524_ug.pdf section 3.2.1 Default Environment API Restrictions) I see this:

    If a task calls send() in a loop using UDP, and the destination IP address is not in the ARP table,
    the UDP packets are not sent because the scheduler thread is never allowed to run to process the
    ARP reply.

    The priority of the net scheduler is set in the call to NC_SystemOpen() in your application.

    ----

    If you wish to try to dig into this a bit yourself, there's a trick that you can use to debug the stack code.  What you would need to do is to add the NDK source file (that defines the function you want to step through) to your project.  This will trick the linker into using the debug *.obj files from your project over the non-debug ones in the library.

    Please give that a try and see if it works for you.

    Thanks,

    Steve

  • 0 in reply to Steven Connell
    Intellectual 295 points

     

    I debugged into ipout.c and I determined that the mask for the subnet route was corrupted so iptxpacket() was failing

    right before the ARP should have been issued.  The routing table was being configured incorrectly(corrupted by me)

    for the subnet route.  Easy enough to correct - thanks for the help.  Is there a CCS3.3 .pjt available for building the

    entire NDK debug?

     

    Regards,

    Jason Kalin

  • 0 in reply to Jason Kalin
    TI__Mastermind 45025 points

    Do you need to rebuild the core libraries? (because it sounded like the corruption was coming from your code?)

    The reason I ask is because, while the stack sources are shipped in NDK 2.0.0, it looks like the build scripts (needed to support a rebuild) were not shipped in NDK 2.0.0.  This is probably a bug.

    What this means is that rebuilding the core won't be easy.  However, not impossible.  There are a couple of options that I can think of:

    1.      move to NDK 2.1.0

    a.       this version of the NDK has the necessary build files.

    b.      or, you could even move to the latest and greatest, NDK 2.20.05.33

    c.       both of these are located here: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html

    d.      instructions for rebuilding are here: http://processors.wiki.ti.com/index.php/Rebuilding_the_NDK_Core

    2.      If you don't want to switch NDK versions, you could copy all of the needed build files from one of these newer products and into your 2.0.0 install.

     

    #2 may be a bit tedious, but you’d basically need to copy all of these files into the same location in your 2.0.0 installation:

     

    C:\Program Files\Texas Instruments\ndk_2_20_05_33\packages\ti\ndk>ls *.xdc *.bld*

     *.xs

    Settings.xdc  package.bld  package.xdc  package.xs config.bld.default

     

    C:\Program Files\Texas Instruments\ndk_2_20_05_33\packages\ti\ndk\build>ls

    buildlib.xs

     

    C:\Program Files\Texas Instruments\ndk_2_20_05_33\packages\ti\ndk\src>ls *.xs

    Module.xs

     

    C:\Program Files\Texas Instruments\ndk_2_20_05_33\packages\ti\ndk\src>ls */*.xs

    hal/Build.xs         netctrl/Build.xs   os/Build.xs     tools/Build.xs

    miniPrintf/Build.xs  nettools/Build.xs  stack/Build.xs

     

    Once all of these files are present, you should be able to follow the steps on the above linked web page to rebuild

    Steve

  • 0 in reply to Jason Kalin
    Prodigy 10 points
    Hello Jason,

    I'm having the same problem with NDK on 6678. I keep getting "No route to host" error, and when I check the wireshark, I cannot see any ARP packets sent. But when I ping the 6678, it can find the route and all the packets are sent. That's kind of a long shot since you wrote this post almost 4 years ago, but do you still remember how you solved that problem?

    Thank you.

    -Mehmet