Debianでpppdおよびtcpカーネル設定を使用して、損失のある無線モデムに対してpppを信頼できるようにするにはどうすればよいですか？
無線モデムを介して2つのDebianシステム間で信頼性の高いppp/tcpipリンクを確立するのに多くの問題があります。
私のハードウェアトポロジは少し複雑です。
システムは以下を使用します：
- ラズビアンストレッチ（RPI）を実行している無線リンクの両端にあるラズベリーパイ3B
- RFDesign RFD900x無線モデム（USB経由でFTDIケーブルを介してRPIに接続）（RFD900）
- それがNATしているlinksyswifiルーター（WIFI）衛星サービス（SkyMuster-オーストラリア）へAUSの未知のPOPからインターネット（SAT）へ
- SATを介してルーターによって終端された別のAusISP静的IPへのVPN（vpnc）。 （これはRPI3Bのデフォルトルートです）
- （VPN）VPNエンドポイントは静的IP（END）でネットに接続されています
TCP無線がパケットをドロップしたときに発生する輻輳フォールバックに関連する、RFD900xモデムを介した問題であると信じていますが、コンテキストに関するその他の詳細を提供し、何かが足りない場合に備えてばかげている。
この問題は、RFD900を介してRPI間で再現可能です。
エンドポイント（最も問題のある）からのインターネットへのリンクは次のとおりです。
RPI-> RFD900-> RFD900-> RPI-> VPN-> WIFI-> SAT-> END。
コンテキストについても上記を参照してください。
RFD900は、距離と障害物が関係するため、パケットを大量にドロップします。私はあらゆる種類の空中構成を無駄に試しました（オムニ、ヤギ、直接対花崗岩の崖で跳ね返る）。 TCP/IPの信頼性を実現するために、モデム、mtu、ppp設定などのあらゆる種類のパラメーターを調整してみました。
対気速度は64kbです。シリアル速度は57kbです。
診断ノート：
- さまざまな距離でのRFD900を介した単純なシリアル間通信では、131バイトまたは151バイトの無線MTUサイズが最高のスループットを発揮します。
- スループットは信頼できますが、連続フローではなく、「バースト」->バースト、バースト、バーストです。
- この「バースト性」は、TCP無線パケットのドロップアウトを、不可避の再試行飽和に進行する輻輳と見なす機能であると思われます。
- 飽和状態になると、セッション（ssh、scp、aptなど）がさまざまな時間（秒、多くの場合2〜3分、場合によっては> 10分）の間フリーズするように見えます。
- aptは一般的に失敗します。 scpとsshは継続して最終的にそこに到達する傾向がありますが、通常は複数のストールとクレイジーな遅延時間があります。
- Sshを介して対話的にリンクを使用できます。ただし、長い応答が含まれていなければ（たとえば、長いls -la）。
- モデム（なし、RTSCTS、XONXOFF）へのフロー制御は、私のテストでは重要ではないようです。
- さまざまな形式のpppペイロード圧縮は重要ではないようです（BSD、Predictor、deflateなど）。
- Van Jacobsenヘッダー圧縮はバーストあたりのスループットを向上させますが、ストールと遅延を悪化させます
- 私は解決策を広範囲に検索しました（戻ってRFCを読んでも）。
- VJヘッダーコンプは不可逆リンクに問題があると特定されたようであり、ROHCなどの圧縮技術に関するRFCの進歩がありました-ROHCワークグループを含むRObustヘッダー圧縮には、で利用できないさまざまな独自の圧縮プロトコルが出現したようですオープンソース。
- この問題は、独自のプロトコルに依存するセルラーリンク（pppとRLPの両方）では十分に解決されているようです。
また、pppdを実行する現在のスクリプトをここに投稿します（試したさまざまなオプションを含みます-＃コメント行を参照してください）。
# 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輻輳設定は調べる価値がありますか？
私自身の質問に対する部分的な回答として、次の方法で信頼性を大幅に向上させました。
Tcp_congestion_controlカーネルプラグインをデフォルトのcubicからbbrに変更することで、損失の多い無線接続とともに問題の核となるbufferbloatに大幅に対処しました。
これには、tcp_bbrカーネルモジュールのロードと、bbrモジュールのペーシングを提供するためにnet.coreキューイングディシプリンモデルを均等化キューイングに変更する必要がありました。
RPIのデフォルトは次のとおりです。
net.ipv4.tcp_congestion_control = cubec
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 updateを1時間以上実行すると（11.7MBファイルで停止）、実行を継続するにはsshターミナルを介してキャリッジリターンが時折必要になり、最終的には非常に長い遅延になりますが、すべてが失敗することはありません。 。
次のスクリーンスクレイピングでは、プロセスは1時間以上で、10〜15分ごとにいくつかのCRがあり、^ 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キャッシュ（最新）として使用しており、転送は無線リンクを介したトラフィックのみを表します。
さらなる改善に関するコミュニティからの洞察は大歓迎です。