2つのネットワークカードの「合法的な」ARP中毒を集計すると、競合が発生します。

奇妙なことが起こっており、脅威が現れています。私たちはこれを解決しなければなりません。

状態：

当社のデバイス（ネットワークカメラ）は、ネットワークを介してビデオをレコーダー/サーバー（Live555 / WIS Streamerを使用）にストリーミングします。ビデオはUDPパケットです。

特定のサーバーを使用する特定のサイトでは、ビデオの送信中にLive555ストリーミングの1つのスレッドが時々（約24時間）ロックされていました。他のスレッドは引き続き実行され、IP経由でカメラに接続できます（Webページの表示、PINGなど）。

私たちは疑う：サーバー。 2つのネットワークポートがあり、それを統合します。 MACは2つですが、IPアドレスは1つです。ワイヤシェーキング中にカメラがあるポート（Aと呼ばれる）に流れているのを見て、別のポート（Bと呼ぶ）からARPを取得し、デバイスはMAC Aにパケットをスプレーするラインを停止し、MACにパケットをスプレーします。 B それから止まったようだ。

追加情報：サーバーは、誤った設定などにより、「無効な」ポートからの着信ARPパケットを破損しているようです。しかし、これらのパケットは、ドライバまたはカーネルネットワーク構成エラーのためにデバイスから読み取られ、動作します。または、チェックサムをスキップするCPUサイクルを節約します。

したがって、この混乱した状況はいくつかの質問を提起します。

1. カーネルネットワークコードのどこでパケットチェックサムを確認するか、確認を有効にする必要がありますか？私たちのハードウェアは固定されており、内蔵デバイスなので、ドライバを調整することは最悪の考えではありません。
2. send()プロセスがポートからデータを引き続き取得し、ARPテーブルがその下に移動したときにプロセスがロックする失敗メカニズムを推測できる人はいますか？

追加するには編集してください。：今、私たちはARPが実際に損傷していないと疑っています。これはWiresharkがパケットを正しく識別できないことです（パケットがFSCワードを含むのに十分な長さだと思いますが、今はゼロパディングだと思います）。これで質問の2番目の部分だけが残ります。 ARPテーブルのこの変更によって転送プロセスが中断されるのを防ぐにはどうすればよいですか？

追加内容を編集して以下を追加しました。人々は、私がポートの状態やプロセスの状態に関連する問題を無視していると考えたくありません。この問題は非常にまれであり（平均24時間に1回）、私たちが持っていない1つの（リモート）設置でのみ発生します。より詳細な診断のために研究室にレプリケートしていますが、システム監視は問題が発生してから約3分後にリセットされるため、メッセージを受信した頃はすでに再起動して起動しています。正常に動作します。

Wireshark情報を追加するには編集してください。：ここでWiresharkキャプチャを要約する最善の方法はよくわかりませんが（〜1Tbキャプチャパケットをアップロードするのは難しいです！）試してみましょう。Cam:X&Cam:Yは、2つの同じLive555 WIS Streamerインスタンスによって異なるポートで送信される2つのRTSPビデオストリームです。サーバー「A」と「B」は、サーバー上の2つのネットワークカードのMACです。

パケットの順序は次のとおりです。

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

このポイントまたはその近くにはストリームに他のパケットはありません。 Intel ANSパケットがNICから来るARPと常に一致するわけではありませんが、完全性のためにそれを含めたかったのです。

問題は非常に時間に敏感なようです。私たちは定期的にサーバー上でこれらの「チーム」ARPをチェックし、一度だけ問題を引き起こします。まるでネットワークスタックコードにARPテーブルを変更した特定のポイントがあるようです。 。特に、他のインスタンス（および他のすべてのネットワークトラフィック（HTTPなど））は引き続き正常に機能するため、失敗したフローインスタンスは必ずしも同じではありません。

チームで構成されたNICは、このセッションのようにARPを「すべきではない」ように聞こえますが、トラフィックがすべてUDPの場合、どのセッションもわかりません。