• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 2087 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 does not ARP default gateway

Felickao Yang
Intellectual 650 points

I'm am observing an issue, or what I believe is an issue, with the NDK stack. When sending a packet to an IP address that is not on the same subnet, the NDK is not sending out an ARP to resolve the route for the default gateway. Here is my test case:

I configured my PC with IP address 192.168.1.1 and subnet mask 255.255.0.0. I configured my device (AM335x using the NDK stack) with IP address 192.168.0.10, subnet mask 255.255.255.0, and default gateway 192.168.0.1 (which does not exist). On the PC, I send a UDP/IP packet to my device. My device receives the packet and sends a UDP/IP packet back to the PC.

In the test case above, I was expecting that my device would detect that the PC's IP address is incompatible (not on the same subnet), and my device would have to route the packet through the default gateway. I was expecting my device to send an ARP to resolve the default gateway's MAC address, but I did not observe this behavior via Wireshark (using a managed switch with port mirroring to observe all traffic with my device).

This is my setup: CCS V5.4.0.00091, NDK V2.22.02.16, SYS/BIOS V6.35.04.50, and XDC V3.25.03.72. I know that these are older versions, but I did not find any documentation on the newer NDK release notes that address this issue.

My first thought was that since my device was able to receive a packet, it would assume that it could use the same route to send the packet. However, this is not the case with other Ethernet devices that I have tested. Other Ethernet devices will send an ARP to resolve the default gateway, if the original sender's IP address is incompatible.

I would appreciate any help on this issue.

  • 0
    TI__Mastermind 26780 points

    Are you seeing no ARP requests at all in Wireshark (even gratuitous ARP)?

    I searched the forums for similar reports, and “no ARP”, and I found two that might be relevant:

    This post, where there is mention of possible scheduling issues, and a corrupted routing table: e2e.ti.com/.../148499

    And this post, which indicated the problem was localized to 192.168.1.1, which is what you are using for your PC: e2e.ti.com/.../151474

    Do these help?  If not, reply back and I can talk to an NDK expert about this…

    Thanks,
    Scott

  • 0 in reply to ScottG
    Intellectual 650 points

    Hello Scott,

    When my device powers on, I do not see any gratuitous ARPs. I'm not really concerned about this, as the "gratuitous" ARP is not really mandatory. Other than that, the NDK seems to be behaving correctly with the exception of this issue.

    In regards to the post with the corrupt routing table, the original poster never specifically detailed what he was doing to corrupt the routing table. In my case, other than initially specifying the default gateway, I'm not fiddling with the routing table at all. I have tried manually adding the default gateway with the following code, but did not see any change of behavior:
    NtAddStaticGateway(0, 0, inet_addr(GatewayIP));

    In regards to the post with the localized IP 192.168.1.1, I have tried other IP addresses on both the PC and my device. The behavior is the same regardless of the IP addresses.

    I have run some more test cases with very interesting findings:

    Test case 1) The original test case described in my original post, which I will repeat here: I configured my PC with IP address 192.168.1.1 and subnet mask 255.255.0.0. I configured my device (AM335x using the NDK stack) with IP address 192.168.0.10, subnet mask 255.255.255.0, and default gateway 192.168.0.1 (which does not exist). On the PC, I send a UDP/IP packet to my device. My device receives the packet and sends a UDP/IP packet back to the PC.

    Test case 2) I wrote a simple program on my device to establish a TCP connection with the PC. When my device started up, it did correctly attempt to ARP the default gateway. The default gateway doesn't actually exist, so this failed as expected. So this test case does confirm that if the NDK has no prior knowledge of an IP address, the NDK will send an ARP to try and resolve the associated MAC address.

    Test case 3) I happened to stumble upon this scenario, but I'll try to explain it the best I can. I ran test case 1, and then power-cycled my device and tried running test case 1 again. Here are my observations on the second test run via Wireshark. The PC sends a UDP packet to my device. To my surprise, the device did not send a packet back. Instead, my device correctly sent an ARP to resolve the default gateway. The NDK seems to be behaving correctly now...or so it seems. I take some time to look at the Wireshark capture and after a couple minutes decide to run test case 1 again. This is the third test run and this time my device incorrectly sends a UDP packet back to the PC. I decided to take a closer look at the second and third test runs. In the second test run, the PC did NOT send a (broadcast) ARP to resolve my device's IP address, because the device's IP address and associated MAC address were still valid in the PC's routing table. In the third test run, the PC did send an ARP to resolve my device's IP address. This is most likely due to the fact that I had waited several minutes before running the third test run, so the PC's route for my IP address and associated MAC address may have become invalid or needed to be updated/renewed.

    My best guess according to test case 3, is that the PC's initial ARP request and my device's ARP response is creating a routing path in the NDK stack for the PC's MAC address. Therefore, when my device receives a UDP/IP packet from the PC, the NDK associates the PC's IP address with the PC's MAC address, and believes it can use that same route which was used in the ARP response.

    Can someone at TI comment on my observations?

  • 0
    TI__Mastermind 45025 points
    fyang,

    It looks to me like you are seeing an issue that another team at TI ran into a year or so ago. They ran into this same issue when running a test suite for testing Address Collision Detection (ACD).

    Let me ask, is your PC and device connected to the same physical layer? (e.g. they are configured for different subnets, but they are physically plugged into the same router or switch).

    If so, it's most likely due to the same issue, filed in the following bug:

    SDOCM00107816 (ACD) allow stack to be rebuilt to enable omission of ARP table entries for ARP req's recvd from hosts on different subnets

    Basically, the issue is that the NDK receives an ARP request from the PC, and when it does, it adds an ARP entry for the PC into its ARP table (this is the problem).

    The NDK receives the PC's ARP (even though they are configured to be on different subnets) because the PC and the device are on the same physical layer (ARP requests are broadcast to all hosts on the LAN). It doesn't check that the PC is in a different subnet, but it should (and NOT add an ARP table entry for it in this case).

    I've added a fix for this issue in NDK 2.24, so you can get it in that version (or newer).

    However, there is a catch. As I mentioned, at the time of implementing this bug fix, it was specifically needed for the team adding ACD support, and it wasn't realized that it was a general problem. In result, the fix is not present by default and requires a rebuild of the NDK stack. You must rebuild with the following macro defined in the compiler options:

    -D_INCLUDE_ACD_SUPPORT

    Rebuilding (the new version of) the NDK will enable this fix. You can find a link to a wiki page with instructions on how to rebuild the NDK in the NDK's release notes.

    Steve
  • 0 in reply to Steven Connell
    Intellectual 650 points
    Steve,

    You have identified the issue. I was able to apply the fix for SDOCM00107816 (from NDK V2.24.00.11) to my NDK version and the behavior is correct now. Thanks for all the help.
  • 0 in reply to Steven Connell
    Intellectual 650 points
    Steve,

    As this issue seems to be a general problem, I'm assuming that the fix for SDOCM00107816 will be enabled by default (without having to define -D_INCLUDE_ACD_SUPPORT and recompile the NDK) for the next NDK release?
  • 0 in reply to Felickao Yang
    TI__Mastermind 45025 points

    fyang,

    Yes, there is already an enhancment filed to track this.  It should be fixed in an NDK release in the near future.

    Steve

    SDOCM00112109 ARP table behavior implemented by SDOCM00107816 should be default behavior in NDK