ARP応答に間違ったMACアドレスが含まれています

有線および無線アダプターを備えたLinuxを実行しているロボットがあります。起動すると、ワイヤレスに正常に接続します。IPを（静的またはDHCPで）有線に割り当てると、動作しているように見えます。同様に、ifconfig適切なIPとroute適切なルートを示します。ただし、有線IPのARP要求を行うと、ARP応答にワイヤレスMACが含まれます。

??? ロボットで実行されているブリッジがないので、なぜ有線MACを取得しないのですか？

ワイヤーが切断されると、ワイヤードIPはpingに応答します...

ロボットが有線のIP要求にワイヤレスインターフェイス経由で応答するのはなぜですか？

編集：同じIPサブネット上の有線および無線アダプタの両方。同じIPサブネット上のコンピューター（異なるコンピューターで試行）からARP要求を実行します。

関連するifconfig出力：

eth0      Link encap:Ethernet  HWaddr 00:01:C0:04:BD:F7  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
ra0       Link encap:Ethernet  HWaddr 24:3C:20:06:3E:6D  
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:59 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31023598 (29.5 MiB)  TX bytes:85640627 (81.6 MiB)

関連するルート出力：

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ra0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

これは非常にカットダウンされたLinuxなので、artptables、iptables、sysctl、brctlなどのツールはありません。

編集：要求された図

編集：私はトラフィックをダンプし、ARPテーブルを見ています。192.168.0.110のARP要求は、24：3C：20：06：3E：6Dを含むARP応答を返します。ARP応答パケットの送信元MACも24：3C：20：06：3E：6Dです。ここで述べたように、_filter、_ignore、_announceをいじってみましたが、役に立ちませんでした。

編集：（どちらかのインターフェースで）ゲートウェイを設定しても違いはありません（そうすべきではありません）。

編集：これは以前のバージョンのOS（openembeddedに基づく）で正常に機能しました。彼らは何かを変えた可能性はありますか？

表示されているのは、同じネットワーク上に2つのインターフェイスがある場合の通常の動作です。このLWNの記事で説明されています。

間違ったインターフェイスに対してARP応答を受け取ったと言うとき、実際にトラフィックをダンプしているのですか、それとも結果のARPテーブルを見ているだけですか？両方のインターフェースに対してARP応答を受け取っている可能性があります...

とにかく、私は適切に操作するには、あなたの問題の嘘の答えを信じているrp_filterとarp_filter。それぞれのドキュメントは以下に含まれています。

最初にこれを試すことをお勧めします：

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

あなたは可能だけでなく、この変更を行う必要があります。

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

rp_filter-ブール値
    1-RFC1812で指定されているように、リバースパスによるソース検証を行います
        シングルホームホストおよびスタブネットワークの推奨オプション
        ルーター。複雑な（ループフリーではない）のトラブルを引き起こす可能性があります
        低速で信頼性の低いプロトコル（RIPの一種）を実行しているネットワーク、
        または静的ルートを使用します。

    0-ソース検証なし。

    ソース検証を行うには、conf / all / rp_filterもTRUEに設定する必要があります
    インターフェース上

    デフォルト値は0です。一部のディストリビューションでは有効になっていることに注意してください。
    起動スクリプト内。

arp_filter-ブール値
    1-同じ上に複数のネットワークインターフェイスを持つことができます
    サブネット、および各インターフェイスのARPに応答させる
    カーネルがパケットをルーティングするかどうかに基づいて
    そのインターフェイスからのARPされたIP（したがって、ソースを使用する必要があります
    これが機能するためのベースのルーティング）。言い換えれば、それは制御を可能にします
    どのカード（通常1）がarpリクエストに応答します。

    0-（デフォルト）カーネルはアドレスでarp要求に応答できます
    他のインターフェースから。これは間違っているように見えるかもしれませんが、通常は
    なぜなら、それは成功したコミュニケーションの機会を増やすからです。
    IPアドレスは、Linuxではなく、完全なホストが所有しています。
    特定のインターフェース。load-のようなより複雑な設定の場合のみ
    バランシング、この動作は問題を引き起こしますか。

    インターフェースのarp_filterは、少なくとも1つの場合に有効になります
    conf / {all、interface} / arp_filterはTRUEに設定され、
    それ以外の場合は無効になります

より徹底的な処理については、次の記事を参照してください。

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

これは古い問題であることは知っていますが、最近、組み込みデバイスでもまったく同じ状況に遭遇しました。デバイスにはイーサネットとwifiの両方のインターフェースがあり、両方のインターフェースがいつでも同じネットワーク上でアクティブになりますが、ネットワークトラフィックは「優先」インターフェースを介してルーティングされる必要があります。

ほとんどのユーザーは、この方法でデバイスを構成することはありませんが、理論的には可能であるはずです。

NetgearルーターはIPアドレスの競合を報告するため、最初に問題を取り上げました。2つのMACアドレスが単一のIPを共有していました。どうやら、このシナリオではルーターの動作が悪くなり、ユーザーのネットワークが台無しになります。

ルーター（イーサネット+ WiFi）、Windowsラップトップ（イーサネットのみ）、および組み込みデバイス（イーサネット+ WiFi）のみを含むプライベートネットワークを作成しました。wireshark、デバイスでtcpdump、およびWindowsでarpを使用すると、次の動作を確認できます。

1. デバイスのifconfigには、別個のwlnおよびイーサネットIPと別個のMACアドレスが表示されます
2. 時々（ごくまれに）、Windowsからのarp –aが正しいIP-MACの組み合わせを示します。
3. ほとんどの場合、Windowsからのarp –aは、wlnとeth0の両方が同じMACアドレスを持っていることを示します。
4. Windowsからwlnまたはeth0のpingを実行すると、ping応答はwlnから送信され、めったにeth0から送信されません。tcpdumpは、wlnが4つのpingの1つにのみ応答したことを示します（たとえば）
5. Windowsがeth0 IPに対してarp「who has」メッセージを送信すると、eth0とwlnの両方のインターフェースが、そのIPを持っていると応答します

アイテム3はアイテム5が原因であると考えています。wlnがeth0のみが応答すべきarpメッセージに応答しているため、arpテーブルが台無しにされています。アイテム4もアイテム5によって引き起こされると信じています。PingはMACアドレスに基づいて送信され、最後に受信したarpメッセージはeth0 IPがあるというwlnからだったため、pingは誤ってwlnインターフェイスにルーティングされます。

掘り下げてテストした結果、ソリューションは実際には非常に簡単でした。この記事を参照-http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Linuxカーネルネットワークドライバーは、既知のインターフェイスに対する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

これは以前のバージョンのOS（openembeddedに基づく）で正常に機能したため、私の解決策は次のバージョンのOSを待つことでした。私の最善の推測は、ワイヤレスカーネルモジュールがバグだということでした。

Insyteのコメントのフォローアップ。

いくつかの命名をしましょう：

• PC1-右上
• PC2-左上
• PC3-左下

ロボットは、有線メディアと無線メディアの両方を介して3台のPCから到達可能です。また、同じサブネット上にあるため、有線メディアのarp要求がどの方法で処理されたかを確実に知ることはできません。つまり、スイッチがarp要求をブロードキャストするとき、ロボットは両方のインターフェイスでそれを受信します（図を参照）。したがって、無線メディアの有線メディアでIPのarp要求を受信します可能性が高くなりますボックスのワイヤレスメディアの物理アドレスで応答し、そのIPが設定されている

私は過去にこの問題を抱えていました、それはあなたのものに正確ではありませんでしたが、似ていました。デフォルトでは、Linuxは、IPが構成されているインターフェースに関係なく、arp要求を受信するインターフェースの物理アドレスで応答します。したがって、PC3をロボットのeth0インターフェイスに直接接続し、192.168.0.101のarp要求を実行すると、ra0ではなくeth0インターフェイスの物理アドレスが返されます。

私の展開シナリオは次のとおりです。

[RTR] | ------------ eth0 --- [サーバー]
| -------- | switch1 | ----- eth1 ----- [サーバー]

両方のインターフェースが接続する同じスイッチ。それがあなたを助けることを願っています。

ルーターには、サーバー上の2つの異なるインターフェイス上の2つの異なるネットワークのインターフェイスで構成されたプライマリおよびセカンダリIPアドレスがありました。しかし、eth0のIPアドレスに対するeth1での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

起動時に適用できるように、ロボットのどこかに置いてください。

推奨事項：2つの異なるサブネットを構成することをお勧めします（たとえば、ra0の192.168.1.x / 24とeth0の192.168.2.x / 24）。PCでIPエイリアスを使用でき、ロボットは任意の場所からアクセスできます。 2つのIPの。同じホスト上の同じサブネットに2つのアウトバウンドパスを設定することはできません。ロボットが他のロボットを好むようなものがない限り、そうではありません。ロボットは、そこからパケットを送信するために1つのパスしか使用できません。

読み取り値： arp_announce、 arp_ignore

ワイヤレスAPとスイッチの間に設定ミスがあると思います。スイッチとAPはパケットの送信先が混乱しています。しかし、これについてはわかりません。また、プログラムがパケットの送信先を認識できるゲートウェイを定義する必要があると思います。何かのようなもの

route add default gw 192.168.0.1