ARP回复包含错误的MAC地址

当你在同一个networking上有两个接口时，你所看到的是正常行为。 它在这个LWN文章中被描述。

当你说你得到一个错误的接口的ARP响应，你实际上是倾销stream量或只是看看产生的ARP表？ 有可能你得到两个接口的ARP答复…

无论如何，我相信你的问题的答案在于正确操纵rp_filter和arp_filter 。 每个文档都包含在下面。

我build议先尝试一下：

 echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter 

您可能还需要进行此更改：

 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter 

 rp_filter  - 布尔值
     1  - 按照RFC1812的规定，通过反向path进行源validation
        推荐select单宿主机和存根networking
        路由器。 可能会造成麻烦复杂（不循环）
        运行缓慢不可靠协议的networking（RIP的种类），
        或者使用静态路由。

     0  - 没有源validation。

     conf / all / rp_filter也必须设置为TRUE来执行源validation
    在界面上

    默认值是0.请注意，一些分布启用它
    在启动脚本。

 arp_filter  - 布尔值
     1  - 允许您有相同的多个networking接口
    子网，并且每个接口的ARP都被回答
    根据内核是否将路由一个数据包
     ARP的IP出该接口（因此你必须使用源
    为此工作）。 换句话说，它允许控制
    哪些卡（通常是1）会响应一个ARP请求。

     0  - （默认）内核可以用地址响应arp请求
    从其他界面。 这看起来可能不对，但通常是这样做的
    意义，因为它增加了成功沟通的机会。
     IP地址由Linux上的完整主机拥有，而不是由
    特定的接口。 只有更复杂的设置，
    平衡，这种行为是否会导致问题。

    如果至less有一个，接口的arp_filter将被启用
     conf / {all，interface} / arp_filter设置为TRUE，
    否则将被禁用

有关更彻底的治疗，请参阅此文章：

http://www.embedded-bits.co.uk/tag/rp_filter/

我知道这是一个老问题，但我最近遇到了一个embedded式设备完全相同的情况。 该设备同时具有以太网和WiFi接口，并且要求两个接口在任何时候都可以处于活动状态并处于同一networking中，但是networking通信必须通过“首选”接口进行路由。

大多数用户不会这样configuration设备，但理论上应该是可能的。

我们首先拿起Netgear路由器的问题，因为他们会报告IP地址冲突 – 2个MAC地址共享一个IP。 显然，路由器会在这种情况下开始performance糟糕，并搞乱了用户networking。

我创build了一个只包含路由器（以太网+ wifi），windows笔记本电脑（仅以太网）和embedded式设备（以太网+ wifi）的专用networking。 使用wireshark，设备上的tcpdump和窗口上的arp我可以看到以下行为：

1. 设备上的Ifconfig显示不同的wln和以太网IP和不同的MAC地址
2. 有时（很less）和窗口中的arp -a显示正确的IP-MAC组合。
3. 大多数情况下，从窗口arp -a显示wln和eth0都具有相同的MAC地址
4. 从Windows ping任一wln或eth0时，ping响应来自wln，很less来自eth0。 tcpdump显示wln只响应四个ping中的一个（例如）
5. 当Windows发送一个arp“谁有”eth0 IP消息 – eth0和wln接口都会回应说他们有这个IP

我相信项目3是由项目5引起的。因为wln正在响应只有eth0应该响应的arp消息，所以arp表正在混乱。 我相信项目4也是由项目5引起的。Ping是基于MAC地址发送的，并且自从收到的最后一个arp消息是来自wln说它具有eth0 IP，ping被错误地路由到wln接口。

经过大量的挖掘和testing，解决scheme其实非常简单。 看到这篇文章 – http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Linux内核networking驱动程序的configuration方式是：当接收到一个已知接口的arp请求时（即使它在另一个接口上接收到），它将响应arp。

这个设置解决了这个问题：

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

说明：

 arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 

由于这个版本的操作系统（基于openembedded）的工作正常，我的解决scheme是等待下一个版本的操作系统。 我最好的猜测是无线内核模块是越野车。

跟随Insyte的评论。

让我们做一些命名：

• PC1 – 右上angular
• PC2 – 左上angular
• PC3 – 左下angular

您可以通过有线和无线媒体从3台电脑上联系您的机器人。 而且他们在同一个子网上，你不能确定你的有线媒体的ARP请求是通过哪种方式。 由此我的意思是当交换机广播一个ARP请求时，你的机器人在两个接口上都会收到它[因为你的图表]，所以它接收到无线介质上的有线介质上的IP的ARP请求，它回复了无线媒体的物理地址，因为这个盒子里有IP地址

过去我曾经遇到过这个问题，这跟你的不一样，但是很相似。 默认情况下，linux回复接口的物理地址，它接收到arp请求，而不pipeIPconfiguration到哪个接口。 所以在你的情况下直接连接PC3到机器人的eth0接口，并做一个192.168.0.101的ARP请求，它会回应你的eth0接口的物理地址，而不是ra0。

我的部署scheme是：

[RTR] | ———— eth0 — [server]
| ——– | switch1 | —– eth1 —– [服务器]

它是两个接口连接的同一个交换机。 希望它能帮助你。

路由器在其接口上为服务器的两个不同接口上的两个不同networkingconfiguration了主IP地址和辅助IP地址。 但是，在eth1上接收eth0的IP地址的arp请求，它回复了eth1的物理地址

为了防止它到目前为止我工作

 # echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce # echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore # echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce # echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore 

把它放在你的机器人的某个地方，这样你就可以在启动时使用它。

build议：我build议你configuration两个不同的子网（比如ra0上的192.168.1.x / 24和eth0上的192.168.2.x / 24），你可以在你的电脑上使用IP别名，你的机器人可以通过任何的两个知识产权。 同一主机上的同一子网不能有两个出站path。 除非有什么东西让你的机器人比另一个更喜欢它。 您的机器人只能采取一条path发送数据包。

一些读数： arp_announce ， arp_ignore

我认为你的无线AP和你的交换机之间有一个configuration错误。 交换机和AP正混淆发送数据包的位置。 不知道这个。 另外，我想你应该尝试定义一个网关，程序可以知道在哪里发送数据包。 就像是

route add default gw 192.168.0.1