Apparently ICMP isn't the only way to create a Traceroute. This and this answer indicates it's possible to send a UDP packet (or any other) with a low TTL and wait for the ICMP message.
How would I go about implementing this in C#? System.IO.Sockets? The TCP objects? Anyone know of an easy/best way?
Update 1:
The following code seems to correctly throw an exception when the TTL is hit. How do I extract information from the returned UDP Packet?
How do I know that the UDP packet I'm receiving is intended for me (and not some other application on my host?)
public void PingUDPAsync(IPAddress _destination, short ttl)
{
// This constructor arbitrarily assigns the local port number.
UdpClient udpClient = new UdpClient(21000);
udpClient.Ttl = ttl;
// udpClient.DontFragment = true;
try
{
udpClient.Connect(_destination, 21000);
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("Is anybody there?");
udpClient.Send(sendBytes, sendBytes.Length);
//IPEndPoint object will allow us to read datagrams sent from any source.
IPEndPoint RemoteIpEndPoint = new IPEndPoint(IPAddress.Any, 0);
// Blocks until a message returns on this socket from a remote host.
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
string returnData = Encoding.ASCII.GetString(receiveBytes);
// Uses the IPEndPoint object to determine which of these two hosts responded.
Console.WriteLine("This is the message you received " +
returnData.ToString());
Console.WriteLine("This message was sent from " +
RemoteIpEndPoint.Address.ToString() +
" on their port number " +
RemoteIpEndPoint.Port.ToString());
udpClient.Close();
}
catch (SocketException socketException)
{
Console.WriteLine(socketException.ToString());
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
Yes, System.Net.Sockets should provide you all the primitive objects you would need to send/receive UDP/TCP packets. Plenty of documentation and samples online, the two articles you included in your question are very interesting and a good starting point :)
https://learningnetwork.cisco.com/thread/87497
You can check out the answer here that goes into detail on Cisco's UPD traceroute implementation. It is rather comprehensive and can easily adapted to target a specific UDP port. You do not get a UDP packet back from the target. Rather, you get an ICMP reply to indicate the traffic was not received. The UDP packet that you originate has a random response port number included and your host tracks what ports are used by what applications. When the ICMP response is sent back, it is sent to the host IP and the response port included in the UDP header. Your host will then see the port and know it is bound to your application. It then delivers the packet to your application.
Related
I need to obtain UDP datagram from Asynchronous Socket Server but an exception occurred in my application :
Problem appear there :
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
The full source code:
class Program
{
static void Main(string[] args)
{
const int PORT = 30485;
IPAddress IP;
IPAddress.TryParse("92.56.23.87", out IP);
// This constructor arbitrarily assigns the local port number.
UdpClient udpClient = new UdpClient(PORT);
Socket receiveSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
try
{
udpClient.Connect("92.56.23.87", PORT);
if (udpClient.Client.Connected)
Console.WriteLine("Connected.");
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("CONNECT");
udpClient.Send(sendBytes, sendBytes.Length);
//IPEndPoint object will allow us to read datagrams sent from any source.
IPEndPoint RemoteIpEndPoint = new IPEndPoint(IP, PORT);
// Blocks until a message returns on this socket from a remote host.
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
string returnData = Encoding.ASCII.GetString(receiveBytes);
// Uses the IPEndPoint object to determine which of these two hosts responded.
Console.WriteLine("This is the message you received " + returnData.ToString());
Console.WriteLine("This message was sent from " + RemoteIpEndPoint.Address.ToString() + " on their port number " + RemoteIpEndPoint.Port.ToString());
udpClient.Close();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
Exception:
Connected.
System.Net.Sockets.SocketException (0x80004005): An existing connection
was forcibly closed by the remote host at System.Net.Sockets.Socket.ReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP) at ystem.Net.Sockets.UdpClient.Receive(IPEndPoint& remoteEP) at ConsoleApplication7.Program.Main(String[] args) in c:\users\user\documents\visual studio 2010\Projects\ConsoleApplication7\ConsoleApplication7\Program.cs
What can be the problem?
To provide more information, i bought the private socks connection on this page: http://rapidsocks.com/
this services give me a list of IP and port who in really is not a proxy .. just a connection that give me a proxyIP:proxyPort from a pool on server in response...
How to get that answer with proxyIP:proxyPort from the server?
In UDP land, one way this can occur is when you send a UDP packet to a host, and the remote host doesn't have a listener on that port, and bounces an ICMP host unreachable message in response.
In plain English, what this exception tells you that no process is listening on the far-end on that port.
Update: You should be able to avoid that behavior with the following code:
var udpClient = new UdpClient();
uint IOC_IN = 0x80000000;
uint IOC_VENDOR = 0x18000000;
uint SIO_UDP_CONNRESET = IOC_IN | IOC_VENDOR | 12;
udpClient.Client.IOControl((int)SIO_UDP_CONNRESET, new byte[] { Convert.ToByte(false) }, null);
Microsoft Article 263823 said this on the subject: [hard to find as of 2019]
SYMPTOMS
In Windows 2000, a User Datagram Protocol (UDP) program may
not work and may generate a WSAECONNRESET response.
CAUSE
If sending a datagram using the sendto function results in an
"ICMP port unreachable" response and the select function is set for
readfds, the program returns 1 and the subsequent call to the recvfrom
function does not work with a WSAECONNRESET (10054) error response. In
Microsoft Windows NT 4.0, this situation causes the select function to
block or time out.
RESOLUTION
A new sockets IOCTL called "SIO_UDP_CONNRESET" has been
introduced in Windows 2000. When this IOCTL is used, the program must
be rewritten specifically for Windows 2000 to obtain the original
Windows NT 4.0 behavior. Windows NT 4.0, Microsoft Windows 95, and
Microsoft Windows 98 have no support for this new IOCTL. In addition
to rewriting your application, you will need the hotfix referenced
further down in this article.
This really is a generic error message that could mean anything. Time to get the low level network traffic sniffers to filter what is actually going wrong. Adding extra error handling try catch blocks on the server with decent logging is always a great place to start.
I'm currently working with a measurement device that has an embedded Linux web server build in and could be controlled with the so called CGI-Interface over LAN. If one wants to change the settings of the device, one has to send at first a TCP/IP login packet and after this a key-code to control a specified function or receive data.
By using a TCP/IP packet tool, for example Paket Sender, everything works fine. A login packet to 192.168.0.1(Device) at port 80 from 192.168.0.2(PC) with the ASCII Text (These are standard password and login name, so I don't blur this out):
GET /cgi-bin/login.cgi?username=long&password=nga HTTP/1.0 \n \n
gets successfully received and acknowledged from the devices, as shown in the wireshark protocol:
Wireshark Screenshot
But the same request with the Standard C# TCP/IP Client provided by Microsoft returns a Bad Request Error Message. Somewhat C# does not send the [FIN,ACK] Packet like "Packet Sender". The modified code from Microsoft is as follows:
// Data buffer for incoming data.
byte[] bytes = new byte[1024];
// Connect to a remote device.
try
{
// Establish the remote endpoint for the socket.
// This example uses port 11000 on the local computer.
IPEndPoint remoteEP = new IPEndPoint(IPAddress.Parse("192.168.0.1"), 80);
// Create a TCP/IP socket.
Socket sender = new Socket(IPAddress.Parse("192.168.0.1").AddressFamily,
SocketType.Stream, ProtocolType.Tcp);
// Connect the socket to the remote endpoint. Catch any errors.
try
{
sender.Connect(remoteEP);
Console.WriteLine("Socket connected to {0}",
sender.RemoteEndPoint.ToString());
// Encode the data string into a byte array.
byte[] msg = Encoding.ASCII.GetBytes("GET /cgi-bin/login.cgi?username=long&password=nga HTTP/1.0 \n \n");
// Send the data through the socket.
int bytesSent = sender.Send(msg);
// Receive the response from the remote device.
int bytesRec = sender.Receive(bytes);
Console.WriteLine("Echoed test = {0}",
Encoding.ASCII.GetString(bytes, 0, bytesRec));
// Release the socket.
sender.Shutdown(SocketShutdown.Both);
sender.Close();
}
catch (ArgumentNullException ane)
{
Console.WriteLine("ArgumentNullException : {0}", ane.ToString());
}
catch (SocketException se)
{
Console.WriteLine("SocketException : {0}", se.ToString());
}
catch (Exception e)
{
Console.WriteLine("Unexpected exception : {0}", e.ToString());
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
Output for this snippet:
Socket connected to 192.168.0.1:80
Echoed test = HTTP/1.0 408 Request Timeout
Content-type: text/html
Date: Mon, 26 Mar 2018 16:41:34 GMT
Connection: close
<HTML><HEAD><TITLE>408 Request Timeout</TITLE></HEAD>
<BODY><H1>408 Request Timeout</H1>
No request appeared within 60 seconds
</BODY></HTML>
Wireshark Screenshot of this communication.
Well, I don't know, why C# doesn't send the [FIN,ACK] message. Maybe anyone has experienced the same? Or there is an easy explanation for this? Maybe I'm missing an option in the TCP/IP Sockets? If it helps, I could also provide the Wireshark protocol files.
I'm guessing that the server requires the sender to send the FIN/ACK before it sends the response, yes? FIN means shutting down that (directional) stream, so if the problem really is the missing FIN, I'm guessing that what you need here is after sending the request but before listening for the response, to add:
sender.Shutdown(SocketShutdown.Send);
which should FIN the outbound connection.
However, see also Dirk's comment on the question; it could simply be that you aren't correctly forming a complete request, and that the FIN is currently making it work indirectly.
Note that you might also want to set sender.NoDelay = true;, although that should be unrelated.
In C#, .Net 4, I have a need to send a UDP message on a port and listen for responses on the same port.
I was using a fixed port, but a customer ran into an issue with that, so I want to use any available port. It seems like I can do that by using 0 for the port number, but it isn't working. Digging into that some more, it appears it doesn't assign the port until it is actually used, so my two bind statements might be going to different ports.
From MSDN:
"If you do not care which local port is used, you can create an
IPEndPoint using 0 for the port number. In this case, the service
provider will assign an available port number between 1024 and 5000.
If you use the above approach, you can discover what local network
address and port number has been assigned by calling the
LocalEndPoint. ... If you are using a connectionless protocol, you
will not have access to this information until you have completed a
send or receive."
Trouble is, I want to set up my send and receive on initialization. If I wait until the first send to set up the receive, I might miss some responses. Is there a better answer than just sending a garbage message to assign the port so I can finish the initialization?
My code:
public bool InitializeSockets()
{
try
{
IPAddress localaddr = LocalIPAddress();
localep = new IPEndPoint(localaddr, 0); //(was port 50000);
//-----------------------------------------------------------------
// set up listener port for responses coming back on the same port
//-----------------------------------------------------------------
listener = new UdpClient();
listener.ExclusiveAddressUse = false;
listener.Client.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, true);
listener.Client.Bind(localep);
detailsOutputText = "Ready to listen on " + localep;
ustate = new UdpState();
ustate.e = localep;
ustate.u = listener;
//------------------------
// set up broadcast port
//------------------------
bcast = new UdpClient();
bcast.Client.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, true);
bcast.Client.Bind(localep);
//-------------------------------
// start listening for responses
//-------------------------------
msgRxCallback = listener.BeginReceive(new AsyncCallback(DiscoveryCallback), ustate);
return true;
}
catch (Exception exc)
{
if (exc is SocketException)
{
// This only catches if another process has opened that port without sharing it
// or if firewall blocks it?
MessageBox.Show("Error opening IP address:Port : " + localep;
}
else
MessageBox.Show(exc.ToString());
return false;
}
}
Thanks
Two options:
Create a configuration file that contains the port number. On initialization, read the config file and use that port number when setting up the clients. Supply a config file with a default port number, and give your customer instructions about how to change it if required.
In your initialization, create a receiver, give it a very short receive timeout, and call Receive. That will cause the port to bind. You can then get the local end point and use that when you create your sender. See Can I set the timeout for UdpClient in C#? regarding setting the receive timeout.
I have a simple UDP listener that I am trying to collect datagrams from. My datagrams can be in one of two data formats. With the first data format, I am receiving data in my program as expected. With the second, there is absolutely no indication that data is ever received from my program, even though I can verify that the UDP data is passing onto the the network interface via Wireshark. I thought that maybe these were malformed UDP packets that Windows was rejecting but Wireshark does label them as UDP. My code is below:
static void Main(string[] args)
{
Thread thdUdpServer = new Thread(new ThreadStart(serverThread));
thdUdpServer.Start();
}
static void serverThread()
{
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.Bind(new IPEndPoint(new IPAddress(0), 2000));
while (true)
{
byte[] responseData = new byte[128];
socket.Receive(responseData);
string returnData = Encoding.ASCII.GetString(responseData);
Console.WriteLine(DateTime.Now + " " + returnData);
}
The missing packets are all 29 byte datagrams that look something like this (translated to ASCII).
#01RdFFFF...?...... ........F
Why would Wireshark indicate their presence but .NET not seem to see them?
If the bytes contain non-printable ASCII characters, you may not see them on the Console.
There's something missing in your code. It should be throwing a socket exception when calling ReceiveFrom (at least according to MSDN, haven't tried your code.)
You should bind your socket to the address:port you want to listen on (or use 0.0.0.0 as the address to listen on any local address):
socket.Bind(new IPEndPoint(new IPAddress(0), 2000);
The EndPoint in ReceiveFrom is not the listening port for the server. It's the address you want to receive packets from. You can use an Endpoint of 0.0.0.0:0 to receive from any host.
After returning from the method the Endpoint will be filled with the address of the host that sent the packet (client).
You can use Receive instead of ReceiveFrom if you don't care about the client end point.
Likely your client is not sending packets from 192.168.1.100:2000, and that is why you are not receiving them; thought why you're not getting an exception when calling ReceiveFrom is beyond me.
Also:
There is no need to call Convert.ToInt32 in:
new IPEndPoint(IPAddress.Parse("192.168.1.100"), Convert.ToInt32(2000));
2000 is already an int.
I need to obtain UDP datagram from Asynchronous Socket Server but an exception occurred in my application :
Problem appear there :
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
The full source code:
class Program
{
static void Main(string[] args)
{
const int PORT = 30485;
IPAddress IP;
IPAddress.TryParse("92.56.23.87", out IP);
// This constructor arbitrarily assigns the local port number.
UdpClient udpClient = new UdpClient(PORT);
Socket receiveSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
try
{
udpClient.Connect("92.56.23.87", PORT);
if (udpClient.Client.Connected)
Console.WriteLine("Connected.");
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("CONNECT");
udpClient.Send(sendBytes, sendBytes.Length);
//IPEndPoint object will allow us to read datagrams sent from any source.
IPEndPoint RemoteIpEndPoint = new IPEndPoint(IP, PORT);
// Blocks until a message returns on this socket from a remote host.
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
string returnData = Encoding.ASCII.GetString(receiveBytes);
// Uses the IPEndPoint object to determine which of these two hosts responded.
Console.WriteLine("This is the message you received " + returnData.ToString());
Console.WriteLine("This message was sent from " + RemoteIpEndPoint.Address.ToString() + " on their port number " + RemoteIpEndPoint.Port.ToString());
udpClient.Close();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
Exception:
Connected.
System.Net.Sockets.SocketException (0x80004005): An existing connection
was forcibly closed by the remote host at System.Net.Sockets.Socket.ReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP) at ystem.Net.Sockets.UdpClient.Receive(IPEndPoint& remoteEP) at ConsoleApplication7.Program.Main(String[] args) in c:\users\user\documents\visual studio 2010\Projects\ConsoleApplication7\ConsoleApplication7\Program.cs
What can be the problem?
To provide more information, i bought the private socks connection on this page: http://rapidsocks.com/
this services give me a list of IP and port who in really is not a proxy .. just a connection that give me a proxyIP:proxyPort from a pool on server in response...
How to get that answer with proxyIP:proxyPort from the server?
In UDP land, one way this can occur is when you send a UDP packet to a host, and the remote host doesn't have a listener on that port, and bounces an ICMP host unreachable message in response.
In plain English, what this exception tells you that no process is listening on the far-end on that port.
Update: You should be able to avoid that behavior with the following code:
var udpClient = new UdpClient();
uint IOC_IN = 0x80000000;
uint IOC_VENDOR = 0x18000000;
uint SIO_UDP_CONNRESET = IOC_IN | IOC_VENDOR | 12;
udpClient.Client.IOControl((int)SIO_UDP_CONNRESET, new byte[] { Convert.ToByte(false) }, null);
Microsoft Article 263823 said this on the subject: [hard to find as of 2019]
SYMPTOMS
In Windows 2000, a User Datagram Protocol (UDP) program may
not work and may generate a WSAECONNRESET response.
CAUSE
If sending a datagram using the sendto function results in an
"ICMP port unreachable" response and the select function is set for
readfds, the program returns 1 and the subsequent call to the recvfrom
function does not work with a WSAECONNRESET (10054) error response. In
Microsoft Windows NT 4.0, this situation causes the select function to
block or time out.
RESOLUTION
A new sockets IOCTL called "SIO_UDP_CONNRESET" has been
introduced in Windows 2000. When this IOCTL is used, the program must
be rewritten specifically for Windows 2000 to obtain the original
Windows NT 4.0 behavior. Windows NT 4.0, Microsoft Windows 95, and
Microsoft Windows 98 have no support for this new IOCTL. In addition
to rewriting your application, you will need the hotfix referenced
further down in this article.
This really is a generic error message that could mean anything. Time to get the low level network traffic sniffers to filter what is actually going wrong. Adding extra error handling try catch blocks on the server with decent logging is always a great place to start.