☰

UDPパケットをブロックするものは何ですか（パスがダウンしているのかどうかはわかります）。

tag-icon • tag-icon networking ip monitoring busybox arp
UDPパケットをブロックするものは何ですか（パスがダウンしているのかどうかはわかります）。

UDPを介してRTSPビデオパケットを送信するサーバー（カメラ）があります。カスタマーサイトでは複数のホップを通過し、そのうちの1つは奇妙なパケットまたは5つのパケットを破棄する信頼できないWiFiリンクです。通常、これは目立たないが、時には数秒間ストリームを中断し、顧客を不幸にする。 （私も知っています。彼らのcr * pネットワークがある程度私たちの問題であることを知っています...）

シミュレートされた疑わしい接続でテスト中にtc奇妙な状況が見つかりました。返品方向（パケットは自動的に破棄されます。）、RTSPクライアント（Live555 Wis-Streamer）が動作し続けても、数秒後にカメラからストリーミングされたUDPパケットは停止します。信じるUDPパケットをパイプの下にうまく散布しています。

これは、UDPパケットが承認されず、物理リンクが絶対に失われないため、奇妙なことです。したがって、私たちのシステムは、パケットがチェーンのビットバケットにドロップされていることを知らず、ストリーマーは誰も知りません。これを受け取ります（ストリーミングセッションタイムアウトは後で期限切れになりません）。

編集：私たちはARPingを見ます（誰が<顧客>）この時点でUDPパケットはもはや入っていませんが、それ以前はスタックに接続が切断されたことを知らせるパケットはありません。

だから、2つの質問があります。

  1. ネットワークスタックが接続に問題があることを知っている他のメカニズムはありますか？
  2. 特定の状況では、ネットワークスタックは自動的にパケットをドロップしますか？

テスト設定のデモ：

定常状態、双方向接続：

Our server <==> Switch <==> TC  <==> Switch <==> PC
                 |                    |
  Wireshark <-- TAP                   |
                                      |
  Wireshark <----------------------- TAP

エラー状態、TCはサーバーに返されたパケットを破棄します。

Our server --> Switch --> TC  <==> Switch <==> PC
                 |                    |
  Wireshark <-- TAP                   |
                                      |
  Wireshark <----------------------- TAP

答え1

接続が失われた場合は、ICMP宛先に接続できないパケットを受信して​​、接続が切断されたことを知らせる必要があります。これは通常のIP動作です。

ICMPパケットを監視および表示するためのツールがあります。他のツールを使用して、選択基準を満たすすべてのトラフィックをダンプまたはキャプチャできます。

パケットをドロップするには、カスタムプロキシサーバーを使用する方が良いかもしれません。

答え2

まあ、ARPテーブルがますます不思議になっているようです。 （私たちがUDPを狂ったようにストリーミングしても、これはARPタイムアウトを引き起こさず、通常の動作中にTCPトラフィックがまれになります。）タイムアウトを増やすことで問題が発生するのを防ぎます。約2分未満の「中断」（この時点でRTSPクライアントセッションがタイムアウトしました）：

ARP gc_staletime extended from 60sec to 360sec
ARP base_unreachable time extended from 30sec to 240sec

残念ながら、Busyboxで利用可能なコマンドがなかったので、かなりのナビゲーションが必要でしたが、arp現時点では私たちが処理しようとしている状況に信頼できるようです。

私はまだネットワークスタックがどのように機能するかを理解したいと思います。現在、ARPテーブル/エントリが古くなってパケット転送が停止しますが、パケット転送を試みるコードチェーンでエラーが発生していないようです。

関連情報