Raw sockets corrupting IP headers

[jasonbstubbs]

Raw sockets corrupting IP headers (SOLVED)

 

I'm listening for ICMP packets using the following method to capture packets. I'm also running a packet sniffer to see what goes in and out of the box.

 

Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);
socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout, 100);
socket.Bind((EndPoint)new IPEndPoint(System.Net.IPAddress.Any, 0));

byte[] buffer = new byte[2000];
IPEndPoint ipendpoint = new IPEndPoint(System.Net.IPAddress.Any, 0);
EndPoint endpoint = (EndPoint)ipendpoint;
socket.ReceiveFrom(buffer, buffer.Length, SocketFlags.Peek, ref endpoint);

 

However, what I'm finding is that some of the values in the IP header returned differ from what the sniffer is showing. Specifically, the TTL is different.

 

Does anybody know what could be causing this? Even better, does anybody know how to prevent this?

Edited November 15, 2003 by jasonbstubbs

[PlausiblyDamp]

How different is the TTL - is it higher or lower and how much is it out by?

Are there any router / NAT devices between the sniffer and device / your code?

[jasonbstubbs]

The sniffer gives a TTL of 128 on a icmp echo reply from a Windows XP machine which is what I would expect. Sockets is returning a TTL of 255, which is incidentally the TTL that I used when sending out the echo request but that was done using a different Socket instance.

 

And the answer to your second question: the sniffer is Ethereal and is running on the same machine that is receiving the packets. The "pinger" and "pingee" are connected to the same switch.

Edited November 14, 2003 by jasonbstubbs

[jasonbstubbs]

Okay. I checked with setting a TTL of 64 on the echo request and found that the reply I received had also had a TTL of 64, but the sniffer is still showing 128.

[jasonbstubbs]

Arggg. Never mind. In my class that holds an IP packet, I was initializing the header with some nice default values in the constructor. Unfortunately (or idiotically) that was overwriting the received packet's data.