問題タブ [packet-loss]

WIFI 経由で組み込み AP に接続している Android スマートフォンがあります。Linux で Tshark を実行しているラップトップで WIFI トラフィックを盗聴しています。小さな (234 バイト) TCP パケットを 100 ミリ秒ごとに 5 回転送し、その後 500 ミリ秒のデータなしで転送しています。定期的にパケットが無視され、再送信が強制されます。TCP ソケットを介してデータを転送する場合、ある程度のパケット再送信が予想されますが、これは過剰です。特に、パケットがスニファーによって問題なく受信されるため (つまり、「飛行中」の破損がないため)、その後の再送信されたパケットも Android によって無視 (ドロップ) されます。

注意: 「IGNORED」と言うときは、受信無線 (802.11 ACK) から、または Wireshark トレースで TCP スタック (TCP ACK) の受信から、確認応答が表示されないことを意味します。下の画像では、データ パケット599はすぐに確認応答されますが、次のデータ パケット (606) は無視され、次の 4 回の再送信 (607 ～ 610) も無視されます。

Wireshark ログ

これは、Android v4.x (テスト済みの 4.0.4 および 4.2.2) で実行されている同じ APK や、iOS で実行されている同様のアプリケーションでは発生しません。どちらの場合も、予期されるドロップされた TCP パケットがあり、その後に再送信が続きますが、ほとんどの場合、すぐに ACK が返されます。

私が転送しているパケットについて特別なことは何もなく、パケット損失に対処するために TCP パケットのシームレスな再送信がある程度期待されているため、多くのアプリケーションがこの同じ問題に苦しんでいると思われますが、全体的な転送速度の低下を単純に受け入れて、 「WIFI混雑」への転送が遅くなります。

私の場合、(サードパーティが提供する) WIFI ハードウェア/ファームウェア ソリューションは、過剰な TCP バックログが発生して詰まります。彼らは、回復に役立つように見える応急処置を備えた新しいソリューションを持っていますが、それはすでに現場にあるハードウェアの問題を解決していません.

ラジオが定期的にシャットダウンされるか、オフチャンネルにシフトされるように、Android 5.xで何かが変更されたと思います。定期的に発生しているように見えるため、これはチャネル スキャンが原因である可能性があります (スキャン間隔中にドロップされたパケットは、無線が戻ったときに再送信によって回復されることを期待して)。Android チャネル スキャン動作の明確な定義を見つけることができませんでした (それについては別の投稿があります)。

失敗すると、数ミリ秒間隔で 4 または 5 パケットのバーストで再送信が行われ、その後 1 秒間何も送信されず、その後に別のバーストが続きます。通常、再送信されたパケットはしばらく無視されます (数秒かかる場合もあります)。最終的に、再送信パケットが確認され、送信は次のパケットで続行されます。

また、定期的な DNS プローブが行われていることにも注意しました (DNS クエリを介して定期的にプローブされる URL のリストを以下に示します)。一部はインストールされたアプリケーションである場合もあれば、オペレーティング システムである場合もあります (たとえば、「connectivitycheck.android.com」は、AP が実際にインターネット接続を提供しているかどうかを確認するために使用される可能性がありますが、私の場合はそうではありません)。

px.demdex.net エントリが私の注意を引いたのは、これが誰を表しているのかわからなかったからです。アドビであることが判明しました。私が知らなかった積極的に調査しているコードのビットが明らかにあり、私の問題が純粋に Android の問題であることを確認するために、Nexus 4 スマートフォンを出荷時設定にリセットし、WIFI 通信の問題に関係している可能性のある初期化オプションを拒否しました ( Google 位置情報サービスとして、オフのときでも WIFI を使用できるようにするなど）。TCP パケットは引き続きドロップされます。

Android側では、私は以下を持っています： - 場所を「デバイスのみ」（GPS）に設定 - WIFI「スキャンは常に利用可能」を無効にしました - ソケットが開いているときはいつでもアプリ内で「WIFI_MODE_FULL_HIGH_PERF」ロックを取得しました。- アプリが通信を開始するとソケットが開かれ、アプリが終了するまで開いたままになります。しばらくの間 (現在 3 秒間) パケットが表示されない場合、アプリはソケットを閉じて新しいソケットを開き、通信を強制的に再確立しようとします。

IWifiManager の「setAllowScansWithTraffic()」関数を発見しました。これは、スキャンの明示的な制御 (リストからその可能性を削除するため) を提供するように思えますが、これを実装するのは難しいようで、私の一部にはなりませんでした。アプリ （？）。IWifiManager は、Android の実装者が独自の WIFI マネージャー (OS) サービスを構築するためのスタブを提供するものであり、アプリ レベルでの使用を意図したものではないと考えています。

入力/提案をいただければ幸いです。

アップデート

「チャネル スキャン」の可能性を追跡している間、テスト対象のハードウェアが WIFI チャネル 8 で動作している間に、パケット スニファを使用して WIFI チャネル 3 で ACK パケットをログに記録しました。Android のバグを開いた

クライアントは最初にファイル名を送信し、サーバーはその名前のファイルを作成してデータを書き込みます。

ファイル名は、「file.txt」のような形式のコマンド引数からキャストされます。問題は、「.txt」以外のファイル名をキャストするたびにエラーが発生することです。

15% の確率で、パケット損失のある状況でコードをテストしています。損失が発生した場合、パケットの一部を残さずに、パケット全体が消えます。そのため、毎回ファイル名が失われると思っていました。ファイル名パケットが失われない場合、ファイルは適切な名前で開きます。だから私はそれが少なくとも10回ごとに適切なものを受け取ると思っていましたが、そうではありませんでした.

これらの変数には他に問題はないと思います。パケット損失が想定されていない場合、期待どおりに機能しました。3番目の引数を strlen(argv[3]) + 1 から変更しましたが、何も変わっていません。

コードを変更することでこの問題を解決できますか?

時々、私の DSL ルーターはこの奇妙な方法で失敗します:

ご覧のとおり、エラー コード$?は0. そのため、コマンドが失敗したかどうかを単純に検出することはできません。出力はどのスクリプトでもエラーを生成しないためです。

パケット損失があったことを検出する適切な方法は何ですか? 出力を解析
する 必要がありますか、それとももっと簡単な方法がありますか?grep

UDP パケットの受信を処理するためにコードを書きました。パケットはすべて同じ長さ (120 バイト) で、毎秒約 1,000 パケットが入ってきます。簡単に言えば、私のコードはこのようなものです。

このコードを書いたとき、recv() 関数はその時点で UDP ソケット バッファ内のすべてのバイトを返すことを期待していましたが、バッファ内にさらにバイトがあるにもかかわらず、毎回 1 つのパケット (120 バイト) しか返されないようです。 . だから今、私はパケット損失に遭遇しました。この問題を解決するには他にも多くの方法があることは知っていますが、今のところ、UDP バッファーに存在するすべてのバイトを一度に読み取ることが、私にとって最も簡単な方法です。では、UDP バッファ内のすべてのバイトを一度に読み取る方法はありますか?

前もって感謝します

私の友人と私は同じタイプのインターネット接続 (ADSL 2+) を使用しており、同様の速度 (10 ダウン 1 アップ) と ping を取得しますが、両方が同じ IP に接続しようとすると、異なる ping を取得します。オーストラリアからカナダのサーバー (158.69.135.112) に接続しようとしていますが、はるかに高い ping が得られますが、米国または英国の両方で IP を ping すると、非常によく似た ping が得られます。これが traceroute の結果です。

私のトレースルート

友達のトレースルート

私の友人は私より 100 ミリ秒以上 ping が遅いのですが、traceroute に問題はありますか? 最初の traceroute のホップ 12 と 13 の間に大きなジャンプがあることに気付きました。これは問題になる可能性がありますか? どんな助けでも大歓迎です！