NDK 2.22 doesn't respond to ping over IPv6

Hi Masayuki,

It could be a couple of things.  First, just to be sure, I want to make sure you have done the set up correctly ...

In order to use IPv6 in the client example, it must be turned on at run time.  There are a couple of ways to do this, but the easiest is to telnet into the client application.  Once in, you can issue a series of IPv6 (as well as IPv4) commands.

To enable IPv6 on interface eth0, type the following command:

>ipv6 init eth0

After that, the IPv6 address can be viewed by using the route command

>ipv6 route

>ipv6 route
-------------------------------------------------
Interface Name   : eth0
Network  Address : fe80::
Next Hop Address : ::
Route Type       : CLONING
Timeout          : Infinite
-------------------------------------------------
Interface Name   : eth0
Network  Address : fe80::212:abff:fe21:479
Next Hop Address : fe80::212:abff:fe21:479
Route Type       : LOCAL
Timeout          : Infinite
-------------------------------------------------
Interface Name   : eth0
Network  Address : ::1
Next Hop Address : ::1
Route Type       : LOCAL
Timeout          : Infinite
-------------------------------------------------

Next, to ping on Windows, you must use the correct interface identifier.  This will be a "%#" tacked onto the end of your Windows 7 IPv6 address, seen by running the ipconfig command.  On my machine, it's "%10", and you must use this when pinging another IPv6 host on the network.

For example, on my Win 7 machine:

>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : am.dhcp.ti.com
   Link-local IPv6 Address . . . . . : fe80::f907:2891:41c5:1e74%10
   IPv4 Address. . . . . . . . . . . : 146.252.161.36
   Subnet Mask . . . . . . . . . . . : 255.255.254.0
   Default Gateway . . . . . . . . . : 146.252.160.1

Now I can ping another host with IPv6 address "fe80::216:3eff:fe01:202" as follows (note the interface ID is appended to the address):

>ping  fe80::216:3eff:fe01:202%10

Pinging fe80::216:3eff:fe01:202%10 with 32 bytes of data:
Reply from fe80::216:3eff:fe01:202%10: time=1ms
Reply from fe80::216:3eff:fe01:202%10: time<1ms

Ping statistics for fe80::216:3eff:fe01:202%10:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
Control-C
^C

Steve

Hi Steve,

Thank you for your reply.

There is no problem about initializing interface eth0, and I tried pinging with inteface ID , but had no reply from DSP.

Proving packets with Wireshark, It seems DSP doesn't reply to ICMPv6 neighbor solicitation.

I found following issue in NDK 2.22.02.16 release notes. Does that refer to the problem that I have? (I have no idea about what "Freon" is.)

Known Bugs:
SDOCM00098789 - NDK doesn't respond to Neighbor Solicitation messages on Freon

Masayuki

Hi Masayuki,

Unfortunately the bug you have listed above is the problem you are seeing.  "Freon" is the evmOMAPL138.

I've been testing this some more and I see that this problem doesn't happen on the ARM9.  I can't recall, but if you have an ARM 9 on your board you could try that.

Note that you can work around this issue right now as follows (excerpt from the bug report):

"What's interesting is that if one telnets into the NDK, then runs an IPv6 ping from the NDK to the Linux or Windows host, the NDK will get a response.  (this is due to the Linux/Windows host *not* having such a problem receiving NS messages).

Once the Linux/Win host responds to the NDK's NS message (with a NA), it updates its neighbor table and can then "see" the other hosts.

After this, it is possible to ping6 from Linux/Windows host to the NDK."

Steve

Hi Steve,

I could get a response, once ping is sent from DSP. But it seems difficult to apply that to my practical case.

I don't have ARM9 on my board, so I have to wait for the bug fix.

Thank you for your reply.

Masayuki

Hi Steve,

It worked. I could receive responses from DSP.

I modified 'ethdriver.c' (not 'ethernet.c') as above, and rebuilded the driver according to NSP release notes.

Thank you so much.

Masayuki

Masayuki,

The fix for the problem you encountered has been made in the latest update to the OMAPL138 NSP product.  You can find the release here:

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

Steve