UDP won't read

[Isereau]

This is what I was doing:

"You can easily test by running client and server on the same PC, no internet connection required."

so the placement of the values were set up to do that. maybe changed as I was fiddling with it.  Here are the versions that don't work. 

[smercurio_fc]

Well, it's certainly not going to work with an IP address of "IPADDRESS".

If you change that to "localhost" then it works. Is the target machine on the same subnet?

[altenbach]

---

Isereau wrote:
Here are the versions that don't work. 

---

The only problem is the malformed IP address. Once you change the string going to "string-to-IP" from "IPADDRESS" to an empty string, things work just fine locally.

What do you enter here when you are trying to contact the remote server?

[Isereau]

I just enter that ip address corresponding to the other end of the form :

111.111.111.11

of course this is not the real address...but it takes that form.

[altenbach]

Obviously, you don't have an address or routing problem, because you say you can see the packets arrive using wireshark.

(I assume you are using wireshark in the recevier side, else it would make little sense for troubleshooting.)

Are you saying you can get it to work locally? Is this correct?

Can you show me a packet capture from wireshark, showing a relevant packet arriving?

[Isereau]

Yes, it works locally.  I can't show you what wireshark shows due to proprietary information, but it definately shows the correct information is coming back.  One thing I noticed when I was watching wireshark is the port which the data is coming in from is labeled HTTP (80) whereas the other port is just labeled 6311 (6311).  Don't know if this could be a problem or not...

[smercurio_fc]

Wireshark is simply automatically labeling that as HTTP since it's a well-defined port, as shown in the Wikipedia entry I had shown you before. What does Wireshark show as the source and destination port at the receiving end? Have you verified that the destination port at the receiving end matches the port that the LabVIEW UDP Read program is listening to? Have you verified that you have no other processes listening on that port?

[Isereau]

I checked and rechecked the ports and ip's in wireshark and in the VI's they are all good.  I also changed ports #'s and still got the same result. 

[altenbach]

---

smercurio_fc wrote:
Have you verified that you have no other processes listening on that port?

---

That should give an error immediately.

You might want to make sure to insert an error indicator right after the UDP operation

Notice also that the NI example has the error cluster in a shift register, while you have it wired across regular tunnels. Your version can mask errors.

---

Isereau wrote:
Yes, it works locally.  I can't show you what wireshark shows due to proprietary information, but it definately shows the correct information is coming back.  One thing I noticed when I was watching wireshark is the port which the data is coming in from is labeled HTTP (80) whereas the other port is just labeled 6311 (6311).  Don't know if this could be a problem or not...

---

There cannot be much properitary information in an UDP header. Can you at least show us a screenshot of wireshark displaying one packet. You can bleep out the information that is proprietary, e.g. the packet payload.

From the IP header, we want: (1) source IP, (2) destination IP, (3) protocol.

From the UDP header, we want: (4) source port, (5) destination port.

If you say "port which the data is coming in from is labeled HTTP (80)  whereas the other port is just labeled 6311 (6311).", I would interpret that as

Source port=80, Destination port=6311

Which is still incorrect. The source port is irrelevant and the destination port MUST be 80. The problem is that you lingo is ambiguous because it uses non-standard terms.

Also, if you say "shows the correct information is coming back", it looks like you are talking about return traffic. UDP is stateless, and from what I understand one-way in this case. Very confusing!

Message Edited by altenbach on 06-25-2008 08:05 AM

[Isereau]

Here are the latest version I have with the wireshark shot and it still doesn't work...