web-dev-qa-db-ja.com

UDPパケットを停止しているのは何ですか（ルートがダウンしていることをどのように認識しますか）？

UDP経由でRTSPビデオパケットを送信するサーバー（カメラ）があります。顧客のサイトでは、複数のホップを通過します。そのうちの1つは、信頼性の低いWiFiリンクで、奇数のパケットまたは5つをドロップする可能性があります。通常、これは見過ごされますが、ストリームが数秒間停止し、顧客に不快感を与えることがあります（cr * pネットワークがどういうわけか私たちの問題です...）

tcを使用して危険な接続をシミュレートするテストで、奇妙な状況が見つかりました。return方向で接続を切断すると（- パケットはサイレントに破棄されます）、RTSPクライアント（Live555 Wis-Streamer）がまだ信じているにもかかわらず、数秒後にカメラからのUDPパケットのフローが停止しますそれは陽気にUDPパケットをパイプに吹き付けています。

これは奇妙なことです。明らかにUDPパケットはACKされておらず、物理リンクがドロップすることはないため、システムにはパケットがチェーンのさらに上流のビットバケットにドロップしていることを知る方法がなく、ストリーマーにはそれを知る方法がありません。誰もそれを聞いていません（ストリーマーセッションのタイムアウトは遅くなるまで期限切れになりません）。

編集：UDPパケットの受信が停止した瞬間にARPing（<client>を持っている人）が表示されますが、スタックに接続を通知する前のARPはありません落ちた。

だから私は2つの質問があります：

  1. ネットワークスタックが接続に問題があることを通知できる他のメカニズムはありますか？
  2. ネットワークスタックは、特定の状況下でパケットをサイレントにドロップしますか？

テストのセットアップを示すため：

通常の状態、双方向の接続：

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

障害状態、TCがサーバーに戻るパケットをドロップします。

Our server --> Switch --> TC  <==> Switch <==> PC
                 |                    |
  Wireshark <-- TAP                   |
                                      |
  Wireshark <----------------------- TAP
networkingipmonitoringbusyboxarp
3
John U

ARPテーブルが古くなったようです（UDPを狂ったようにストリーミングしていても、ARPタイムアウトは発生せず、TCPトラフィックは通常の操作でははるかにまばらです） ）タイムアウトを増やすと、2分未満の「中断」で問題が表示されなくなりました（この時点で、RTSPクライアントセッションはとにかくタイムアウトします）。

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

残念ながら、arpコマンドが使用できないBusyboxを使用しているため、これにはかなりの注意が必要でしたが、現在、処理しようとしている状況では信頼できるようです。

私はまだネットワークスタックがどのように機能するかを理解したいと思っています-ARPテーブル/エントリが古くなった瞬間にパケットの送信を停止しますが、パケットを送信しようとしているコードのチェーンのさらに上流でエラーを引き起こさないようです。

0
John U

接続を切断したら、ICMP宛先到達不能パケットの受信を開始して、接続が切断されたことを通知する必要があります。これは通常のIPの動作です。

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

カスタムプロキシサーバーを使用してパケットをドロップする方がよい場合があります。

2
BillThor