ARP+ICMP请求和回复信息.docx
- 文档编号:6089327
- 上传时间:2023-01-03
- 格式:DOCX
- 页数:15
- 大小:107.91KB
ARP+ICMP请求和回复信息.docx
《ARP+ICMP请求和回复信息.docx》由会员分享,可在线阅读,更多相关《ARP+ICMP请求和回复信息.docx(15页珍藏版)》请在冰豆网上搜索。
ARP+ICMP请求和回复信息
下图是ping装置时抓图工具显示的提示信息:
电脑:
MAC:
00:
25:
11:
6f:
7b:
16IP:
192.168.2.30
装置:
MAC:
ac:
de:
48:
00:
00:
80IP:
192.168.2.5
图1
图1显示先是ARP广播,然后电脑收到了ARP回复(信息如图2),之后电脑又发ICMP命令请求(信息如图3),但没有收到回复,ping不通。
图2
图2是ARP回复的信息,从上图可以看到ARPFramechecksequence不对,但ARP回复(reply)信息的MAC地址和IP地址都是正确的
图3
图3是电脑的ICMP请求信息,从图3来看 请求信息正常,校验也正确,但就是收不到回复
ARP报文被封装在以太网帧头部中传输,如图所示,是ARP请求协议报文头部格式。
>上图中粗体的部分是以太网(这里是EthernetII类型)的帧头部。
其中:
第一个字段是广播类型的MAC地址:
0XFF-FF-FF-FF-FF-FF,其目标是网络上的所有主机。
第二个字段是源MAC地址,即请求地址解析的主机MAC地址。
第三个字段是协议类型,这里用0X0806代表封装的上层协议是ARP协议。
最后一个字段FCS,是4个字节的帧校验序列(FrameCheckSequence,FCS),采用32位CRC循环冗余校验对从"目标MAC地址"字段到"数据"字段的数据进行校验。
接下来是ARP协议报文部分。
其中各个字段的含义如下:
硬件类型:
表明ARP实现在何种类型的网络上。
协议类型:
代表解析协议(上层协议)。
这里,一般是0800,即IP。
硬件地址长度:
MAC地址长度,此处为6个字节。
协议地址长度:
IP地址长度,此处为4个字节。
操作类型:
代表ARP数据包类型。
0表示ARP请求数据包,1表示ARP应答数据包。
源MAC地址:
发送端MAC地址。
源IP地址:
代表发送端协议地址(IP地址)。
目标MAC地址:
目的端MAC地址(待填充)。
目标IP地址:
代表目的端协议地址(IP地址)。
ARP应答协议报文和ARP请求协议报文类似。
不同的是,此时,以太网帧头部的目标MAC地址为发送ARP地址解析请求的主机的MAC地址,而源MAC地址为被解析的主机的MAC地址。
同时,操作类型字段为1,表示ARP应答数据包,目标MAC地址字段被填充以目标MAC地址。
////////////////////////////////////////////////////////////////////////////////
我也不知道怎么搞得,奇怪了,我的8019驱动为什么能收ARP,UDP包,却收不到ICMP和TCP包!
!
ARP已经通了,而中断对icmp(ping)和tcp(telnet)却不理?
?
我是用Ethereal抓的包。
各位碰到没有,帮我想想问题出在那儿了!
!
多谢!
!
同样是数据包,差距咋这么大呢!
!
即然能正确接收ARPUDP包,说明我的8019驱动应该是好的吧?
怎么会有这种问题?
?
?
ping172.16.4.15 这个ip不存在,发4个ARP包,都能接收并处理;
ping17727 17727当作主机名,发3个NBNS包,nbns是udp,能收到;
ping172.16.4.18 8019的ip,发4个ICMP包,网卡根本不中断;
telnet172.16.4.187 发3个TCP包,没反应:
(
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
兄弟们帮忙分析一下,想不通啊!
!
多谢
答2:
把驱动源代码贴出,这样才好帮你改,这样说鬼知道是什么问题
答3:
应该是软件问题,好好找找。
答4:
是skyeye杨晔的驱动驱动太长了,能把人看晕的
下面是8019中断的代码,我就在这里设断点,ARPUCP包能中断,而icmp和tcp就停不下来。
?
?
?
?
void__irq ne2k_isr(void)
{
u8_t isr,curr,bnry;
structnetif*netif;
rI_ISPC=BIT_EINT1;
//closenic
//********************addbymaokorfordebug,2005.6.17*******
outb(CMD_PAGE2|CMD_NODMA|CMD_STOP,NE_CR);
isr=inb(NE_IMR);
//*****************************************************888888
//inPAGE0
outb(CMD_PAGE0|CMD_NODMA|CMD_STOP,NE_CR);
isr=inb(NE_ISR);
//ramoverflowinterrupt
if(isr&ISR_OVW){
outb(ISR_OVW,NE_ISR); //clearinterrupt
// ne2k_overflowProcess(); //yangye:
nooverflownow
}
//errortransferinterrupt,NICaborttxduetoexcessivecollisions
if(isr&ISR_TXE){
outb(ISR_TXE,NE_ISR); //clearinterrupt
//temporarilydonothing
}
//Rxerror,resetBNRYpointertoCURR(useSENDPACKETmode)
if(isr&ISR_RXE){
outb(ISR_RXE,NE_ISR); //clearinterrupt
outb(CMD_PAGE1|CMD_NODMA|CMD_STOP,NE_CR);
curr=inb(NE_CURR);
outb(CMD_PAGE0|CMD_NODMA|CMD_STOP,NE_CR);
outb(curr,NE_BNRY);
}
//gotpacketwithnoerrors
if(isr&ISR_PRX){
outb(ISR_PRX,NE_ISR); //clearinterrupt
outb(CMD_PAGE1|CMD_NODMA|CMD_STOP,NE_CR);
curr = inb(NE_CURR);
outb(CMD_PAGE0|CMD_NODMA|CMD_STOP,NE_CR);
bnry=inb(NE_BNRY);
//yangye2003-1-21
//getmorethanonepacketuntilreceivebufferisempty
while(curr!
=bnry){
ne2k_recv_packet(rtl8019if_netif);
outb(CMD_PAGE1|CMD_NODMA|CMD_STOP,NE_CR);
curr= inb(NE_CURR);
outb(CMD_PAGE0|CMD_NODMA|CMD_STOP,NE_CR);
bnry= inb(NE_BNRY);
}
}
//Transfercomplelte,donothinghere
if(isr&ISR_PTX){
PRINT("ne2k_isr:
isISR_PTX\n");
outb(ISR_PTX,NE_ISR); //clearinterrupt
}
outb(CMD_PAGE0|CMD_NODMA|CMD_STOP,NE_CR);
outb(0xff,NE_ISR); //clearISR
//opennicfornextpacket
outb(CMD_PAGE0|CMD_NODMA|CMD_RUN,NE_CR);
}
答5:
8019有bug,千万要注意可以参考linux下的驱动,那个是修正bug的,千万不要用没有经过实践验证的代码。
答6:
啊!
多谢各位回复!
wangkj:
8019有bug?
能具体说说吗,skyeye的驱动好像也有人移植成功过!
答7:
可能是mac地址不对我对比了一下,发现这几种包的区别是目的mac不同,arp是广播的就能受到。
难道是网卡的mac设置不对?
8019发送的arp回复包中的mac地址是直接读寄存器的还是程序设置的?
怎么会错呢?
我把arp包贴出来,兄弟们帮我分析一下,另外这个包有校验错误(incorrect,shouldbe0xaf8108fa)不知哪里错了?
No. Time Source Destination ProtocolInfo
651436.86735325:
01:
00:
ea:
5d:
00 172.16.4.10 ARP 172.16.4.18isat25:
01:
00:
ea:
5d:
00
Frame65(64bytesonwire,64bytescaptured)
EthernetII,Src:
25:
01:
00:
ea:
5d:
00,Dst:
00:
05:
5d:
02:
14:
db
Destination:
00:
05:
5d:
02:
14:
db(172.16.4.10)
Source:
25:
01:
00:
ea:
5d:
00(25:
01:
00:
ea:
5d:
00)
Type:
ARP(0x0806)
Trailer:
000000000000000000000000000000000000
Framechecksequence:
0xc4be25b7(incorrect,shouldbe0xaf8108fa)
AddressResolutionProtocol(reply)
Hardwaretype:
Ethernet(0x0001)
Protocoltype:
IP(0x0800)
Hardwaresize:
6
Protocolsize:
4
Opcode:
reply(0x0002)
SenderMACaddress:
25:
01:
00:
ea:
5d:
00(25:
01:
00:
ea:
5d:
00)
SenderIPaddress:
172.16.4.18(172.16.4.18)
TargetMACaddress:
00:
05:
5d:
02:
14:
db(172.16.4.10)
TargetIPaddress:
172.16.4.10(172.16.4.10)
答8:
发现mac地址没有正确保存,才错误发现个问题,帮我看看!
structRTL8019if{
structeth_addr*ethaddr;
};
packedstructeth_addr{
u8_taddr[6];
}PACK_STRUCT_STRUCT;
staticvoid
low_level_init(structnetif*netif)
{
u8_ti,isr;
structRTL8019if*rtl8019if,rtl8019;
u8_tmac_addr[6];
mac_addr[0]=inb(NE_PAR0);
mac_addr[1]=inb(NE_PAR1);
mac_addr[2]=inb(NE_PAR2);
mac_addr[3]=inb(NE_PAR3);
mac_addr[4]=inb(NE_PAR4);
mac_addr[5]=inb(NE_PAR5);
/*makeupanaddress.*/
rtl8019if->ethaddr->addr[0]=mac_addr[0];
rtl8019if->ethaddr->addr[1]=mac_addr[1];
rtl8019if->ethaddr->addr[2]=mac_addr[2];
rtl8019if->ethaddr->addr[3]=mac_addr[3];
rtl8019if->ethaddr->addr[4]=mac_addr[4];
rtl8019if->ethaddr->addr[5]=mac_addr[5];
rtl8019=*rtl8019if;
mac_addr数组读值正确,但是赋值给rtl8019if->ethaddr->addr时没有成功,sdt中查看变量rtl8019值,只能看到->ethaddr是0x00000000。
是数据结构packed的问题吗?
多谢!
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
这时候的网络充满了ARP请求数据和ARP响应数据,这些数据占用了很大的网络带宽,降低了网络的流量和利用率,不管你是通过Capture获取数据的方式来分析或者利用EtherPeekNX的协议类型数据分析或者流量分析都可以看出。
接下来就进行NetRobocop的限制权限功能,看看它到底是怎样限制网络上用户的连网的。
在计算机C上对计算机B进行限制,禁止它和其它主机相连。
这时候查看计算机A和计算机B的ARP缓存表可以看出来它把各自计算机的ARP缓存表中计算机A和计算机B的MAC地址(下面框出来的部分)给换掉了。
计算机A上C:
\WINDOWS\Desktop>arp-a
Interface:
192.168.11.1onInterface0x1000002
InternetAddressPhysicalAddressType
192.168.11.200-e0-4c-02-88-24dynamic
192.168.11.300-e0-4c-3c-05-20dynamic
计算机B上C:
\WINDOWS\Desktop>arp-a
Interface:
192.168.11.2onInterface0x1000002
InternetAddressPhysicalAddressType
192.168.11.100-e0-4c-05-77-76dynamic
192.168.11.300-e0-4c-3c-05-20dynamic
其实这就是一个ARP欺骗。
这时候如果计算机B有发送到IP为192.168.11.1的计算机A的数据通过查找ARP缓存表就转换成其它的MAC地址,数据到达计算机A后它通过对照MAC地址,发现不是自己的MAC地址就丢弃这个数据,计算机A就收不到计算机B发来的数据,也就是计算机B不能连通计算机A。
但是计算机C为了还能控制计算机B,它不修改自己的MAC地址,保持着和计算机B的通信。
实现这个ARP欺骗的过程通过EtherPeekNX的数据截取和分析可以看出它采用的也是ARP响应数据。
ARP协议并不只在发送了ARP请求数据才接收ARP响应数据。
当计算机接收到ARP响应数据的时候,就会对本地的ARP缓存表进行更新,将ARP响应中的IP地址和MAC地址存储在ARP缓存表中。
这个ARP欺骗的ARP响应数据其实就是计算机C借用了计算机A的IP地址向计算机B发送了一个随机伪造的MAC地址,它的数据包如下:
Flags:
0x00
Status:
0x00
PacketLength:
64
Timestamp:
11:
04:
08.31800009/25/2003
EthernetHeader
Destination:
00:
E0:
4C:
3B:
F0:
46
Source:
00:
E0:
4C:
05:
77:
76/伪造的MAC地址
ProtocolType:
0x0806IPARP
ARP-AddressResolutionProtocol
Hardware:
1Ethernet(10Mb)
Protocol:
0x0800IP
HardwareAddressLength:
6
ProtocolAddressLength:
4
Operation:
2ARPResponse
SenderHardwareAddress:
00:
E0:
4C:
05:
77:
76/伪造的MAC地址
SenderInternetAddress:
192.168.11.1/伪造的计算机A的IP地址
TargetHardwareAddress:
00:
E0:
4C:
3B:
F0:
46
TargetInternetAddress:
192.168.11.2
Extrabytes
Numberofbytes:
20202020202020202020202020202020
2020
FCS-FrameCheckSequence
FCS(Calculated):
0xC3277168
ARP缓存表是动态更新的,如果只发送一个这样的带ARP欺骗的ARP响应数据,在经过一段时候没有通信后它就会从ARP缓存表中删除,下次再有连接的话就再进行ARP请求和ARP响应,更新成正确的MAC地址。
为了防止ARP缓存更新,NetRobocop在一直不停地给计算机B发送这个带ARP欺骗的ARP响应数据。
同时它也一直不停的向计算机A发送带ARP欺骗的ARP响应数据,这样就可以完全阻止计算机A和计算机B的双方的通信。
如果发送方和接收方的IP地址一样会怎样呢?
也就是我们经常见到的IP地址冲突警告,NetRobocop就是利用它来产生IP地址冲突的。
计算机C发给计算机A的IP冲突的ARP响应数据如下:
Flags:
0x00
Status:
0x01
PacketLength:
64
Timestamp:
11:
06:
29.84100009/25/2003
EthernetHeader
Destination:
00:
E0:
4C:
3C:
0F:
14
Source:
00:
E0:
4C:
78:
84:
6B/伪造的MAC地址
ProtocolType:
0x0806IPARP
ARP-AddressResolutionProtocol
Hardware:
1Ethernet(10Mb)
Protocol:
0x0800IP
HardwareAddressLength:
6
ProtocolAddressLength:
4
Operation:
2ARPResponse
SenderHardwareAddress:
00:
E0:
4C:
78:
84:
6B/伪造的MAC地址
SenderInternetAddress:
192.168.11.1/伪造的和接收方相同的IP地址
TargetHardwareAddress:
00:
E0:
4C:
3C:
0F:
14
TargetInternetAddress:
192.168.11.1
Extrabytes
Numberofbytes:
................00000000000000000000000000000000
..0000
FCS-FrameCheckSequence
FCS(Calculated):
0xFE9194DA
这样,计算机A在收到这个带IP冲突的ARP响应数据后,网卡在检测到发送方和接收方使用了相同的IP地址,就会产生一个IP地址冲突中断,CPU接收中断后就弹出一个警告窗口。
这个带IP冲突的ARP响应数据也是在一直不停地发送的,所以计算机A就一直收到这个IP冲突警告。
五、EtherPeekNX对NetRobocop的解决方法
通过对NetRobocop数据的截取和分析,了解了NetRobocop这个网络软件的基本原理。
一旦这个软件被非法使用,某些用户可能被非法限制权限后就很难摆脱它的控制,而且它是利用网络的底层功能ARP欺骗来实现控制,没有什么现成的工具和软件来阻止这种限制,除非它对你取消限制权限才有可能正常连网使用。
那我们对这种限制是否就束手无策了呢?
答案当然是否定的,其实我们可以用NetRobocop的ARP欺骗原理来进行反击,摆脱它的控制,保持网络的正常状态。
当然在这种情况下,网络上就会充满了这些ARP的数据包,占用很大的网络流量,影响正常的网络使用。
使用的方法可以这样来实现,因为一旦受到NetRobocop的限制,你已经没办法和其他计算机进行通信,但控制你的那台计算机还可以和你通信,我们就是利用它的这个线索找到控制你的计算机,通过EtherPeekNX的Capture功能就可以发现,找出它的IP地址和MAC地址,然后通过EtherPeekNX的发送数据功能给它也发送带ARP欺骗的ARP响应数据,让它断开和其他计算机的连接,从而摆脱它的控制。
六、结束语
如EtherPeekNX和NetRobocop这些网络工具可以被网管人员用于加强安全性
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ARP ICMP 请求 回复 信息
![提示](https://static.bdocx.com/images/bang_tan.gif)