UDP won't read

[Isereau]

I need to read udp data and I know its getting to the card ( I used wireshark to see it) but I need to get it into LabVIEW without using a "packet sniffer".  The UDP read just doesn't seem to work...any suggestions?
 
-D

[Isereau]

^^^

[smercurio_fc]

Were you trying to add more information, or was that an attempt to "bump" the thread? Please give time for people to respond to your thread. Most of the folks here are volunteering their time, and many (like me) have full-time jobs. With respect to your question: Please be more explicit. What doesn't work? Are you getting an error? Or, are you getting no data? Same port? Can you post your code, or a screenshot?

[Isereau]

<a href="message?board.id=170&amp;message.id=334242" class="titlebar_text" onmouseover="self.status= Up One Level ;return true;" target="_blank">**smercurio_fc</a>.... -Yes I was bumping the thread, I was in a pinch and thought someone might have a quick answer considering most people who use the forum&nbsp; look at the first page.&nbsp; I appreciate the help but there is no need to be defensive, we are all here for the same reason.&nbsp; And if you work in the same industry I am in then you probably realize sometimes you need a problem solved as efficiently as possible.As for the question intended, the the data is not getting recieved by labview (it is sent fine). &nbsp; I noticed there is the timeout error but I eliminated that.&nbsp; It almost seems like a timing issue, although I am an electrical engineer, not a computer engineer, so I don't have a good grasp on networking. Thanks for the help,-Dustin

[altenbach]

UDP read works perfectly, so you are doing something wrong.
&nbsp;
Have a look at the shipping example "UDP receiver.vi" for correct code.
&nbsp;
If you cannot figure out the problem, attach your VI and we will have a look. :)

[smercurio_fc]

I wasn't being defensive, and it's irrelevant what industry I'm in. I was merely pointing out that you can't always get "immediate" answers on public forums. Sometimes too many people who post on these boards assume there's somebody at the other end ready to pounce on the keyboard when a new question comes in. If you find yourself needing immediate assistance, then your best bet is to contact NI support directly. :smileywink:With respect to your question: Have you looked at the examples that ship with LabVIEW? If you post your code there more specific help may be provided.

[Isereau]

I am reading from port 80, could this be a problem because its the HTTP port?

[altenbach]

Isereau wrote:
I am reading from port 80, could this be a problem because its the HTTP port?


No, this is no problem. Any port that is not already in use as a server port if free to be used.

[smercurio_fc]

HTTP should be using TCP, not UDP. Regardless, any particular reason why you're using 80, when there are so many <a href="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers" target="_blank">private ports</a> available?

[Isereau]

It's still not working, Here's a screen shot of my two VI's:


UDP PIC.JPG:
http://forums.ni.com/attachments/ni/170/334530/1/UDP PIC.JPG

[altenbach]

Unfortunately, we cannot see the values for "local port" and "remote port". Why don't you attach the VI instead? (or temporarily&nbsp;change them to constants before taking the image).
&nbsp;
Does it work if you run both on the local computer?
&nbsp;
How are your firewall settings?

[Isereau]

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

[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).
&nbsp;
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.
&nbsp;
The client sends from "remote port 80" (= source port in the packet) (your nomenclature) to port 80 (dest port in hte packet).
&nbsp;
The server listens for packets with a destination port of 6311. No communication will result!

[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.

[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&nbsp;ones up at my desk real quick, a little sloppy with nomenclature).&nbsp; I went to check and this is how it is:


UDP PIC.JPG:
http://forums.ni.com/attachments/ni/170/334553/1/UDP PIC.JPG

[altenbach]

Yes, this should work.
&nbsp;
You can easily test by running client and server on the same PC, no internet connection required.
&nbsp;
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&nbsp;and the program will fail.
(Even if the communication&nbsp;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,&nbsp;and attach them here. It is much easier for us if we can actually test it live.
&nbsp;
(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:


receiveudp.vi:
http://forums.ni.com/attachments/ni/170/334594/1/receiveudp.vi


sendudp.vi:
http://forums.ni.com/attachments/ni/170/334594/2/sendudp.vi

[altenbach]

You are STILL not listening on port 80 as instructed! Chance this to 80 and all's well. :D
<img src="Loading Image..."> Message Edited by altenbach on 06-24-2008 12:50 PM


port80.png:
http://forums.ni.com/attachments/ni/170/334596/1/port80.png

[Isereau]

This is what I was doing:
"You can easily test by running client and server on the same PC, no internet connection required."
&nbsp;
so the placement of the values were set up to do that. maybe changed as I was fiddling with it.&nbsp; Here are the versions that&nbsp;don't work.&nbsp;


receiveudp.vi:
http://forums.ni.com/attachments/ni/170/334603/1/receiveudp.vi


sendudp.vi:
http://forums.ni.com/attachments/ni/170/334603/2/sendudp.vi

[altenbach]

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


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.
&nbsp;
What do you enter here&nbsp;when you are trying to contact the remote server?

[Isereau]

I just enter that ip address corresponding to the other end&nbsp;of the form :
&nbsp;
111.111.111.11
&nbsp;
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.
&nbsp;
(I assume you are using wireshark in the recevier side, else it would make little sense for troubleshooting.)
&nbsp;
Are you saying you can get it to work locally? Is this correct?
&nbsp;
Can you show me a packet capture from wireshark, showing a relevant packet arriving?

[Isereau]

Yes, it works locally.&nbsp; I can't show you what wireshark shows due to proprietary information, but it definately shows the correct information is coming back.&nbsp; 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).&nbsp; Don't know if this could be a problem or not...

[smercurio_fc]

Well, it's certainly not going to work with an IP address of "IPADDRESS". :smileysurprised: If you change that to "localhost" then it works. Is the target machine on the same subnet?

[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.&nbsp; I also changed ports #'s and still got the same result.&nbsp;

[altenbach]

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


That should give an error immediately.
&nbsp;
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.
&nbsp;





Isereau wrote:
Yes, it works locally.&nbsp; I can't show you what wireshark shows due to proprietary information, but it definately shows the correct information is coming back.&nbsp; 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).&nbsp; 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.
&nbsp;
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.
&nbsp;
If you say "port which the data is coming in from is labeled HTTP (80)&nbsp; whereas the other port is just labeled 6311 (6311).", I would interpret that as
&nbsp;
Source port=80, Destination port=6311
&nbsp;
Which is still incorrect. The source port is irrelevant and the destination port&nbsp;MUST be 80. The problem is that you lingo is ambiguous because it uses non-standard terms.
&nbsp;
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&nbsp;and it still doesn't work...


UDP RECEIVE TEST.vi:
http://forums.ni.com/attachments/ni/170/334846/1/UDP RECEIVE TEST.vi

[altenbach]

I don't see the wireshark shot, but in your program, the port again&nbsp;defaults to&nbsp;6311. I assume that you change that to 80 before testing, right?
&nbsp;
EDIT:
&nbsp;
OK, which IP address is the&nbsp;computer that received the packets? Is it 192.168.200.80? How come there is also traffic on the other direction?Message Edited by altenbach on 06-25-2008 09:08 AM

[altenbach]

<img src="Loading Image...">
&nbsp;
&nbsp;
OK, we have see two participants, and there is traffic in both directions.
&nbsp;
(A) 192.168.200.72
(B) 192.168.200.80
&nbsp;
A sends regular UDP&nbsp;packets to B from a high port to port 80
Once in a while, B send a packet to A with a source port of 80 and a destination port of 6311.
&nbsp;
You are not yet telling us which IP address is which!
&nbsp;
We need to know where the other traffic comes from. Could it be that A is the computer that is supposed to receive packets? Is it B?
&nbsp;
One&nbsp;possible scenario interpertation:
&nbsp;
Some program on A regularly sends packets to port 80 of the remote device B, possibly a query. After such, B replies to port 6311, where your program is sopposed to be&nbsp;listening. What do you get if you listen on port 6311 as is the default for your program?
&nbsp;
What is the packet size? Could it be that the payload is empty?Message Edited by altenbach on 06-25-2008 09:22 AM


wireshark.png:
http://forums.ni.com/attachments/ni/170/334880/1/wireshark.png

[Isereau]

Your scenario is correct, but when I listen on 6311 I don't recieve anything.&nbsp; The packet size that is sent from (A) is 53 bytes including 11 data bytes and (B)'s reply (to&nbsp;port 6311)&nbsp;is 66 bytes including 24 data bytes.&nbsp;

[altenbach]

OK, on your computer at 192.168.200.72&nbsp;you run both &nbsp;(1)"UDP receive test" AND (2) "UDP send". Earlier in the discussion, we thought that these two programs talk to each other directly, but now we know that both talk to a remote device, one to query and one to grab the response.
&nbsp;
In "UDP receive test", I would remove the 200ms wait, because the loop rate is determined by the 200ms UDP timeout (or faster if needed&nbsp;if there is traffic). (OTOH, this is not the problem here). You need to listen on port 6311 as configured. Also make sure to add an error indicator after UDP read so you know if things go wrong, e.g. if it cannot listen because the port is already in use by something else. You should make the loop stop if there is an error.
&nbsp;
This brings me back to the firewall configuration. Are you really sure it is turned off?&nbsp;Do you really allow incomong UDP packets to port 6311? Can you show me the configuration screen of the windows firewall? I also assume that both devices are on the same flat network segment and there is no firewall or filtering bridge inbetween because wireshark sees the packets.
&nbsp;
Do you run any other kind of personal firewall software or security software?
&nbsp;

[Isereau]

altenbach wrote:
&nbsp;
<img src="http://forums.ni.com/attachments/ni/170/334880/1/wireshark.png">
&nbsp;

(A) 192.168.200.72------ Users computer
(B) 192.168.200.80------ Remote Device
&nbsp;
A sends regular UDP&nbsp;packets to B from a high port to port 80
Once in a while, B send a packet to A with a source port of 80 and a destination port of 6311.
&nbsp;
One&nbsp;possible scenario interpertation:
&nbsp;
Some program on A regularly sends packets to port 80 of the remote device B, possibly a query. After such, B replies to port 6311, where your program is sopposed to be&nbsp;listening. What do you get if you listen on port 6311 as is the default for your program?


Here is the situation...I just got off the phone with&nbsp;NI tech support and they are stumped as well, I check and double checked the firewall its definately off,&nbsp;still no go&nbsp;

&nbsp;


&nbsp;

[altenbach]

Isereau wrote:


Here is the situation...I just got off the phone with&nbsp;NI tech support and they are stumped as well, I check and double checked the firewall its definately off,&nbsp;still no go&nbsp;



OK, we need to do a few test. Do you have LabVIEW installed on any other computer on the network? If so, create a small program that can send UDP packets to&nbsp;a selectable&nbsp;port on a selectabel target IP..
&nbsp;
Now send packets to the program listening on 6311. Same result?
Now switch to some other port on each side and repeat?
(remember that you cannot change ports on your receiving program while it is running. The terminal only gets read at the start of the program.)
Try some high ports and some low ports.
Have you added an error indicator as instructed? Does it tell you anything?
&nbsp;

When the receiving program is running, open a command prompt and enter "netstat -an". post the output. See what process ID is listening on 6311 and then look up the process in the task manager.

[Isereau]

wireshark pic.JPG:
http://forums.ni.com/attachments/ni/170/334848/1/wireshark pic.JPG


UDPSEND1.vi:
http://forums.ni.com/attachments/ni/170/334848/2/UDPSEND1.vi

[smercurio_fc]

This is the point where altenbach starts screaming, and I know exactly what he's going to say. Wait for it... :smileyvery-happy:

[smercurio_fc]

I would doubt it's a firewall issue since the packets can be seen by Wireshark. I'm still not seeing the complete picture here of what the user is doing with this LabVIEW code, what with all the different versions and unclear explanations of what's running where.

[altenbach]

smercurio_fc wrote:I would doubt it's a firewall issue since the packets can be seen by Wireshark.


Are you sure that wireshark monitors only after the firewall? I always thought it sees all traffic.
I'll do some tests...

[smercurio_fc]

altenbach wrote:




smercurio_fc wrote:I would doubt it's a firewall issue since the packets can be seen by Wireshark.


Are you sure that wireshark monitors only after the firewall? I always thought it sees all traffic.
I'll do some tests...
Am I sure? No. If we're dealing with a software firewall only, then it's likely that Wireshark would indeed see all the packets since it's monitoring the network interface. If we're dealing with a potential hardware firewall, like a router, then it's a different story, obviously. That was why I had asked way back when about whether or not the computers were on the same subnet. As I stated in my last post, I'm not sure what the environment is anymore. Initially I thought we were dealing with a sender and a receiver only. Now it seems we're dealing with a sender and a receiver at one end, and I'm not sure what's at the other end. A picture at this point would sure be nice, with all IP addresses and ports written on it.