|
Hi all,
I try to sniff dhcpdiscover on the network.
I can't see any broadcast UDP. I try to modify the programe like this :
socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
and
socket.SetSocketOption(SocketOptionLevel.Socket,SocketOptionName.Broadcast, 1);
The sniffer see nothing
Can someone help me
thanks for your help
arnaud
|
|
|
|
|
|
Yep,
I use the Microsoft API for dhcp server in W2K3.
It's working very well you can catch and do what you want.
|
|
|
|
|
actually we're developing a project in which we need to capture TCP flags
we've tried to make similar class StreamSocket, done with small changes to
the RawSocket class, but actually, we can't read the TCP header correct
i just want to check if this is the corect initialization of the socket object
socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
& if the correct socket option is
socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.HeaderIncluded, 1);
a question: what does the intger value of the third parameter mean ??
& if this is the correct changes in order to read the TCP header, should this read the IP header
followed by the TCP one or what???
anybody can help??
mehro
|
|
|
|
|
Can we change the data after geting it to change the original sent data ? (Spoofing)
|
|
|
|
|
RawSocket Class not run in Windows98,why?
|
|
|
|
|
Because in Windows NT 4, Windows 98 and Windows 95 we can only choose ICMP and IGMP protocols, when we are creating RAW_SOCKET. When we are using other protocols like UDP, TCP, IP we have to include IP_HDRINCLUDE that is available since win2k
Oglodek, Michal
|
|
|
|
|
I am just playing around with this raw socket class and I am trying to figure out how to decode the bytes recieved into Text. Is this possible?
I have been trying to use,
System.Text.Encoding.ASCII.GetString(e.MessageBuffer, 0, (int)e.MessageLength);
but this only gives my junk.
Any ideas?
|
|
|
|
|
I'm having the very same problem. Did you find a solution? In fact I'm in search for a method to capture every URL the user is browsing...
|
|
|
|
|
Not all packet data is ASCII text. In fact, the data's meaning is only useful if you know how to interpret it. For example, each byte of the packet data is 8 bits. How you interpret those 8 bits (signed, unsigned, bitfield, ASCII character, etc.) is a matter of knowing what you are looking at. If you are filtering specific packets (e.g. DNS, DHCP), try looking at the RFCs to detrmine the packet layouts.
In addition, not all bytes are meaningful on their own. Often, a series of bytes in a packet will need to be "reassembled" to form a DWORD (32-bit) or WORD (16-bit) value...
|
|
|
|
|
If it's a TCP type packet, the first 20 bytes of message buffer are the TCP header.
Byte layout follows
0-1 = Source Port
2-3 = Dest port
4-7 = sequence numb.
8-11 = ack numb.
12 = dataoffset ( upper 4 bits only )
13 = flags ( 0x01 = fin , 0x10 = ack, etc etc etc )
14-15 short
16-17 short
18-19 short
Don't recall off the top of my head what the last 3 shorts were for, but just do a google and you'll find a document that describes this in much more detail. This should be enough to at least get your pointed in the correct direction.
|
|
|
|
|
To see examples of decoding see http://www.tamos.com/products/commview/
|
|
|
|
|
Hi,
I was testing this application with a small test I am doing. I have a client/server application using SQL Server 2000 to populate a table in a client.
I use netstat to count the number of packets. Netstat reports 65 packets, when I use this program I get 10 .. and the funny thing is that the number of packets changes, it's not constant.
Any ideas what's going on?
P.S. The client is just a DataReader retrieving data from an SQL Server. Nothing fancy about it.
|
|
|
|
|
How hard would it be to convert or use the RawSocket class to perform network address translation? It seems that I could set the IP binding for receiving to the 'Local Network Address' and then set up a sending IP. Then for each packet coming in to the receiving IP if it is destined for an external subnet, it will forward the packet on to the 'sending IP'.
Does this make sense or have I lost my mind?
David
|
|
|
|
|
Have the same problem, as target i see only local router.
|
|
|
|
|
could you please explain in your own words what this does, i understand everything but this one section.
string IPString="10.10.10.10";
IPHostEntry HosyEntry = Dns.Resolve(Dns.GetHostName());
if(HosyEntry.AddressList.Length > 0)
{
foreach(IPAddress ip in HosyEntry.AddressList)
{
IPString=ip.ToString();
}
}
Thankyou for making sutch a simple example, but why the lack of comments?
Grizz
|
|
|
|
|
It has been a while, but it looks like it does this:
1. Sets the string IPString to a initial value of "10.10.10.10"
2. Finds all IP addresses on your machine as a list. (like 192.168.0.1,192.168.0.2....)
3. It keeps assigning the next IP address to that string IPString so that the very last value of IPString is the last IP Address of your machine....in this example that I have given IPString would equal 102.168.0.2 after the loop is done.
Grizz, I just don't like adding confusing comments when the code is easier for me to read without them. OK?
|
|
|
|
|
Hi
I am working on something similar, but trying to send UDP packets out rather than back in.
I do it as follows -
<br />
Socket sender=new Socket(AddressFamily.InterNetwork,SocketType.Raw,ProtocolType.Raw);<br />
sender.SetSocketOption(SocketOptionLevel.IP,SocketOptionName.HeaderIncluded,1);<br />
sender.SetSocketOption(SocketOptionLevel.IP,SocketOptionName.MulticastInterface,(int)IPAddress.Parse(dest_ip).Address);<br />
sender.Connect(new IPEndPoint(IPAddress.Parse(mcast_addr),0));<br />
then I send the data out using
sender.Send(b,0,len,SocketFlags.None);
Where b is the buffer and is exactly the same as the incoming buffer used in the example in this article.
However, my output data seems to be a larger packet than my input data! Why is this????
Regards,
Gary
|
|
|
|
|
If you want to send 3 bytes of UDP data out to somewhere, then after UDP headers, etc. are added the total byte count will definitely be more than 3 bytes. There is some overhead added by the UDP protocol.
|
|
|
|
|
Anonymous wrote:
If you want to send 3 bytes of UDP data out to somewhere, then after UDP headers, etc. are added the total byte count will definitely be more than 3 bytes. There is some overhead added by the UDP protocol.
Why would there be UDP headers added to the message if I have HeaderIncluded set to true?
|
|
|
|
|
hi!
Anybody converted this great class or something similar to VB(.net)? if anybody has something pls mail me!
|
|
|
|
|
Hi,
I've tried to use your class to monitor my internet connection, i tried downloading a 808kb file but I don't seem to get it right, I end up reporting a size of 383kb.
I'm just adding the size of all incoming packets and I imagine the total length should at least be the size of the file.
Any idea? Have I got it totally wrong ? Or maybe that class should be used for that?
Thanks for your help.
|
|
|
|
|
I created a test program and found the same results. My totals were about half of what they should have been.
I think the packet sniffer is reporting the correct byte count on what it receives, but that it is only receiving about half the packets. The packet sniffer, since it is running on the same machine as the app that is really receiving the packets, is not in sync with the incoming data. I think if you put your sniffer on a fast machine on the same hub (not a switch) so it can listen to all incoming traffic and can easily keep up, it will count the proper number of incoming bytes.
Problems occur when you are sniffing data coming to the same machine.
Let me know if anyone can prove the above. My network is on switches now and I can only receive broadcast traffic on my sniffer.
Lyle.
|
|
|
|
|
Thanks for the details Lyle.
I've notice something I found weird myself, the longest packet length I ever received was 1480, when I download that file I had almost only packets with 1480 bytes. Is that normal, I mean I would expect something more like 4096 bytes/packet.
What do you think ?
Pyt
|
|
|
|
|
The packet length on my machine was the same (1480.) I assumed that was normal (the packet sniffer doesn't control that.) I would have to check out a tcpip book to see what controls the packet length.
Lyle.
|
|
|
|