UDP Read does not receive data

[Aero-DAS]

I am using LV2016 to send and receive UDP data to an embedded controller (TI Delfino DSC).  I am able to receive the UDP data from LV on the DSC.  The UDP Read times out without receiving any data.  I am using modified versions of the Simple UDP example.  I added the IP address of the USB network adapter that I am using to both UDP Opens, and adjusted port numbers. I have disabled the Firewall, and virus checker.  I am using PC Write Port 1121, PC Read Port 1122, DSC Write Port 1124, DSC Read Port 1123.

I am running Wireshark to monitor the data packets.  Both Send & Receive data packets look good on Wireshark.

UDP Write Datagram viewed on Wireshark:

Frame 5: 50 bytes on wire (400 bits), 50 bytes captured (400 bits) on interface 0

Ethernet II, Src: Siig_60:40:7d (00:00:ba:60:40:7d), Dst: 06:e5:96:c0:1e:00 (06:e5:96:c0:1e:00)

Internet Protocol Version 4, Src: 10.10.10.1, Dst: 10.10.10.2

User Datagram Protocol, Src Port: 1121, Dst Port: 1123

    Source Port: 1121

    Destination Port: 1123

    Length: 16

    Checksum: 0x2838 [unverified]

    [Checksum Status: Unverified]

    [Stream index: 1]

Data (8 bytes)

    Data: 5231323334353640

    [Length: 8]

UDP Read Datagram viewed on Wireshark:

Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: 06:e5:96:c0:1e:00 (06:e5:96:c0:1e:00), Dst: Siig_60:40:7d (00:00:ba:60:40:7d)
Internet Protocol Version 4, Src: 10.10.10.2, Dst: 10.10.10.1
User Datagram Protocol, Src Port: 1124, Dst Port: 1122
Source Port: 1124
Destination Port: 1122
Length: 16
[Checksum: [missing]]
[Checksum Status: Not present]
[Stream index: 2]
Data (8 bytes)
Data: 3132333435363738
[Length: 8]

The UDP Read Datagram shows Checksum as missing, but I have read on this Forum that UDP works with Checksum of 0000.

I have 10 bytes of padding on the datagram sent from the DSC.  I have tried adjusting the IP header length, did not work.

I have run netstat -an and I see my ports: 

UDP 10.10.10.1:1121 *:*
UDP 10.10.10.1:1122 *:*

[altenbach]

---

@Aero-DAS wrote:

I am using PC Write Port 1121, PC Read Port 1122, DSC Write Port 1124, DSC Read Port 1123. 

---

I am a bit confused with all the numbers and sides, but the write port needs to match the read port on the other end and vice versa. If the DSC writes to port 1124 and nothing is listening on that port on the PC, nothing interesting will happen.

[Aero-DAS]

PC                              DSC

10.10.10.1                 10.10.10.2

Write – 1121              Read – 1123

Read – 1122             Write – 1124

PC writes to port 1121 and DSC reads on port 1123.  DSC writes to port 1124 and PC reads on port 1122.  I assume this is how you setup two-way UDP communication.  Each device has two ports, one for write and one for read.  Unfortunately NI does not have an example showing two-way UDP.  I did find a previous post where someone setup two-way UDP.  They used 'Local Socket Port' of 61556, 'Local Receive Port' of 61561, and 'Remote port to write to' of 61557.  Basically it just combined the Simple UDP - Sender and Simple UDP - Receiver into one VI with two while loops.  Each local port has it's own UDP Open (& UDP Close).

Since Wireshark is reporting a successful UDP receive, I am guessing that the problem is in Windows accepting the packet.  I have read on similar posts of UDP receive problems where the problem was with IP header length, and the firewall blocking ports even with firewall disabled (IT setup).

---

[altenbach]

If a device receives a UDP packet to a port where no service is listening, it gets discarded. Wireshark will still see it. You need to write to a port where the other side is actually listening.

Can you tell us a little bit more about the two devices? Who wrote the code running on the DSC? (I assume this is not LabVIEW). How exactly are you configuring the communication ports?

UDP is a connection-less protocol, meaning that the packet it simply sent out and there is no built-in mechanism (as with TCP) to ensure transmission (three way handshake, ACK packets, etc.).

Are you trying to do two-way communication or two unrelated on-way communications, one in each direction?

For a client-server type two-way communication via UDP, only the server needs to listen on a port known to the client. The client will send a packet to that IP/port using an ephemeral source port (Doesn't matter what it is, so let the OS pick an unused local port!) and the server will (if properly programmed) respond to whatever the source IP/port of the incoming request is. This makes it very convenient because the same server can respond to many different clients at different times. It could be very asymmetric, e.g. the client could send a single very small packet ("start sending me data!") and he server will stream forever.

[Aero-DAS]

The PC is a Windows 10 Pro, Intel i7 cpu.  The Ethernet controller is a SIIG USB Ethernet adapter.

The DSC can read the UDP packets from the PC, no problem.

The DSC embedded controller (TI Delfino) is programmed in C code using TI Code Composer Studio.  I wrote the C code.  When the DSC first boots up it sends an ARP reply to the PCs ARP request.  The PC then starts sending UDP commands.  When the DSC receives a certain command it will send a reply (UDP data).  The PC would be the server and the DSC the client.  The client performs internal tasks based on the command received.  One particular command causes the DSC to respond back to the PC with a data packet.

It appears that the PC is not listening, or Windows is filtering out the received UDP packet.

[altenbach]

Still makes no sense what you are doing. ARP is a natural part of TCP/IP (to define relationships between IP and MAC addresses), so it should be part of the stack. Nothing that should be of concern here.

If your LabVIEW program is not listenig on whatever the destination port of the incoming packet (1124?) is, you won't see it.

---

@Aero-DAS wrote:

 When the DSC receives a certain command it will send a reply (UDP data).  The PC would be the server and the DSC the client. 

---

No, the PC is the client, because it requests data from the server. The DSC is "serving" data that the "client" requests. (of course there are exceptions such as SYSLOG servers, which just passively receive data from all clients and never serve anything back)

[pincpanter]

This thread, although reporting a different problem suggests that maybe IPv6 or another Win 10 gadget could interfere with UDP communications.

The poster says that he got the program working resetting the network card (and possibly disabling the IPv6), but only for a while.

Just a remark: you don't really need two couples of sockets, because the UDP sockets are bidirectional. A single socket for each tier would simplify the code, in my opinion.

[altenbach]

---

@pincpanter wrote:

This thread, 

---

This was about multicast. I don't think anybody reported problems with UDP unicast.

[pincpanter]

Yes, of course. I said it was another problem. However, to try that pseudo-solution only costs a couple of minutes.

Today, computer systems are so complicated and problems can be dependent on a specific machine. Sometimes a (not fully senseless) shot in the dark can help. I learned this by experience.

[Aero-DAS]

The stack is code that I have modified to work with my hardware. I am using a custom built board with a TI F28377D DSC and a Microchip LAN9218i Ethernet Controller.

I mentioned the ARP because it shows up in Wireshark.  The PC (LabVIEW?) will keep sending the ARP request, and not send UDP, until it gets a reply.  The PC is getting the ARP reply from the DSC and responds by sending UDP packets.

I will check out the post you referenced.

How can I verify that the PC is setup to listen on port 1122?  I have ran netstat -an (in cmd window) and I see my ports listed as:

UDP 10.10.10.1:1121 *:*
UDP 10.10.10.1:1122 *:*

Does this indicate that the port is setup correctly?  Is there more that I can do to verify the port is 'Listening'?