无法使用原始套接字读取传入响应
我试图通过监听原始套接字通过代码读取网站的响应,尽管到目前为止我只能读取计算机发送的传出请求,而不是我真正感兴趣的传入响应。 我该如何阅读收到的回复?
编辑:我相信,使用 Wireshark 我发现我正在寻找的数据是通过 TCP 发送的。
Socket listener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Unspecified);
IPAddress localIP = Dns.GetHostByName(Dns.GetHostName()).AddressList[0];
listener.Bind(new IPEndPoint(localIP, 0));
byte[] invalue = new byte[4] { 1, 0, 0, 0 };
byte[] outvalue = new byte[4] { 1, 0, 0, 0 };
listener.IOControl(IOControlCode.ReceiveAll, invalue, outvalue);
while (true)
{
byte[] buffer = new byte[1000000];
int read = listener.Receive(buffer);
if (read >= 20)
{
Console.WriteLine("Packet from {0} to {1}, protocol {2}, size {3}",
new IPAddress((long)BitConverter.ToUInt32(buffer, 12)),
new IPAddress((long)BitConverter.ToUInt32(buffer, 16)),
buffer[9],
buffer[2] << 8 | buffer[3]
);
}
}
I am trying to read a response from a website via code by listening to a raw socket, though so far I've only been able to read the outgoing requests sent by my computer rather than the incoming responses that I'm actually interested in.
How might I go about reading the incoming responses?
EDIT: Using Wireshark I've come to find that the data I'm looking for is being sent via TCP, I believe.
Socket listener = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Unspecified);
IPAddress localIP = Dns.GetHostByName(Dns.GetHostName()).AddressList[0];
listener.Bind(new IPEndPoint(localIP, 0));
byte[] invalue = new byte[4] { 1, 0, 0, 0 };
byte[] outvalue = new byte[4] { 1, 0, 0, 0 };
listener.IOControl(IOControlCode.ReceiveAll, invalue, outvalue);
while (true)
{
byte[] buffer = new byte[1000000];
int read = listener.Receive(buffer);
if (read >= 20)
{
Console.WriteLine("Packet from {0} to {1}, protocol {2}, size {3}",
new IPAddress((long)BitConverter.ToUInt32(buffer, 12)),
new IPAddress((long)BitConverter.ToUInt32(buffer, 16)),
buffer[9],
buffer[2] << 8 | buffer[3]
);
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
端口 0 表示他将侦听所有端口,我认为您需要将 ProtocolType.Unspecified 设置为 ProtocolType.IP。
new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Raw);
从我在msdn上读到的内容来看,仅适用于ipv6。带有原始套接字的ipv4仅支持ProtocolType.IP。
我还认为这是一个无连接套接字,对吗?
除非情况确实如此,否则 Reciveall 不会真正产生影响。
如果您正在寻找 ip 标头,您可以通过设置如下代码来获取它:
希望这会有所帮助:)
port 0 says he will listen on all ports, i think you need to set ProtocolType.Unspecified to ProtocolType.IP instead.
new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Raw);
is for ipv6 from what i read on msdn only ProtocolType.IP is supported for ipv4 with raw sockets.
Also im thinking this is a connectionless socket right?
Reciveall wouldnt really have an affect unless thats the case.
if youre after the ip header u can get it by setting up the code like this:
hope this helps :)
我在使用基本相同的原始套接字设置的 C++ 程序中遇到了类似的问题。就我而言,我可以在调试版本中看到传入的数据包,但在发布版本中看不到。在两个版本中都可以看到传出数据包。我不会在此程序中发送任何数据包。
我正在 Win7 x64 下使用 VS2008 本机 C++ 进行构建。
我的问题出在防火墙上。当在 VS 中创建项目时,它显然在防火墙中放置了一个“允许”条目,以便项目构建进行网络访问,但仅限于程序的调试构建。
我必须为发布版本添加另一个条目,然后允许传入数据包。 Win7 下的高级防火墙设置也可能导致特定协议被阻止,因此,如果您仅收到部分传入消息,请检查程序条目的这些设置。
I had a similar problem in my C++ program using basically the same raw sockets setup. In my case I can see incoming packets in the debug build, but not in a release build. Outgoing packets are seen in both builds. I'm not sending any packets in this program.
I'm building with VS2008 native C++ under Win7 x64.
My issue was with the firewall. When the project was created in VS it apparently put an "Allow" entry in the firewall for network access by the project build, but only for the debug build of the program.
I had to add another entry for the release build and this then allowed incoming packets. The advance firewall settings under Win7 can also cause specific protocols to be blocked, so if you're getting only partial incoming messages check those settings for your program's entry.
今天我想知道如何做同样的事情!这是我的代码,现在似乎可以工作了,这个工作的功劳归功于其他回答者“Tom Erik”建议的 ProtocolType.IP。
Today I was wondering how to do the exact same thing! Here is my code which now seems to work, credit for getting this working is due to fellow answerer 'Tom Erik' for suggesting ProtocolType.IP.