We Keep Coding

Let clients in a network find eachother

I have multiple pc's in a network, they each need to get each other ipaddress, i looked at broadcasting, but this requiers a server, but all pc's need to find all other. can anyone kick me in the right direction on how this could be implemented?

Well a server is technically a client that just listen for connection most of the time or provides a service.
Now, if you want that all client should discover each other. The simple way to achieve that would be send Listen for Broadcast Message at a specific port and send a broadcast message in the network that will help other client know that a EndPoint (Node) is now active.
An example would be
Listen on port XXXX as client starts up.
Broadcast a message at port XXXX this will help other client discover the node.
Once the client receives a discovery message, it sends its own detail to the client from which it received the message!

Problems with a simple UDP listener

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!

Sending UDP packet to destination on different subnet on LAN

I have a udp socket server written in C/C++ and a udp client written in C#. I can send packets back and forth, where the server simply echo's back the clients broadcasted message. However, when I send a udp packet to tell the server to reconfigure its network settings (IP, subnet, gateway, DNS) and rebind the adapter to refresh the settings, the client cannot receive the servers echo back anymore.
From what I have read so far, now that the server has different settings it could very well be on a different subnet on the same LAN. My question is how to send the packet back to the broadcasting client? I use the sendto() WIN32 api function, which sends the message to the IP Address and port it got from the broadcasted message. Is there another function that could send the packet back to the specific MAC of the client, therefore skipping the different subnet part? Or is there a different way to send the UDP packet across a local subnet?

RemoteEndPoint giving wrong IP address

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.

C# - Ping server with ICMP disabled

I am trying to ping a series of servers frequently using the PingReply class. Most of the time this is fine, but other times I get failed pings. I'm guessing this has something to do with ICMP being disabled on the remote server(s). Is there any way to get a ping to from a server even if ICMP is disabled?

If the remote server won't respond to an ICMP ECHO request, it won't work with the Ping command. Odds are there is some difference between the packet you're sending and the one Ping is sending. You can use something like Network Monitor or Wireshark to see the packets and compare them.
Odds are you're sending a packet with a lower TTL (or maybe too big of a buffer). I would try increasing PingOptions.Ttl first.

The ping command also uses ICMP. If you know of a port that will reliably be open on that machine, you can always establish a telnet connection.