TMS320C6655: TI NDK How to get destination IP address from UDP packet?

Hi Yeung,

Want to understand what do you mean by Unicast socket getting tripped from global broadcast packet traffic IP? Can you please provide more details?

Thanks

We have 3 sockets for UDP operations.  One bind to the exact device address (192.168.0.X), we call it the Unicast socket.  The second one bind to the direct broadcast address (192.168.0.255), and the third one bind to the global broadcast address (255.255.255.255).  All are on the same port number.  We received unicast packet from the Unicast socket, direct broadcast from the direct broadcast socket, but when there is a global broadcast packet on the wire, all 3 sockets were tripped with the same packet.  So our code made 3 responses to that one global broadcast request and causing problems.  Not sure what is going on as it is definitely not normal or correct, but to workaround it, I was thinking to use the destination address 255.255.255.255 to filter it out.  Any insight?

Hi Yeung,

I am still trying to understand the problem.

1. Why are you having an UDP socket with global BC (255.255.255.255)? What is it used for, if you are looking to drop/filter it out?

2. My understanding on "3 sockets are tripped with the same packet" means all sockets received this global BC packet and your software is responding to this packet. This is not desirable right?

3. By the way, did you add the Global BC entry via "CfgAddEntry()" API?

Thanks for helping me to understand your system/usage/need.

Thanks

- Like I said we are working on supporting EIP protocol.  The protocol says it must allows any UDP request to be sent from client using unicast, direct broadcast or global broadcast.  And it says that depend on how the request is sent (unicast, direct or global bc), different response time must be used in order to become EIP ODVA certified.

- Yes, all 3 sockets received the global bc, and it causes us to process the same packet 3 times and not able to set the response time correctly.

- We tried CFGITEM_IP_DIRECTEDBCAST CfgAddEntry(), and it doesn't seem to do anything different.  Please tell me more about the g bc entry.  I couldn't find any reference on that yet.

Thanks!

Hi Yeung,

What I understand from you is you are looking for limited broadcast right? CFGITEM_IP_DIRECTEDBCAST is for a  packet is sent to a specific destination address where only the host portion of the IP address is either all ones or all zeros (such as 192.20.255.255 or 190.20.0.0)

As per my understanding, UDP sockets receiving the BC packets is as per standard ..

I am discussing this internally and get back to you.

Thanks,

Hi Yeung,

I don't find any APIs to get the destination IP of the UDP packet - I wonder you may need to read the packet 

By the way, I would like to understand your approach:

"I was thinking to use the destination address 255.255.255.255 to filter it out.  Any insight"

If you filter out the global broadcast, then none of the sockets would receive it right? is that you want to achieve? 

How do I read the destination address from the packet? after the socket tripped for read, without touching code in NDK.

That is correct.  If I can read the destination address when my "unicast" socket pops, I can drop the one that has global bc IP 255.255.255.255.  Though It cannot just block all global socket in the NDK layer, I still need global bc to continue to work for my other global bc socket that actually bind to 255.255.255.255.

Yeung,

Are you opening unicast socket with SO_BROADCAST flag?

Looks like the SO_BROADCAST socket flag may help.

As per description:

“Datagrams to broadcast addresses can be only sent or received when the SO_BROADCAST socket flag is set.”

Probably just removing the flag may help.

Let me know.

If this is not enough for you, I still need to check with local NDK experts if this is possible and feasible and get back to you..

Please expect delay on this for next response.

Hi Yeung,

Not heard back from you on this. Note that the thread get locked after a month or so, if you have no response. I just unlocked it again. Please close the thread if there is nothing else to discuss. 

I will close the thread in couple of days, if there is no further question.

Thanks

Sorry, I didn't get an email from your last reply. SO_BROADCAST has to be left on as they are all UDP broadcast. Especially, the problem was that Direct Broadcast and Global Broadcast sockets needed to be distinguishable. We gave up and brute force found a way to work around it, and it is quite inefficient. Looks like it's a flaw in the NDK stack.

Hi Yeung,

Thanks for the inputs. Please close the thread if there is nothing further. As on today, there is no further plans on revising the NDK/update the design on NDK.

Thanks

Thanks for taking the time anyhow.   Since the issue was not resolved technically, I shouldn't check "This resolved my issue" to confuse anyone.  So I don't have a way to close the thread, you may close it on your side.