LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP won't read

 
Download All
0 Kudos
Message 31 of 41
(1,661 Views)
This is the point where altenbach starts screaming, and I know exactly what he's going to say. Wait for it... Smiley Very Happy
0 Kudos
Message 32 of 41
(1,650 Views)
I don't see the wireshark shot, but in your program, the port again defaults to 6311. I assume that you change that to 80 before testing, right?
 
EDIT:
 
OK, which IP address is the 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
0 Kudos
Message 33 of 41
(1,641 Views)
 
 
OK, we have see two participants, and there is traffic in both directions.
 
(A) 192.168.200.72
(B) 192.168.200.80
 
A sends regular UDP 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.
 
You are not yet telling us which IP address is which!
 
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?
 
One possible scenario interpertation:
 
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 listening. What do you get if you listen on port 6311 as is the default for your program?
 
What is the packet size? Could it be that the payload is empty?


Message Edited by altenbach on 06-25-2008 09:22 AM
0 Kudos
Message 34 of 41
(1,631 Views)
Your scenario is correct, but when I listen on 6311 I don't recieve anything.  The packet size that is sent from (A) is 53 bytes including 11 data bytes and (B)'s reply (to port 6311) is 66 bytes including 24 data bytes. 
0 Kudos
Message 35 of 41
(1,617 Views)
OK, on your computer at 192.168.200.72 you run both  (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.
 
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 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.
 
This brings me back to the firewall configuration. Are you really sure it is turned off? 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.
 
Do you run any other kind of personal firewall software or security software?
 
0 Kudos
Message 36 of 41
(1,605 Views)
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.
0 Kudos
Message 37 of 41
(1,598 Views)


altenbach wrote:
 
 
(A) 192.168.200.72------ Users computer
(B) 192.168.200.80------ Remote Device
 
A sends regular UDP 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.
 
One possible scenario interpertation:
 
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 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 NI tech support and they are stumped as well, I check and double checked the firewall its definately off, still no go 


 

 
0 Kudos
Message 38 of 41
(1,589 Views)


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...
0 Kudos
Message 39 of 41
(1,576 Views)

@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.
0 Kudos
Message 40 of 41
(1,571 Views)