UDP won't read

[altenbach]

Unfortunately, we cannot see the values for "local port" and "remote port". Why don't you attach the VI instead? (or temporarily change them to constants before taking the image).

Does it work if you run both on the local computer?

How are your firewall settings?

[Isereau]

Local port is 6311 and remote port is 80.  The data is getting sent and there is a return (noted by wireshark) but its not getting "grabbed" by Labview.  I run the receive vi then send vi...this is a sort of test just test communication.  I was using the winpcap driver with labview to get the data but company policy eliminates that possiblity...

[smercurio_fc]

The UDP Write should be writing to the port that the receiving end is listening to. If you say that "Local Port" is 6311 then based on your picture, that's the value that should be wired to UDP Write, not 80. That's how it's coded in the UDP Receiver and UDP Sender examples that ship with LabVIEW.

[altenbach]

The local port should probably be 80, that's where you want to listen. Currently you are listening on 6311 while you send to port 80 from port 80 (it is OK to have local and remote ports the same).

What you call "remote ports" is actually just port (I would NEVER rename things!). It is the local port used for the outgoing connection by the client.

The client sends from "remote port 80" (= source port in the packet) (your nomenclature) to port 80 (dest port in hte packet).

The server listens for packets with a destination port of 6311. No communication will result!

[Isereau]

I'm sorry the computer I have the VI's on is in the lab and not connected to the internet (so I made these ones up at my desk real quick, a little sloppy with nomenclature).  I went to check and this is how it is:

[altenbach]

Yes, this should work.

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

The source port for the outgong connection (6311) is irrelevant, because the connection is on-way, so for full flexibility, you should set it to zero. In this case, the computer will select a free ephemeral port for you. If it is hardwired as in your case, there is a nonzero chance are that the port is in use by something else and the program will fail.

(Even if the communication were two-way, I would leave it at zero, because the server can read the source port and thus determine where to send the return packets.)

[Isereau]

I tested it again but still no luck, I have the firewall turned off and I tried a test on the computer (which worked) any other suggestions?

[altenbach]

---

Isereau wrote:
...any other suggestions?

---

Yes, set all current controls of your VI to defaults, save the two VIs, and attach them here. It is much easier for us if we can actually test it live.

(You don' bring a picture of your car to a mechanic and expect him to figure out what's wrong. (Unless e.g. the wheels are missing). :D)

[Isereau]

Thanks for the help here are the Vi's:

[altenbach]

You are STILL not listening on port 80 as instructed! Chance this to 80 and all's well. 😄

Message Edited by altenbach on 06-24-2008 12:50 PM