[求助]linux收到Broadcast的Gratuitous ARP Request后是否更新arp table？

Caivi

最近遇到一个DHCP的问题，大概情况描述一下：
linux kernel：2.6.18，ARM平台，运行了udhcpd作为DHCP Server

1.
首先在switch port接入CPE1(MAC1)，CPE1拿到IP1: MAC1 <--> IP1(192.168.0.10);
然后接入CPE2(MAC2)，CPE2拿到IP2：MAC2 <--> IP2(192.168.0.11)。
linux的arp表是：
MAC1 <--> IP1(192.168.0.10)
MAC2 <--> IP2(192.168.0.11)

2.
然后拔掉CPE1的网线，CPE2还连着，reboot

3.
之后CPE2拿到IP1，也就是MAC2 <--> IP1(192.168.0.10), 即现在MAC2拿到的ip是先前MAC1拿到的ip
此时linux的arp表是：
MAC2 <--> IP1(192.168.0.10)
然后再接上CPE1，则理论上他应该是先去DHCP request 他以前拿到过的IP1，然后DHCP Server会回给CPE1 NAK，这样CPE1再重新去discover。

4.
我遇到的问题是CPE1此时没有收到这个NAK，当他发送3个request没收到server的任何回应后，就会发送broadcast的Gratuitous ARP request去检测这个IP是否冲突了，此时CPE2会回给CPE1一个Gratuitous ARP replay，说这个IP我在用了，然后CPE1会继续去discover重新拿IP，并且拿到了IP2
此时，理论上的期望是：
MAC2 <--> IP1(192.168.0.10)
MAC1 <--> IP2(192.168.0.11)

5.
但实际并非如此，实际的linux arp表变成了：
MAC1 <--> IP1(192.168.0.10)
MAC1 <--> IP2(192.168.0.11)

也就是MAC2的那条记录被那个broadcast的Gratuitous ARP request给毁掉了，然后linux记录了这条错误的arp信息，即由MAC2 <--> IP1(192.168.0.10)变成了MAC1 <--> IP1(192.168.0.10)
后面第4步CPE1是正确的记录到ARP 表了。

我想问的是，当linux收到Broadcast的Gratuitous ARP request时，到底是忽略这个请求，还是更新自己的arp table？
我这台linux似乎是选择了更新自己的arp table，但这明显是不对的，因为Gratuitous ARP request本身并不一定是正确的。