Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 43 subscribers
  • Views 1426 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.

CC3000 combines data from multiple UDP packets that have different source ports!

Valkyrie-MT
Expert 1050 points
Other Parts Discussed in Thread: CC3200, CC3100

I am trying to implement LLMNR support using UDP.  I open the socket, then I bind to the Multicast IP and port.  But when the 0x84 HCI_DATA_RECVFROM event fires, I am getting two packets from the same source IP, but different source ports combined together into a single 0x84 event.  Since I don't have the source port for one of the packets, I cannot respond to it.  Also, there is no way to know how to split these two messages since there is no start position or size value to indicate where the start of the second packet is. 

Here is an image illustrating the problem.  Notice there is no way to know the source port 61501.  Packets with different source ports should have separate HCI_DATA_RECVFROM events! 

 

Perhaps, the cc3000 combines these packets together because the bound port is the same for both packets in the case of Multicast UDP.  If so, that is a big mistake because packets can and do come from a variety of different clients in a multicast group.  These messages must remain separate. 

I have tried to work around this by reducing the RECV size, but that did not work at all. 

 

  • 0
    TI__Mastermind 27490 points

    Hi there,

    Please see last item on errata: http://www.ti.com/litv/pdf/swrz044b

    Regards,

    Aaron

  • 0 in reply to made4engineering
    Expert 1050 points

    Issue 2.13 -- UDP packets are not received one-by-one by the host

    Is categorized as severity = LOW. 

    I strongly disagree with this assessment.  If there was a workaround, certainly, but the comment listed as a workaround is not reasonable.  How in the world do you think the host could ever possibly know the size of an incoming UDP packet before it is received?  Assuming that I can't know the packet length ahead of time, now I have NO CLUE what the address and port of the packets are after the first packet!  Ridiculous.  I just had my UDP server hit this bug when two devices (from different IPs) had their packets combined.  When this happens there is NO WAY to know what the Remote IP is of my packets (other than the first packet).  The only workaround is to just ignore all packets after the first, but that would have the net effect of forcing you to drop half or more of the UDP packets!  It's possible that polling more frequently would reduce the number of packets combined in one, but I am already polling VERY frequently. 

    Not having the remote IP address of the Packets is a HIGH severity bug.  If we don't have the address of the packet, it cannot be replied to!  I cannot comprehend how anyone would ever categorize this as anything other than an absolutely CRITICAL flaw.  Until this is fixed in the firmware, there is no way to use UDP without dropping most of the packets because you don't know the remote IP.  That means UDP is broken.   

    This has been a known issue for over 4 months now, so I hope there is a fix imminent. 

  • 0 in reply to Valkyrie-MT
    TI__Mastermind 27490 points

    Hi Valkyrie,

    It is as you say - this is a significant issue. However, for most applications I believe it is not a game ender. First of all, knowing the packet size in advance is easy if it is a fixed number that is agreed upon by both server and client. Alternatively, senders of the packets could encapulate the length of their messages along with their own address at the beginning of the payload. The recipient would then be able to divide the stream accordingly. This requires a little extra effort, but as long as you have control over the packet content on both ends of communication it should be workable.

    Regards,

    Aaron

  • 0 in reply to made4engineering
    Expert 1050 points

    Hi Aaron. 

    For my application, to maximize stability, I switched from TCP to UDP a few months ago, abandoning my REST web server approach.  Then, I switched to fixed message sizes because of this issue.  Ultimately, this ended up performing much better for me, so it has some advantages.  You are absolutely correct, that using fixed message size works... for me.  However, this will not work if someone is communicating with any third-party service or any other service that cannot be altered to have a fixed size.  Such as LLMNR or MDNS or other core network communication services, which have variable lengths.  Since the cc3000 strips out the UDP header, I can't know how many bytes to read.  The cc3000 must tokenize the packets if you are going to remove the UDP header.  Also, I am not entirely convinced that the IP information is correct for other packets read from the buffer.  My concern is that only the first or last UDP packet information is used for all packets from the buffer.  I have no way of knowing if that's true, but my gut says that is a possibility given the current UDP issue. 

    Ultimately, though, I am not pushing for a fix for myself.  I am pushing to make the cc3000 work better for everyone and possibly for myself in a future project.  Also, the cc3000 library I developed (cc3000.codeplex.com) cannot expose a general purpose UDP socket that assumes a fixed size.  That would be very limiting. 

  • 0 in reply to Valkyrie-MT
    Intellectual 635 points

    Could someone from TI please confirm if this issue is fixed in the CC31XX and CC32XX stacks?

  • 0
    Prodigy 30 points

    Can TI representatives please update if this issue is Fixed for CC3200?

  • 0 in reply to Sachin Agrawal
    TI__Mastermind 27490 points
    Yes this is fixed for CC3200/CC3100

    -Aaron