I'm currently programming a UDP application which allows clients to login. After that, their endpoint gets stored in a list.
private void socket_Callback(IAsyncResult result_)
{
EndPoint remote = new IPEndPoint(IPAddress.Any, 0);
socket.EndReceiveFrom(result_, ref remote);
if (!listOfEndPoints.Contains(remote))
{
// registration process
// add it to list
listOfEndPoints.Add(remote)
}
else
{
// process packet
}
}
However, sometimes a client's NAT will assign every packet a different external end point. If the registration packet's source end point is 12.34.56.78:1000, that end point gets added to the list. If the same client then however sends another packet, the NAT will assign it a different port, so its source end point will be 12.34.56.78:1001.
This results in the server assuming the client is not registered and try to process the packet as a registration one. Needless to say this won't work.
A way of fixing this would be to send an ID (which could however be faked easily, if it's not super-cryptic) to the client. However, the client would have to add it to each packet it sends to the server.
So it wouldn't be very effective to do it like that.
Is there any other way of telling that the packet has come from the same client as the registration packet?
You should definitely not use the source IP address and port of a UDP packet to associate it with a logical connection. You should include the ID of the connection in each packet and update the IP and port you respond to if you receive a new IP and port for the same logical connection. If connection hi-jacking is an issue, you may need to implement some form of security, such as a secure checksum in the datagram.
TCP handles associating packets with connections for you. With UDP, you must associate datagrams with logical sessions yourself. I don't know why you think it "wouldn't be very effective to do it like that".
One of the tradeoffs of UDP is that if you need anything TCP provides, you have to code it yourself.
By the way, I've never seen ports shift in this way. Are you sure the client code isn't broken, perhaps opening a new socket for each datagram it sends.
Related
I have a SIP application that needs to send UDP packets to set up the SIP calls. SIP has a timeout mechanism to cope with delivery failures. An additional thing I would like to be able to do is detect whether a UDP socket is closed in order having to wait the 32s retransmit interval SIP uses.
The cases I am referring to are when an attempt to send to a UDP socket results in an ICMP Destination Unreachable packet being generated by the remote host. If I attempt to send a UDP packet to a host that's up but that the port is not listening I can see the ICMP message arriving back with a packet tracer but the question is how do I get access to that from my C# code?
I'm playing around with raw sockets but as yet have not been able to get the ICMP packets to be received by my program. The sample below never receives a packet even though ICMP messages are arriving on my PC.
Socket icmpListener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
icmpListener.Bind(new IPEndPoint(IPAddress.Any, 0));
byte[] buffer = new byte[4096];
EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
int bytesRead = icmpListener.ReceiveFrom(buffer, ref remoteEndPoint);
logger.Debug("ICMPListener received " + bytesRead + " from " + remoteEndPoint.ToString());
Below is a wireshark trace showing the ICMP responses coming into my PC from an attempt to send a UDP packet from 10.0.0.100 (my PC) to 10.0.0.138 (my router) on a port I know it's not listening on. My problem is how to make use of those ICMP packets to realise the UDP send has failed rather than just waiting for the application to timeout after an arbitrary period?
Nearly 3 years later and I stumbled across http://www.codeproject.com/Articles/17031/A-Network-Sniffer-in-C which gave me enough of a hint to help me find a solution to receiving ICMP packets on Windows 7 (don't know about Vista, which the original question was about but I suspect this solution would work).
The two key points are that the socket has to be bound to a single specific IP address rather than IPAddress.Any and the IOControl call which sets the SIO_RCVALL flag.
Socket icmpListener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
icmpListener.Bind(new IPEndPoint(IPAddress.Parse("10.1.1.2"), 0));
icmpListener.IOControl(IOControlCode.ReceiveAll, new byte[] { 1, 0, 0, 0 }, new byte[] { 1, 0, 0, 0 });
byte[] buffer = new byte[4096];
EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
int bytesRead = icmpListener.ReceiveFrom(buffer, ref remoteEndPoint);
Console.WriteLine("ICMPListener received " + bytesRead + " from " + remoteEndPoint);
Console.ReadLine();
I also had to set a firewall rule to allow ICMP Port Unreachable packets to be received.
netsh advfirewall firewall add rule name="All ICMP v4" dir=in action=allow protocol=icmpv4:any,any
UPDATE: I think I'm going crazy.... That piece of code that you posted is also working for me...
The following piece of code works fine for me(xp sp3):
using System;
using System.Net;
using System.Net.Sockets;
namespace icmp_capture
{
class Program
{
static void Main(string[] args)
{
IPEndPoint ipMyEndPoint = new IPEndPoint(IPAddress.Any, 0);
EndPoint myEndPoint = (ipMyEndPoint);
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
socket.Bind(myEndPoint);
while (true)
{
/*
//SEND SOME BS (you will get a nice infinite loop if you uncomment this)
var udpClient = new UdpClient("192.168.2.199", 666); //**host must exist if it's in the same subnet (if not routed)**
Byte[] messagebyte = Encoding.Default.GetBytes("hi".ToCharArray());
int s = udpClient.Send(messagebyte, messagebyte.Length);
*/
Byte[] ReceiveBuffer = new Byte[256];
var nBytes = socket.ReceiveFrom(ReceiveBuffer, 256, 0, ref myEndPoint);
if (ReceiveBuffer[20] == 3)// ICMP type = Delivery failed
{
Console.WriteLine("Delivery failed");
Console.WriteLine("Returned by: " + myEndPoint.ToString());
Console.WriteLine("Destination: " + ReceiveBuffer[44] + "." + ReceiveBuffer[45] + "." + ReceiveBuffer[46] + "." + ReceiveBuffer[47]);
Console.WriteLine("---------------");
}
else {
Console.WriteLine("Some (not delivery failed) ICMP packet ignored");
}
}
}
}
}
Icmp is using an identifier which seems to be different for every icmp "session" (for every icmp socket). So the reply to an icmp packet not sent by the same socket is helpfully filtered out for you. This is why that piece of code won't work. (I'm not sure about this. It's just an assumption after looking at some ICMP traffic.)
You could simply ping the host and see whether you can reach it or not and then try your SIP thing. However that won't work if the other host is filtering out icmp.
An ugly (but working) solution is using winpcap. (Having this as the only working solutions just seems to be too bad to be true.)
What I mean by using winpcap is the you could capture ICMP traffic and then see if the captured packet is about your UDP packet being undeliverable or not.
Here is an example for capturing tcp packets:
http://www.tamirgal.com/home/SourceView.aspx?Item=SharpPcap&File=Example6.DumpTCP.cs
(It shouldn't be too hard to do the same with ICMP.)
Just use connected udp sockets and the OS will match the icmp unreachable and return an error in the udp socket.
Google for connected udp sockets.
So you want to pick up the dest unreachable return icmp packet programmatically? A tough one. I'd say the network stack soaks that up before you can get anywhere near it.
I don't think a pure C# approach will work here. You'll need to use a driver level intercept to get a hook in. Take a look at this app that uses windows' ipfiltdrv.sys to trap packets (icmp,tcp,udp etc) and read/play with them with managed code (c#).
http://www.codeproject.com/KB/IP/firewall_sniffer.aspx?display=Print
Oisin
There are a number of posts on the web mentioning the problem of ICMP Port Unreachable packets no longer being accessible on Vista.
http://www.eggheadcafe.com/software/aspnet/31961998/icmp-port-unreachable-and.aspx
http://social.msdn.microsoft.com/Forums/en-US/Offtopic/thread/5bd8b275-cc6f-43cd-949d-7c411973b2f3/
The stack should give you back an exception when it receives the ICMP. But it doesn't, at least on Vista. And hence you are trying a workaround.
I don't like answers that say it's not possible, but it seems that way. So I suggest you go back a step to the original problem, which was long timeouts in SIP.
You could let the user configure the
timeout (hence sort of complying with
the spec).
You can start doing other things (like checking other proxies) before
the timeout ends.
You could cache known bad destinations (but that would need
good management of the cache.
If icmp, and udp don't give proper error messages, try tcp or another protocol. Just to elicit the desired information.
(Anything is possible, it just may take a lot of resources.)
I am writing this as a separate answer, since the details are completely different from the one I wrote earlier.
So based on the comment from Kalmi about the session ID, it got me to thinking about why I can open up two ping programs on the same machine, and the responses don't cross over. They are both ICMP, therefore both using port-less raw sockets. That means something in the IP stack, has to know what socket those responses were intended for. For ping it turns out there is an ID used in the data of the ICMP package as part of ECHO REQUEST and ECHO REPLY.
Then I ran across this comment on wikipedia about ICMP:
Although ICMP messages are contained
within standard IP datagrams, ICMP
messages are usually processed as a
special case, distinguished from
normal IP processing, rather than
processed as a normal sub-protocol of
IP. In many cases, it is necessary to
inspect the contents of the ICMP
message and deliver the appropriate
error message to the application that
generated the original IP packet, the
one that prompted the sending of the
ICMP message.
Which was elaborated on (indirectly) here:
The internet header plus the first 64
bits of the original datagram's data.
This data is used by the host to match
the message to the appropriate
process. If a higher level protocol
uses port numbers, they are assumed to
be in the first 64 data bits of the
original datagram's data.
Since you are using UDP, which uses ports, it is possible the network stack is routing the ICMP message back to the original socket. This is why your new, and separate, socket is never receiving those messages. I imagine UDP eats the ICMP message.
If I am correct, one solution to this is to open a raw socket and manually create your UDP packets, listen for the anything coming back, and handle UDP and ICMP messages as appropriate. I am not sure what that would look like in code, but I don't imagine it would be too difficult, and may be considered more "elegant" than the winpcap solution.
Additionally this link, http://www.networksorcery.com/enp/default1003.htm, appears to be a great resource for low level network protocols.
I hope this helps.
Is there any way of dealing with sessions with sockets in C#?
Example of my problem:
I have a server with a socket listening on port 5672.
TcpListener socket = new TcpListener(localAddr, 5672);
socket.Start();
Console.Write("Waiting for a connection... ");
// Perform a blocking call to accept requests.
TcpClient client = socket.AcceptTcpClient();
Console.WriteLine("Connected to client!");
And i have two clients that will send one byte. Client A send 0x1 and client B send 0x2.
From the server side, i read this data like this:
Byte[] bytes = new Byte[256];
String data = null;
NetworkStream stream = client.GetStream();
while ((stream.Read(bytes, 0, bytes.Length)) != 0)
{
byte[] answer = new ...
stream.Write(answer , 0, answer.Length);
}
Then client A sends 0x11.
I need a way to know that this client is the same that sent "0x1" before.
Each TcpClient instance is for a different connection. A connection in TCP consists of four things: source IP, source port, target IP, target port. So, even if you have the same target IP and port, and the same source port, you have two different connections.
Data sent by one client will not be mixed in with data sent by the other client. Data sent by a client on a connection will be received in order over that connection.
The only time that Sessions become an issue is to remember the client after the connection is closed.
You would probably need to implement your own protocol in order to identify the clients. Perhaps define a chunk of bytes, where in addition to the data you also include a client identifier.
You'll need some sort of authentication or pre-negotiated token, and all of this somehow encrypted with some salt.
There is a lot of existing literature on how sessions are implemented in the Web world (HTTP).
One key is whether you are closing the client connections, or are they persistent? If they are persistent, then simply identify them by their object reference. If not, then...
1) You can do simple sessions based on the source IP address. But if multiple clients are behind a NAT firewall, sharing the IP, then that doesn't work, see the next option.
2) Use a "cookie"
3) Use authentication to identify each client
Every option except IP based sessions requires adding something to the protocol itself.
Some things to remember with sockets. The remote IP + remote port uniquely identifies a client TCP socket. Multiple connections from the same remote client will have diffent remote ports. But you cannot rely on that if the socket closes, because the remote OS may recycle the remote port for a new connection once the old one times out.
Context: I'm porting a linux perl app to C#, the server listens on a udp port and maintains multiple concurrent dialogs with remote clients via a single udp socket. During testing, I send out high volumes of packets to the udp server, randomly restarting the clients to observe the server registering the new connections. The problem is this: when I kill a udp client, there may still be data on the server destined for that client. When the server tries to send this data, it gets an icmp "no service available" message back and consequently an exception occurs on the socket.
I cannot reuse this socket, when I try to associate a C# async handler with the socket, it complains about the exception, so I have to close and reopen the udp socket on the server port. Is this the only way around this problem?, surely there's some way of "fixing" the udp socket, as technically, UDP sockets shouldn't be aware of the status of a remote socket?
Any help or pointers would be much appreciated. Thanks.
I think you are right in saying: 'the server should not be aware'. If you send an UDP packet to some IP/port which may or may not be open, there is no way of knowing for the server if it reached it's destination.
The only way for the server to know is to have the client send an ACK back. (Also both the client and server must have resend mechanisms in place in cases of lost packages).
So clearly something else is going on in your code (or with the .Net udp implementation)
EDIT:
After Nikolai's remark I checked the docs. And indeed there is a distinction in .Net to about being 'connected' or 'connectionless' when using UDP.
If you use code like this:
UdpClient udpClient = new UdpClient(11000); //sourceport
try{
udpClient.Connect("www.contoso.com", 11000); //'connect' to destmachine and port
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("Is anybody there?");
udpClient.Send(sendBytes, sendBytes.Length);
then apparently you are 'connected'
However if you use code like this:
UdpClient udpClientB = new UdpClient();
udpClientB.Send(sendBytes, sendBytes.Length, "AlternateHostMachineName", 11000);
then you can send to whomever you choose without 'connecting'.
I'm not sure what your code looks like, but it might be worthwhile to check if you are using the correct set of commands which doesn't assume a 'connection'
I have seen many resources here on SO about Sockets. I believe none of them covered the details which I wanted to know. In my application, server does all the processing and send periodic updates to the clients.
Intention of this post is to cover all the basic ideas required when developing a socket application and discuss the best practices. Here are the basic things that you will see with almost all socket based applications.
1 - Binding and listening on a socket
I am using the following code. It works well on my machine. Do I need to take care about something else when I deploy this on a real server?
IPHostEntry localHost = Dns.GetHostEntry(Dns.GetHostName());
IPEndPoint endPoint = new IPEndPoint(localHost.AddressList[0], 4444);
serverSocket = new Socket(endPoint.AddressFamily, SocketType.Stream,
ProtocolType.Tcp);
serverSocket.Bind(endPoint);
serverSocket.Listen(10);
2 - Receiving data
I have used a 255 sized byte array. So when I am receiving data which is more than 255 bytes, I need to call the receive method until I get the full data, right? Once I got the full data, I need to append all the bytes received so far to get the full message. Is that correct? Or is there a better approach?
3 - Sending data and specifying the data length
Since there is no way in TCP to find the length of the message to receive, I am planning to add the length to the message. This will be the first byte of the packet. So client systems knows how much data is available to read.
Any other better approach?
4 - Closing the client
When client is closed, it will send a message to server indicating the close. Server will remove the client details from it's client list. Following is the code used at client side to disconnect the socket (messaging part not shown).
client.Shutdown(SocketShutdown.Both);
client.Close();
Any suggestions or problems?
5 - Closing the server
Server sends message to all clients indicating the shutdown. Each client will disconnect the socket when it receives this message. Clients will send the close message to server and close. Once server receives close message from all the clients, it disconnects the socket and stop listening. Call Dispose on each client sockets to release the resources. Is that the correct approach?
6 - Unknown client disconnections
Sometimes, a client may disconnect without informing the server. My plan to handle this is: When server sends messages to all clients, check the socket status. If it is not connected, remove that client from the client list and close the socket for that client.
Any help would be great!
Since this is 'getting started' my answer will stick with a simple implementation rather than a highly scalable one. It's best to first feel comfortable with the simple approach before making things more complicated.
1 - Binding and listening
Your code seems fine to me, personally I use:
serverSocket.Bind(new IPEndPoint(IPAddress.Any, 4444));
Rather than going the DNS route, but I don't think there is a real problem either way.
1.5 - Accepting client connections
Just mentioning this for completeness' sake... I am assuming you are doing this otherwise you wouldn't get to step 2.
2 - Receiving data
I would make the buffer a little longer than 255 bytes, unless you can expect all your server messages to be at most 255 bytes. I think you'd want a buffer that is likely to be larger than the TCP packet size so you can avoid doing multiple reads to receive a single block of data.
I'd say picking 1500 bytes should be fine, or maybe even 2048 for a nice round number.
Alternately, maybe you can avoid using a byte[] to store data fragments, and instead wrap your server-side client socket in a NetworkStream, wrapped in a BinaryReader, so that you can read the components of your message direclty from the socket without worrying about buffer sizes.
3 - Sending data and specifying data length
Your approach will work just fine, but it does obviously require that it is easy to calculate the length of the packet before you start sending it.
Alternately, if your message format (order of its components) is designed in a fashion so that at any time the client will be able to determine if there should be more data following (for example, code 0x01 means next will be an int and a string, code 0x02 means next will be 16 bytes, etc, etc). Combined with the NetworkStream approach on the client side, this may be a very effective approach.
To be on the safe side you may want to add validation of the components being received to make sure you only process sane values. For example, if you receive an indication for a string of length 1TB you may have had a packet corruption somewhere, and it may be safer to close the connection and force the client to re-connect and 'start over'. This approach gives you a very good catch-all behaviour in case of unexpected failures.
4/5 - Closing the client and the server
Personally I would opt for just Close without further messages; when a connection is closed you will get an exception on any blocking read/write at the other end of the connection which you will have to cater for.
Since you have to cater for 'unknown disconnections' anyway to get a robust solution, making disconnecting any more complicated is generally pointless.
6 - Unknown disconnections
I would not trust even the socket status... it is possible for a connection to die somewhere along the path between client / server without either the client or the server noticing.
The only guaranteed way to tell a connection that has died unexpectedly is when you next try to send something along the connection. At that point you will always get an exception indicating failure if anything has gone wrong with the connection.
As a result, the only fool-proof way to detect all unexpected connections is to implement a 'ping' mechanism, where ideally the client and the server will periodically send a message to the other end that only results in a response message indicating that the 'ping' was received.
To optimise out needless pings, you may want to have a 'time-out' mechanism that only sends a ping when no other traffic has been received from the other end for a set amount of time (for example, if the last message from the server is more than x seconds old, the client sends a ping to make sure the connection has not died without notification).
More advanced
If you want high scalability you will have to look into asynchronous methods for all the socket operations (Accept / Send / Receive). These are the 'Begin/End' variants, but they are a lot more complicated to use.
I recommend against trying this until you have the simple version up and working.
Also note that if you are not planning to scale further than a few dozen clients this is not actually going to be a problem regardless. Async techniques are really only necessary if you intend to scale into the thousands or hundreds of thousands of connected clients while not having your server die outright.
I probably have forgotten a whole bunch of other important suggestions, but this should be enough to get you a fairly robust and reliable implementation to start with
1 - Binding and listening on a socket
Looks fine to me. Your code will bind the socket only to one IP address though. If you simply want to listen on any IP address/network interface, use IPAddress.Any:
serverSocket.Bind(new IPEndPoint(IPAddress.Any, 4444));
To be future proof, you may want to support IPv6. To listen on any IPv6 address, use IPAddress.IPv6Any in place of IPAddress.Any.
Note that you cannot listen on any IPv4 and any IPv6 address at the same time, except if you use a Dual-Stack Socket. This will require you to unset the IPV6_V6ONLY socket option:
serverSocket.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);
To enable Teredo with your socket, you need to set the PROTECTION_LEVEL_UNRESTRICTED socket option:
serverSocket.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)23, 10);
2 - Receiving data
I'd recommend using a NetworkStream which wraps the socket in a Stream instead of reading the chunks manually.
Reading a fixed number of bytes is a bit awkward though:
using (var stream = new NetworkStream(serverSocket)) {
var buffer = new byte[MaxMessageLength];
while (true) {
int type = stream.ReadByte();
if (type == BYE) break;
int length = stream.ReadByte();
int offset = 0;
do
offset += stream.Read(buffer, offset, length - offset);
while (offset < length);
ProcessMessage(type, buffer, 0, length);
}
}
Where NetworkStream really shines is that you can use it like any other Stream. If security is important, simply wrap the NetworkStream in a SslStream to authenticate the server and (optionally) the clients with X.509 certificates. Compression works the same way.
var sslStream = new SslStream(stream, false);
sslStream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Tls, true);
// receive/send data SSL secured
3 - Sending data and specifying the data length
Your approach should work, although you probably may not want to go down the road to reinventing the wheel and design a new protocol for this. Have a look at BEEP or maybe even something simple like protobuf.
Depending on your goals, it might be worth thinking about choosing an abstraction above sockets like WCF or some other RPC mechanism.
4/5/6 - Closing & Unknown disconnections
What jerryjvl said :-) The only reliable detection mechanism are pings or sending keep-alives when the connection is idle.
While you have to deal with unknown disconnections in any case, I'd personally keep some protocol element in to close a connection in mutual agreement instead of just closing it without warning.
Consider using asynchronous sockets. You can find more information on the subject in
Using an Asynchronous Server Socket
Using an Asynchronous Client Socket
I have a SIP application that needs to send UDP packets to set up the SIP calls. SIP has a timeout mechanism to cope with delivery failures. An additional thing I would like to be able to do is detect whether a UDP socket is closed in order having to wait the 32s retransmit interval SIP uses.
The cases I am referring to are when an attempt to send to a UDP socket results in an ICMP Destination Unreachable packet being generated by the remote host. If I attempt to send a UDP packet to a host that's up but that the port is not listening I can see the ICMP message arriving back with a packet tracer but the question is how do I get access to that from my C# code?
I'm playing around with raw sockets but as yet have not been able to get the ICMP packets to be received by my program. The sample below never receives a packet even though ICMP messages are arriving on my PC.
Socket icmpListener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
icmpListener.Bind(new IPEndPoint(IPAddress.Any, 0));
byte[] buffer = new byte[4096];
EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
int bytesRead = icmpListener.ReceiveFrom(buffer, ref remoteEndPoint);
logger.Debug("ICMPListener received " + bytesRead + " from " + remoteEndPoint.ToString());
Below is a wireshark trace showing the ICMP responses coming into my PC from an attempt to send a UDP packet from 10.0.0.100 (my PC) to 10.0.0.138 (my router) on a port I know it's not listening on. My problem is how to make use of those ICMP packets to realise the UDP send has failed rather than just waiting for the application to timeout after an arbitrary period?
Nearly 3 years later and I stumbled across http://www.codeproject.com/Articles/17031/A-Network-Sniffer-in-C which gave me enough of a hint to help me find a solution to receiving ICMP packets on Windows 7 (don't know about Vista, which the original question was about but I suspect this solution would work).
The two key points are that the socket has to be bound to a single specific IP address rather than IPAddress.Any and the IOControl call which sets the SIO_RCVALL flag.
Socket icmpListener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
icmpListener.Bind(new IPEndPoint(IPAddress.Parse("10.1.1.2"), 0));
icmpListener.IOControl(IOControlCode.ReceiveAll, new byte[] { 1, 0, 0, 0 }, new byte[] { 1, 0, 0, 0 });
byte[] buffer = new byte[4096];
EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
int bytesRead = icmpListener.ReceiveFrom(buffer, ref remoteEndPoint);
Console.WriteLine("ICMPListener received " + bytesRead + " from " + remoteEndPoint);
Console.ReadLine();
I also had to set a firewall rule to allow ICMP Port Unreachable packets to be received.
netsh advfirewall firewall add rule name="All ICMP v4" dir=in action=allow protocol=icmpv4:any,any
UPDATE: I think I'm going crazy.... That piece of code that you posted is also working for me...
The following piece of code works fine for me(xp sp3):
using System;
using System.Net;
using System.Net.Sockets;
namespace icmp_capture
{
class Program
{
static void Main(string[] args)
{
IPEndPoint ipMyEndPoint = new IPEndPoint(IPAddress.Any, 0);
EndPoint myEndPoint = (ipMyEndPoint);
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
socket.Bind(myEndPoint);
while (true)
{
/*
//SEND SOME BS (you will get a nice infinite loop if you uncomment this)
var udpClient = new UdpClient("192.168.2.199", 666); //**host must exist if it's in the same subnet (if not routed)**
Byte[] messagebyte = Encoding.Default.GetBytes("hi".ToCharArray());
int s = udpClient.Send(messagebyte, messagebyte.Length);
*/
Byte[] ReceiveBuffer = new Byte[256];
var nBytes = socket.ReceiveFrom(ReceiveBuffer, 256, 0, ref myEndPoint);
if (ReceiveBuffer[20] == 3)// ICMP type = Delivery failed
{
Console.WriteLine("Delivery failed");
Console.WriteLine("Returned by: " + myEndPoint.ToString());
Console.WriteLine("Destination: " + ReceiveBuffer[44] + "." + ReceiveBuffer[45] + "." + ReceiveBuffer[46] + "." + ReceiveBuffer[47]);
Console.WriteLine("---------------");
}
else {
Console.WriteLine("Some (not delivery failed) ICMP packet ignored");
}
}
}
}
}
Icmp is using an identifier which seems to be different for every icmp "session" (for every icmp socket). So the reply to an icmp packet not sent by the same socket is helpfully filtered out for you. This is why that piece of code won't work. (I'm not sure about this. It's just an assumption after looking at some ICMP traffic.)
You could simply ping the host and see whether you can reach it or not and then try your SIP thing. However that won't work if the other host is filtering out icmp.
An ugly (but working) solution is using winpcap. (Having this as the only working solutions just seems to be too bad to be true.)
What I mean by using winpcap is the you could capture ICMP traffic and then see if the captured packet is about your UDP packet being undeliverable or not.
Here is an example for capturing tcp packets:
http://www.tamirgal.com/home/SourceView.aspx?Item=SharpPcap&File=Example6.DumpTCP.cs
(It shouldn't be too hard to do the same with ICMP.)
Just use connected udp sockets and the OS will match the icmp unreachable and return an error in the udp socket.
Google for connected udp sockets.
So you want to pick up the dest unreachable return icmp packet programmatically? A tough one. I'd say the network stack soaks that up before you can get anywhere near it.
I don't think a pure C# approach will work here. You'll need to use a driver level intercept to get a hook in. Take a look at this app that uses windows' ipfiltdrv.sys to trap packets (icmp,tcp,udp etc) and read/play with them with managed code (c#).
http://www.codeproject.com/KB/IP/firewall_sniffer.aspx?display=Print
Oisin
There are a number of posts on the web mentioning the problem of ICMP Port Unreachable packets no longer being accessible on Vista.
http://www.eggheadcafe.com/software/aspnet/31961998/icmp-port-unreachable-and.aspx
http://social.msdn.microsoft.com/Forums/en-US/Offtopic/thread/5bd8b275-cc6f-43cd-949d-7c411973b2f3/
The stack should give you back an exception when it receives the ICMP. But it doesn't, at least on Vista. And hence you are trying a workaround.
I don't like answers that say it's not possible, but it seems that way. So I suggest you go back a step to the original problem, which was long timeouts in SIP.
You could let the user configure the
timeout (hence sort of complying with
the spec).
You can start doing other things (like checking other proxies) before
the timeout ends.
You could cache known bad destinations (but that would need
good management of the cache.
If icmp, and udp don't give proper error messages, try tcp or another protocol. Just to elicit the desired information.
(Anything is possible, it just may take a lot of resources.)
I am writing this as a separate answer, since the details are completely different from the one I wrote earlier.
So based on the comment from Kalmi about the session ID, it got me to thinking about why I can open up two ping programs on the same machine, and the responses don't cross over. They are both ICMP, therefore both using port-less raw sockets. That means something in the IP stack, has to know what socket those responses were intended for. For ping it turns out there is an ID used in the data of the ICMP package as part of ECHO REQUEST and ECHO REPLY.
Then I ran across this comment on wikipedia about ICMP:
Although ICMP messages are contained
within standard IP datagrams, ICMP
messages are usually processed as a
special case, distinguished from
normal IP processing, rather than
processed as a normal sub-protocol of
IP. In many cases, it is necessary to
inspect the contents of the ICMP
message and deliver the appropriate
error message to the application that
generated the original IP packet, the
one that prompted the sending of the
ICMP message.
Which was elaborated on (indirectly) here:
The internet header plus the first 64
bits of the original datagram's data.
This data is used by the host to match
the message to the appropriate
process. If a higher level protocol
uses port numbers, they are assumed to
be in the first 64 data bits of the
original datagram's data.
Since you are using UDP, which uses ports, it is possible the network stack is routing the ICMP message back to the original socket. This is why your new, and separate, socket is never receiving those messages. I imagine UDP eats the ICMP message.
If I am correct, one solution to this is to open a raw socket and manually create your UDP packets, listen for the anything coming back, and handle UDP and ICMP messages as appropriate. I am not sure what that would look like in code, but I don't imagine it would be too difficult, and may be considered more "elegant" than the winpcap solution.
Additionally this link, http://www.networksorcery.com/enp/default1003.htm, appears to be a great resource for low level network protocols.
I hope this helps.