• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 949 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.

RTOS: NDK and TCPIP stack behavior

Guy Mardiks
Genius 4135 points

Tool/software: TI-RTOS

Hello,

I encountered some behavior which does not fit with what i would have expected to see - could it be a bug and/or implementation dependent behavior ?

The scenario is as follows:

Device A: subnet 255.255.255.0 , ip 10.1.0.39 (the NDK stack)

Device B: (linux / windows) subnet 255.255.0.0 , ip: 10.1.1.11

 

Device A sees Device B as on a different subnet but device B think A in on its subnet.

 

B tries to send TCP packet to A (B once talked to A on a different scenario so it already has the MAC) A should receive the packet but should respond through the gateway as it sees the B from different subnet .

There is no gateway configured (nothing exist on the gateway IP) so A should not be able to communicate with B.

After a while, when B gets no response it tries to ARP A – the ARP received and ANSWERD by A (not quite sure why if B is on a different subnet unless ARP does not care and is only Layer 2 ?)

From here on it seems the A can communicate with B – I assume it is because after the ARP A now have an entry the contains B’s IP and MAC association and from some reason it no longer even considers the different subnets. Can you help explain this behavior?

 

Attached is a wireshark log

Thankshttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/5383.host10.1.1.11_2D00_usrr10.1.0.39.pcap.7z

  • 0
    TI__Mastermind 45025 points

    Guy,

    This issue is actually fixed in the version of the NDK you have (2.24x), however, it is not enabled by default.

    In order to enable the fix, you need to rebuild the NDK stack with "-D_INCLUDE_ACD_SUPPORT".

    You can see the fix for this in the code of ti/ndk/stack/lli/lliin.c.  Just search for the preprocessor code that checks for "_INCLUDE_ACD_SUPPORT".  (see NDK docs for more info about how to rebuild with this macro and what else it does).

    Can you try rebuilding with that and see if this resolves your problem?


    There are 2 bug reports related to this:

    1. SDOCM00107816 - (ACD) allow stack to be rebuilt to enable omission of ARP table entries for ARP req's recvd from hosts on different subnets
      1. This was fixed, but the fix was specifically added for Address Collision Detection (ACD) support, and so was surrounded by preprocessor checks (as described above).
    2. NDK-70ARP table behavior implemented by SDOCM00107816 should be default behavior in NDK
      1. This is to remove that preprocessor code.
      2. This is currently planned for the next major NDK release.

    Steve