一般情况下 IP冲突后,操作系统怎么处理IP初始化的问题
包括后初始化的 和已经初始化OK的

今天做了实验 同事的一个redhat 想抢谁的IP 就抢的谁的 呵呵
搞的大家很郁闷 我的XP就不行了 冲不下来

好问题，不同操作系统的处理流称肯定不一样，我就想知道VISTA是如何处理的，但是找了很久没找到相关的介绍资料啊。
希望有高手能提供各个系统在处理此问题时的流程～～

那个，初学的来猜测一下，说错了别打脸
  protocol 的初始化和interface的初始化是2回事吧？

  比如系统启动时，协议栈初始化后，ifup eth0，这时候发送个arp广播出去，问问
谁用了这个ip地址了啊？如果没收到答复，那interface就设置完毕可用了

  如果收到arp答复，有人告诉说，我用了这个ip地址了，那系统就会输出一个类似
  duplicate ip address 什么的提示，但这个是不会影响协议栈工作的，比如
  ping 127.0.0.1是正常的，说明icmp，ip协议都好使

引用:

原帖由 chinit 于 2008-5-23 16:28 发表
那个，初学的来猜测一下，说错了别打脸
  protocol 的初始化和interface的初始化是2回事吧？

  比如系统启动时，协议栈初始化后，ifup eth0，这时候发送个arp广播出去，问问
谁用了这个ip地址了啊？如果没收到 ...

感谢兄弟回复，但是，不同的系统在收到这个针对免费ARP的回应时，处理的方式肯定不太一样。
例如，xp系统会提示地址冲突，但是vista不会提示，并将自己的地址变成了169。x。x。x的一个地址，关于系统的针对该问题的处理能否说详细点呢？

从实际观察来看，XP设定了地址或DHCP以后，会发三个Gracious ARP Request，即request IP 和requested IP是一样的
如果有其他人报告使用，XP会放弃自己的IP地址。
所以XP比较礼让，而Linux比较野蛮

vista 与 xp系统启动时发送免费ARP数据包的区别
VISTA 系统发送的免费ARP请求包格式为:
源MAC              目的MAC             源IP           目的IP
自己MAC地址  FF:FF:FF:FF       0.0.0.0         自己的IP

XP系统中发送的免费ARP请求包格式为:
源MAC              目的MAC             源IP           目的IP
自己MAC地址  FF:FF:FF:FF       自己的IP         自己的IP

不知道VISTA系统在设计时是基于什么考虑将免费ARP的数据包格式改了？这种格式的改动是否会影响网络中的其他设备对该免费ARP的处理呢？

正常的arp解析过程：
广播请求，单播回应。
系统启机等情况时，由于本来就不可知其IP是否可用，因此构造了免费arp这种特殊报文，具体特征为：sender和target为同一ip，target mac为自己的mac。
此时，其他设备发现上述特征匹配时，自然需要回应，但有一个问题，其他系统如何到底验证了什么认为这是一个免费arp呢？是验证sender和target为同一ip，还是target mac非全0？还是target mac必须和sendmac相同？还是交叉匹配……

这些规则，从协议上来说，当然是希望，匹配send ip、target ip相同的；sendmac target mac相同的报文，才走免费arp的处理流程。

然而，不同OS，其处理流程，却未必按照协议来做，参考vista系统，那么可以知道windows肯定只匹配了target mac是否全0。
另外我们知道wireshark能够解析arp是否Gracious的，因此试验了一下，wireshark对于要求send ip、target ip相同，target mac非全0，即认为是Gracious的，而没有继续匹配sendmac target mac还要相同。

其实，这又一次体现微软是多么的霸道，经常不按照标准出牌，谁让我市场占有率第一呢？

PS：突然想到，对于Gracious arp的回应，send ip、target ip也是相同的，而sendmac target mac不同，因此要匹配Gracious arp仅仅匹配IP是不够的，微软干脆放弃IP匹配的做法，还是说的过去的！

[ 本帖最后由 lvfengg 于 2008-5-24 11:07 编辑 ]

额，这个“其他系统”不用判断这个是否是 gratuitous arp 吧？

他只要知道，这个arp包里的sender protocol address和自己某接口配置的
ip地址是一样的，而且这个数据包确实是个arp request，就准备发送arp reply了

扫了一眼freebsd6.2，里边是这么判断的
ms的系统会把简单的事情复杂化吗？哪位熟悉来解释解释啊

引用:

原帖由 孤独的意尹者 于 2008-5-23 18:01 发表
vista 与 xp系统启动时发送免费ARP数据包的区别
VISTA 系统发送的免费ARP请求包格式为:
源MAC              目的MAC             源IP           目的IP
自己MAC地址  FF:FF:FF:FF       0.0.0.0         自己的I ...

A机－B机两台xp对联测试：
1）按照xp的arp包格式（源ip＝目的ip＝a机ip），用sniffer伪造arp包向b机发包，b机不断提示ip冲突；
2）按照vista的arp包格式（源ip＝0.0.0.0），用sniffer伪造arp包向b机发包，b机不提示。
这就是最明显的区别，看来vista比xp还谦虚，它不仅让出ip，而且还不让对方发现有ip冲突，宁可牺牲自己 哈哈。

免费ARP(Gratuitous ARP)
主机发送ARP请求查找自己的IP地址。通常发生在系统引导期间进行接口配置的时候。
(1)检查IP地址是否可用，是否和别人冲突
(2)刷新ARP Cache

需要注意的是并不是所有的OS都支持在接口配置期间发送免费ARP
我猜测RedHat Linux就不做这个处理。

另：Vista的ARP报文似乎不符合ARP请求的规范。所以不能算做免费的ARP。

需要注意的是并不是所有的OS都支持在接口配置期间发送免费ARP
我猜测RedHat Linux就不做这个处理。

------------------------------------------------------------------------------------------
有这个过程的  曾经记得某个用LINUX做的防火墙 忘记了管理的IP
然后就通过这个办法把IP给抓出来的

哦  看了大家的回答长见识啊

vista 与 xp系统启动时发送免费ARP数据包的区别
VISTA 系统发送的免费ARP请求包格式为:
源MAC              目的MAC             源IP           目的IP
自己MAC地址  FF:FF:FF:FF       0.0.0.0         自己的IP

XP系统中发送的免费ARP请求包格式为:
源MAC              目的MAC             源IP           目的IP
自己MAC地址  FF:FF:FF:FF       自己的IP         自己的IP



看了上面各位大虾的观点受益非浅,一般遇到这种问题时候都是计算机重新配置IP地址或者重起计算机的时候,XP发送ARP数据包的格式会造成正在使用这个IP地址的计算机提示:IP地址冲突的提示,但是并不影响本机的使用,而发送这个数据包的计算机收到有人已经使用了这个地址后就配置不上这个IP了.但是毕竟会让用这个IP地址的计算机不断弹出提示消息,也影响正常工作.
而VISITA的数据包格式我认为更合理,他不会让使用这个IP的计算机有任何影响,只是自己的桌面提示有冲突(这个是猜测,没有证实,请网友证实),而且自己也配置不上这个IP,从而不影响别人的正常工作.
所以我认为微软的设计是合理的,毕竟使用其操作系统的人很多.不知道我这么认为对不!


至于REDHAT抢IP,我认为这是REDHAT本身缺陷,呵呵!因为REDHAT设置好IP以后就认为这个IP是自己的,不会发任何数据包(或者发一个回答数据包,说这个IP地址已经有人使用了)而在网络中的XP等系统会认为IP已经有人使用,从而自己用不了.
   上面这个解释我自己也是瞎猜的,不要笑话.
还有可能就是REDHAT在以太网中抢线能力比微软系统要快!请高手解释一下!

[ 本帖最后由 bdbanner 于 2008-6-4 17:27 编辑 ]

“而VISITA的数据包格式我认为更合理,他不会让使用这个IP的计算机有任何影响,只是自己的桌面提示有冲突(这个是猜测,没有证实,请网友证实)”
实验证实：vista机器自己也不弹出地址冲突提示，只是让其手动设置的网卡地址变为169段的一个地址。

高手很多啊……要好好吸收啊！

ok,check this~

ARP  is susceptible to a redirection attack when an attacker
sends  a  “gratuitous-ARP”  packet  (normally  used  to
propagate  address  changes)  to  a  target host  [Appendix  II].
After receiving such a packet, the target will forward future
packets  to  the  attacker’s  node  rather  than  the  intended
target.  We  observed  that  the  Windows  Vista  stack  will
accept  the  information  in  a  gratuitous ARP  packet  sent  to
the broadcast  link address or  to  the host’s  link address and
create  a new  entry  in  the host’s ARP  table or overwrite an
existing  entry.  When  an  existing  ARP  table  entry  is
overwritten, no warnings are displayed to the user or logged
in the system event log.  

When processing an ARP packet  that contains  the same  IP
address  as  the  host,  the Windows Vista  stack will  log  the
address  conflict  in  the  system  event  log  but  will  not
otherwise notify  the user of  the  conflict. After  logging  the
conflict,  the  Windows  Vista  networking  stack  marks  its
network  interface  as  having  a  conflict  and  stops  initiating
packets  from  that  interface,  effectively  rendering  the
interface  useless.  Oddly  enough,  pre-existing  connections
on  the  host  are  not  affected.  The  interface  remains  in  this
state until it is reset by reacquiring a DHCP lease.