I used the very basic sample code here - http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/92846ccb-fad3-469a-baf7-bb153ce2d82b/ - to create 2 console applications. One sends data via UDP, the 2nd application just receives and displays it. I did that on port 5115 and it all works fine. The sender sends random strings to 127.0.0.1:5115 and the listener receives it correctly.
We have a device that sends UDP packets to the same PC that I've been playing on, on port 5115. And using the same listener code, I receive absolutely nothing on it. What makes it weird is that Wireshark running on the same PC sees the packets just fine:
I have absolutely no idea what I'm doing wrong here. I receive 0 bytes on the same port Wireshark is seeing all this data! COuld you please offer some suggestions?
Thanks!
I think you're sending packet at the loopback addresse "127.0.0.1". It works fine when you run you both the Listener and Sender application on the same machine. But when you run the sender on some other device and the listener on a separate device, the communication fails.
Try changing loopback address in the Sender's application to the Listener Machines's IP Address
You can find out the IP Address of listener by going to Command Prompt on your Listener's Machine. Type "ipconfig" and press Enter. In the output you'll see some IPv4 Address. Try changing "127.0.0.1" to this IPv4 address.
Sigh The issue was the windows firewall. I didn't know Wireshark intercepts packets before the local firewall. 3 days down the drain...haha!
Related
We're using Fleck for our Websockets.
When we test our network program locally it all works fine. The process of a client connecting is:
Establish TCP connection
Send/receive infrequent TCP messages
Start sending/receiving UDP stream to server
The problem is on the live server which is far away geographically, clients can receive and send TCP messages, and they can send UDP messages, but they do not receive UDP messages.
We've investigated it as far as we can, and have found that the RemoteEndPoint property of the TCP connection on the server has the wrong IP address. It appears to be an IP address from our ISP. We use this IP address to attempt to send UDP messages back to the client. As it has the wrong IP, the client never receives these UDP messages.
The actual source IP address of the client must be known somewhere, as the TCP messages make it back OK. I've gone through the Fleck source and have printed out the RemoteEndPoint of the underlying System.Net.Socket but it keeps giving the wrong IP address.
Does anyone know what is going wrong and how we can expose the actual IP addresses of the clients?
The most likely reason is that your client does not have a public IP address, but a private address behind Network Address Translation (a very common setup). A common private addresses are of the form 10.X.X.X or 192.168.X.X.
NAT device replaces private address in a packet from your client with its IP address, which is public. For the outside world it seems that the traffic originates from the NAT device. The main advantage of NAT is that it allows many clients to use a single public IP address (IP addresses are sparse). But NAT introduces a problem: an incoming packet needs to be routed to a correct client, but it does not have a client IP address. Some other strategy needs to be used to recognize to which client a packet should be routed and such routing is not always possible.
For example, the most well known limitation of NAT is that you can't simply start a listening TCP server behind a NAT and then connect to it from the outside world. The reason is that NAT device has no idea that your server listens on a given port and thus, it has no way to known that TCP SYN packets from the outside world need to be passed to your client. A workaround for this is to explicitly configure the NAT device to route SYN packets directed to a given port to a specific client (port forwarding).
When a client behind a NAT initiates a TCP connection, a NAT device remembers state of the connection (client address, client port, remote address, remote port). Because of this, when a response arrives, the device knows to which client the response should be passed. When the connection is closed, the device discards state information. This is why your client can communicate over TCP.
But UDP is more difficult to handle because it is connectionless and stateless. When the device sees a UDP packet it does now known if a reply is expected and when, so not all NAT devices handle UDP traffic. Although there is a technique that allows to do it.
To summarize: the problem you are seeing is not C# specific. Setting IP address in packets from your server to the client IP address won't help, because it is most likely a private address that is not routable. To solve the problem you need to use a NAT device that can pass UDP traffic in both directions. But if you are developing a generic client to be used in many setups, you may want to reconsider if UDP is the best option. TCP connection forwarding is a basic feature that all NAT devices support, but some devices may not support UDP.
I've published an Android app which communicates with a C# server app via UDP. I've implemented an "Auto Connect" feature which does broadcasting and receives an answer from the server. Once an answer received by phone, the phone app holds the sender IP and sends subsequent messages to this IP directly. Also there is a Manual Connect feature which sends data to the IP address the user enters (which is the local IP of the PC running the server app).
So, everything works great for lots of users but some users reported me that when they use manual connect, it never connects; when they use auto connect, the server gets the broadcast message (seems connected) and the phone receives the answer but afterwards none of the (direct) messages will be received by the server app. The common point of these users is that their PCs are connected to the WiFi router by wire and their phones are connected by wireless. I've tried the same thing on my network but again it works for me without any problem.
May it be because of having multiple network interfaces (both LAN and WLAN)? I've been searching net for 1 week but no success.
What should I do? Please help.
Thanks in advance.
I am working an application in windows phone 7 that must detect the devices connected to particular port no or network. I have desktop application that is implemented in c++ that uses UDP broadcast. I read some articles and know windows phone 7 doesn't support UDP broadcasting. I have tried UDP multicasting in WP7 but due to desktop application have implemented in UDP broadcast, I am not able to do that.
Help me Guys...........
You can use socket.ConnectAsync with e.Buffer containing the message you want to broadcast. In this case, the message will be sent automatically when connection is established. More information about this trick you can read here
You could send a broadcast packet through just SendToAsync method by using limited broadcast IP, not local broadcast IP(such as 255.255.255.255) This means, if your NIC device is in 192.168.0.x IP range, you should shoot a packet to 192.168.0.255. (this IP might be vary on your netmask setting)
However, it works.
Additionally, response back is also allowed but FOR 5 SECONDS ONLY. Your host received a UDP packet from Windows Phone 7.1 device, the host should response back to the port that UDP packet came from, IN 5 SECONDS. Unless, Windows Phone will close the port then, and it has to be gone.
It's very tricky, weird, and ununderstandable(like this word) way.
but it works as far I know.
I am using the UDPClient class to send and receive messages on my loopback address. The executables are also interacting with each other. But why doesnt the traffic appear in wireshark?
BTW I am running windows inside parallels on OSX and can select only 1 interface that is my intel pro net network card in wireshark.
Here's the key phrase:
on my loopback address
The loopback address is a complete additional interface, not just an address. Wireshark is configured to listen on a specific interface, and I'm guessing the loopback interface is not it.
The loopback traffic is not captured by the Net Packet Filter driver.
One workaround is to send it to the IP address of your Intel Pro NIC. In my experience, this is enough to hit the NPF capture driver and show up in Wireshark. (Well, to be accurate, my experience in that matter doesn't involve a VM so YMMV).
Of course, the listener should be bound to that NIC IP to receive the packets (and not only to localhost).
We have a simple piece of legacy software with which we need to
communicate using TCP/IP over port 15001. We need to listen on port 15001
for the legacy software to make a connection and then read whatever it sends us.
We have tested this solution accross the internet and it works just fine.
If however we test the same solution across a GPRS TCP/IP network it does not.
All the basics have been checked, we can ping other devices in the GPRS network
and port 15001 is not blocked by any firewall.
So maybe there is something wrong with my TcpListener?
It is initialized like this:
tcpServer = new TcpListener(IPAddress.Any, TCP_PORT);
I'm assuming it listens on every available IPv4 enabled interface on the system,
because I used IPAddress.Any ?
Does anybody have any idea what the difference might be between the two networks? (Even though there shouldn't be any difference) and if there is something I need to change to my TcpListener?
You need to specify the IP address on which you want to listen, instead of IPAddress.Any. See here. When you use IPAddress.Any, it will automatically choose the network interface for you. To listen on a certain interface (in your case, GPRS) you have to use the correct IP in the constructor.
This post has more information on getting the IP address for each nic.
Also, if you're looking to listen on every IP address at once, you'll need a TcpListener for each nic.