We Keep Coding

How to create TCP proxy for SSL stream

There's a transparent BLE to IP communication established between mobile (Xamarin) and BLE device.
The high-level diagram is the following:
Mobile TCP/IP socket <---> BLE Central <---> BLE Peripheral <---> SSL server on device
I want to establish TLS session over BLE, for this purpose the client connects to Mobile TCP/IP server socket over SSLStream, but on a method AuthenticateAsClient it hangs and mobile TCP/IP socket doesn't receive any data.
Taking in account that SSL is located above TCP I was expecting that TCP socket will receive all data related to SSL handshake process..
Please advise any ideas how to solve this.

Get IP address of devices that respond to broadcast

I have successfully created UDP sockets in C#. One to broadcast a command out to look for an device on the network. The other to receive the response data. I get the correct responses from the devices.
The question I have is how do I get the actual IP address of the devices that responds. I'm sending and receiving asynchronously on the receive side I am using socket.BeginReceiveFrom(...). It is VERY important that I know and save the IP address from each responding device.
Thanks, any help would be much appreciated.

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.

How broadcast ping works?

Hi
Can someone tell me why when I send broadcast ICMP Request, only router send me ICMP Reply?
Even if I modify MAC destination of this ICMP Request (original is FF:FF:FF:FF:FF:FF) to MAC specific host (IP still broadcast that local network ...it still don't send me Reply.
Why?

From RFC1122: "An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded"
MS Windows usually discard broadcast ping. Check that your computers are really running MS Windows.