☰

Debian で pppd および tcp カーネル設定を使用して損失のあるワイヤレス モデムで ppp を安定させる方法は？

tag-icon • tag-icon tcp modem ppp pppd
Debian で pppd および tcp カーネル設定を使用して損失のあるワイヤレス モデムで ppp を安定させる方法は？

私は、ワイヤレスモデムを介して2つのDebianシステム間で安定したppp / tcpipリンクを確立するのに多くの困難を抱えています。

私のハードウェアトポロジーは少し複雑です。

このシステムは以下を使用します。

  • Raspberry Pi 3Bは、ワイヤレスリンクの各端でRPI（raspbianstretch）を実行します。
  • RFDesign RFD900xラジオモデム（FTDIケーブルを介したUSB-RPI）（RFD900）
  • NAT（WIFI）経由で衛星サービス（SkyMuster - オーストラリア）、オーストラリアの未知のPOP、インターネット（SAT）で動作するlinksys Wi-Fiルーター
  • SATを介して他のオーストラリアISP固定IPに接続されているVPN（vpnc）は、ルータによってシャットダウンされます。 （これはRPI3Bのデフォルトパスです）
  • （VPN）VPNエンドポイントは静的IPを使用してネットワークに接続する（END）

私は問題がRFD900xモデムにあり、無線がパケットを破棄したときに発生するTCP輻輳フォールバックに関連していると思います。しかし、私が愚かなことを逃した場合に備えて、コンテキストに関する追加の詳細を提供しています。

これらの問題は RFD900 の RPI 間で再現可能です。

最も面倒なエンドポイントからインターネットへのリンクは次のとおりです。

RPI - > RFD900 - > RFD900 - > RPI - > VPN - > WIFI - > SAT - >終了。

もう一度上記の文脈を参照してください。

RFD900は、距離や障害物によって多くのパケットが失われます。私はさまざまな公共構成を試しましたが、何の役にも立ちませんでした（オムニ、八木、直接大花崗岩の崖から飛び出すこと）。 TCP / IPの信頼性を得るために、モデム、mtu、ppp設定などのさまざまなパラメータを調整してみましたが、成功しませんでした。

待機速度は64kbです。シリアル速度は57kbです。

診断注：

  • 131バイトまたは151バイトのワイヤレスMTUサイズは、RFD900を介してさまざまな距離にわたって単純なシリアル間通信を実行するときに最高のスループットを持ちます。
  • 継続的なストリーミングではなく、「バースト」 - >バースト、バースト、バーストにもかかわらず、スループットは安定しています。
  • 私はこの「暴走」がTCPが無線パケット損失を輻輳として扱い、不可避な再試行飽和をもたらす機能だと思います。
  • 飽和状態になると、セッション（ssh、scp、aptなど）がさまざまな拡張時間（数秒、通常2〜3分、時には10分以上）の間停止するように見えます。
  • aptは通常失敗します。 scpとsshには複数の一時停止と膨大な遅延がありますが、続行して最終的に目的地に到達する傾向があります。
  • 長い ls -la などの長い応答が含まれていない場合は、SSH 相互作用を通じてリンクを使用できます。
  • モデムのフロー制御（なし、RTSCTS、XONXOFF）は私のテストでは重要ではないようです。
  • さまざまな形式のpppペイロード圧縮は重要ではないようです（BSD、Predictor、deflateなど）。
  • Van Jacobsenヘッダー圧縮はバーストあたりのスループットを増加させますが、停止とレイテンシを増加させます。
  • 私は解決策を見つけるために広く検索しました（戻ってRFCを読みました）。
  • VJヘッダー圧縮は損失のあるリンク問題と見なされ、RFCはさまざまな独自の圧縮プロトコルとして登場したように見えるROHCワークグループを含むROHC - RObustヘッダー圧縮などの圧縮技術に進展しています。これらのプロトコルはオープンソースです。
  • この問題は、独自のプロトコル（pppとRLPを使用）に依存するセルラーリンクでよく解決されているようです。

私もpppdを実行している現在のスクリプトをここに公開しました（私が試したさまざまなオプションを含む - #commented行を参照してください）：

# set up the pppd to allow the remote unit to connect as an IP peer
# additional options for remote end: usepeerdns defaultroute replacedefultroute

pppd /dev/ttyUSB0 57600 mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach

#pppd /dev/ttyUSB0 57600 novj novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach

#pppd /dev/ttyUSB0 57600 192.168.10.1:192.168.10.2 mru 131 mtu 131 proxyarp noauth crtscts nocdtrcts noaccomp nobsdcomp nodeflate nopcomp nopredictor1 novj novjccomp lock mru 131 mtu 131 passive local maxfail 0 persist updetach

#debug ktune bsdcomp 12 xonxoff nocrtscts mru 296 mtu 296
#pppd /dev/ttyUSB0 57600 debug mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist updetach proxyarp

#pppd /dev/ttyUSB0 57600 noaccomp nobsdcomp nodeflate nopcomp nopredictor1 novj novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach

#pppd /dev/ttyUSB0 57600 novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach

オープンソースのpppdを使ってこの問題を解決した人はいますか？代わりに使用できる他のオプションや技術はありますか？

カーネルTCP輻輳設定を調べる価値はありますか？

答え1

私の質問に対する部分的な答えとして、次のことでかなりの信頼性向上を達成しました。

tcp_congestion_controlカーネルプラグインをデフォルトのキュービックからbbrに変更すると、バッファ拡張の問題が大幅に解決され、問題の核心であるバッファ拡張とワイヤレス接続の損失が発生しました。

これを行うには、tcp_bbrカーネルモジュールをロードし、net.coreキューモデルをプロセスキューに変更してbbrモジュールに速度を提供する必要があります。

RPI のデフォルト値は次のとおりです。

net.ipv4.tcp_congestion_control=立方体

net.core.default_qdisc=pfifo_fast

実行時にこの設定を変更するコマンドは次のとおりです。

modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

現在/etc/rc.localというスクリプトでこれを実行します。 modprode.dとsysctl.confを変更したり、sysctl.dのファイルで簡単に永久に作成したりできます。

その結果、より滑らかなSSH応答、より安定した一括送信が行われました。それでも静止した状態で迅速かつ確実に再開することで、すぐにコマンドプロンプトに戻ることができます（100％で長時間一時停止するのではなく（例：1 - 3を使用して前の数回に戻るのではなく））、キュービック輻輳制御の場合と同様に）。

全体的な速度はトレードオフですが、安定性がより重要です。たとえば、scpを使用して無線リンクを介して283kファイルを転送すると、次のような結果が得られます。

100%  283KB   2.5KB/s   01:51

これは今まで私が満足している妥協です。しかし、長期にわたって実行されるバルク転送プロセスは依然として問題があり、最終的に中断され完了しません。

たとえば、apt-getアップデートは1時間以上実行され（11.7MBファイルで停止）、実行を続行するには時々ssh端末を介して入力する必要があり、完全に失敗しませんでしたが、最終的に非常に長い遅延に閉じ込められました。

以下の画面キャプチャでは、プロセスは1時間以上続き、一部のCRは10〜15分ごとに表示され、^ C送信と端末応答の間に約5分の遅延が発生しました。

root@priotdev2:~# apt-get update
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian stretch InRelease [15.0 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [145 kB]                                                   
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [30.7 kB]                                                    
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
23% [3 Packages 270 kB/11.7 MB 2%]                                                                            2,864 B/s 1h 6min 15s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
29% [3 Packages 1,263 kB/11.7 MB 11%]                                                                          131 B/s 22h 2min 19s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
60% [3 Packages 5,883 kB/11.7 MB 50%]                                                                        16 B/s 4d 4h 13min 58s
60% [3 Packages 5,902 kB/11.7 MB 51%]                                                                         1,531 B/s 1h 2min 38s
66% [3 Packages 6,704 kB/11.7 MB 58%]                                                                                              

66% [3 Packages 6,704 kB/11.7 MB 58%]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
66% [3 Packages 6,735 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,746 kB/11.7 MB 58%]                                                                          230 B/s 5h 55min 46s

66% [3 Packages 6,747 kB/11.7 MB 58%]                                                                          148 B/s 9h 12min 47s^C
root@priotdev2:~# ^C
root@priotdev2:~# 
root@priotdev2:~#

上記のダンプの右にスクロールして、低いスループット（場合によっては1秒あたり16バイトと32バイトまで減少）を確認します。

衛星リンクに関連するエンドツーエンド変数を削除するために、aptプロセスは実際にアップストリームRPIをaptキャッシュ（最新キャッシュ）として使用し、トランスポートは無線リンクからのトラフィックのみを表します。

さらなる改善について、コミュニティからのコメントを歓迎します。

関連情報