• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 101 subscribers
  • Views 2508 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.

IPv6 multicast

viethoang
Prodigy 230 points

Hi all,

Has any one tried to use IPv6 multicast with NDK?

        I am developing a network application on TM4C129X Development Board ( and a custom board based on that board). I am using tirtos_1_20_00_28, ndk_2_23_00_00 and CCS 5.5.0.00077

        I am trying to send 18-byte UDP packets from one board (Sender) to multicast address "ff02::1". I make  another board (Receiver) join that "ff02::1" multicast group using setsockopt() with IPV6_JOIN_GROUP. On Receiver side, calling recvfrom( lSocket, buffer, TCPPACKETSIZE, MSG_WAITALL, (struct sockaddr *)&remote_addr, &addrlen) returns 26 (!!!), with 8 zero bytes appended the real data sent by Sender. Another problem is that remote_addr.sin6_addr and remote_addr.sin6_port are set to 0 (!!!).

        Then I try to send those 18-byte UDP packets from Sender to Receiver directly using Receiver's IPv6 address (e.g "fe80::aa11:22ff:fe33:4466"), recvfrom() now returns 18 and remote_addr.sin6_addr, remote_addr.sin6_port are set correctly.

        In function IPv6RxPacket() in file tirtos_1_20_00_28\products\ndk_2_23_00_00\packages\ti\ndk\stack\ipv6\ipv6in.c, in multicast sending case, I still see that srcAddr is Sender's IPv6 address and dstAddr is "ff02::1". In case I use Receiver's address (instead of multicast address), the destAddr is Receiver's address.

        I am still trying to trace the function call in NDK stack, but I'd like to know if you met this problem of IPv6 multicast before? Is this a known problem?

Thanks all,

Viet Hoang.

  • 0 in reply to judahvang
    Prodigy 230 points

    judahvang said:

    Does this link provide any useful information?

    http://processors.wiki.ti.com/index.php/IPv6_Support

     

    Thank you for your reply, judahvang. But that link does not provide specific information, except "Basic Socket Interface Extensions for IPv6 - Implemented partially. No compatibility with IPv4 nodes, multicast, getaddrinfo/freeaddrinfo". Do you have a clearer information about multicast case?

    Thanks,

    Viet Hoang.

  • 0
    TI__Mastermind 45025 points

    Hi Viet Hoang,

    I'm wondering why you are trying to join the group "ff02::1"?

    This is a special multicast address for the "link local all nodes multicast address/group" which all IPv6 hosts are required to join.

    When you initialize the IPv6 stack in TI-RTOS, this group is joined automatically.

    Can you try a different multicast group?  For example, try joining something like "ff02::123".  Are you able to receive data in that group?

    Steve

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Hi Steve,

    No, Receiver does not join that "ff02::1" multicast group automatically. Without calling setsockopt(lSocket, IPPROTO_IPV6, IPV6_JOIN_GROUP, (char*) &multicastRequest, sizeof(multicastRequest)), Receiver cannot receive data from Sender, I tested.

    I tried with other addresses as you suggested, same result as with "ff02::1".

    I also tried to send UDP multicast packets from my Linux PC to NDK board and got same result.

    How about this information "No compatibility with IPv4 nodes, multicast, getaddrinfo/freeaddrinfo"?

    Thanks,

    Viet Hoang.

  • 0 in reply to viethoang
    TI__Mastermind 45025 points

    How are you initializing the IPv6 stack?

    Are you basing your app on one of the TIRTOS examples?

    It may be helpful to attach your source code, in particular the code that sets up your sockets and initializes the NDK and NDK's IPv6 stack.  If you cannot post publicly, we can become friends on the forum and then you can email it directly to me (which will be private).

    Steve

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Hi Steve,

    Yes, I added a multicast task ( udpMultiCastHandler()) to tcpEchoIPv6_TivaTM4C129XNCZAD project and changed netOpenHook() funtion to call that task.

    Please find attached source code. This is just for testing multicast.

    Thanks,

    Viet Hoang.

    tcpEchoIPv6_TivaTM4C129XNCZAD.zip
  • 0 in reply to viethoang
    TI__Mastermind 45025 points

    Viet Hoang,

    Can you try the attached example?  This is a multicast example that we have not released yet (but plan to soon).  I was able to run it on another h/w platform (stellaris B96 board) but the code should work for your Tiva board, too.

    Steve

    2577.mcUDPIPv6_example.zip

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Hi Steve,

    I am trying your code. I don't change any thing, so I just talk about the data received in mcRecvTaskFxn(). My multicast sender sends string "Hello" (length = 5) to TI-NDK board, and System_printf("recv: %d %s\n", n, data); in mcRecvTaskFxn() prints this:

    recv: 13 HelloÙ6)ÑX6)Ñ
    recv: 13 HelloÙ6)ÑX6)Ñ
    recv: 13 HelloÙ6)ÑX6)Ñ
    recv: 13 HelloÙ6)ÑX6)Ñ
    recv: 13 HelloÙ6)ÑX6)Ñ

    ........

    So, received data is 13 bytes long (8 bytes are added at the end of real data).

    I think you are misunderstanding my question. My udpMultiCastHandler() does work, it receives data; But with wrong length, and cannot get the source address information (Sender's address).

    Thanks,

    Viet Hoang.

  • 0 in reply to viethoang
    TI__Mastermind 45025 points

    Viet Hoang,

    Indeed I did misunderstand your problem, thanks for clarifying.  I am trying to reproduce the issue you are seeing now, however I'm having some trouble with my Linux machine (needed to run the Python app), but I will get back to you as soon as I can once I'm past that.

    Steve

  • 0 in reply to Steven Connell
    TI__Mastermind 45025 points

    Viet Hoang,

    I've been debugging this issue today.  I was able to reproduce it (changed Python script to not write '\0' char to "hello" string it sends to target) and believe I've found the root cause and solution.

    I see that in the function which processes multicast messages for UDP is writing (UDP header size + UDP payload size) to the socket buffer.  This explains the extra 8 bytes of garbage characters that come out (since sizeof(UDP header) == 8).

    the following code in udp6.c (Udp6Input fxn):

        if (IPv6IsMulticast(dstAddr)) {

            processMulticast(pPkt, srcAddr, ptr_udpHdr->SrcPort,
                            dstAddr, ptr_udpHdr->DstPort, PayloadLength);

            return;
        }

    In the above, PayloadLength is the size of the *entire* UDP packet, including the 8 byte header.  But, processMulticast() assumes that it is given a size that corresponds to only the UDP payload (without the header).

    The argument value should be changed to subtract the 8 byte header:

            processMulticast(pPkt, srcAddr, ptr_udpHdr->SrcPort,
                            dstAddr, ptr_udpHdr->DstPort, PayloadLength - UDPHDR_SIZE);


    I tried this and got the correct output.

    I've filed a bug to track this issue:

        SDOCM00106585 - UDPv6 multicast copies too much data into socket buffer (extra 8 bytes == size of UDP header)

    In the mean time, if you wanted this change, you would unfortunately have to apply it yourself to your installed NDK and then rebuild the NDK (it's recommended to make a copy of the originally installed NDK, modify that and then rebuild the copy).  Please refer to the NDK release notes for steps on how to rebuild the NDK.

    Steve

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Hi Steve,

        Thank you very much.

    I also traced NDK stack code, and reached that part of code (By adding System_printf() and rebuilding NDK). I doubted that that code branch ( if (IPv6IsMulticast(dstAddr))) causes the issue, but did not have enough time to dive into that processMulticast() function.

    So, one of two issues I said is solved. I think the 2nd issue is also caused by that function.

    Could you also file a bug on this issue "cannot get the source address information (Sender's address)"?

    Thanks,

    Viet Hoang.

  • 0 in reply to viethoang
    TI__Mastermind 45025 points

    No problem, we will definitely look at this, too.

    SDOCM00106630  UDPv6 multicast: cannot get the source address information (Sender's address)

    Steve

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Steve,

    Thank you very much for your help.

    Viet Hoang.

  • 0 in reply to viethoang
    TI__Mastermind 45025 points

    Hi Viet Hoang,

    I just wanted to update you on the status of these two bugs - they have been fixed in the latest NDK release (NDK 2.24).  You can download NDK 2.24 here.

    Steve

  • 0 in reply to Steven Connell
    Prodigy 230 points

    Hi Steve,

    Thank you very much for informing me this. We will update our projects using this new NDK release.

    Viet Hoang.