我在通过无线调制解调器在两个 debian 系统之间建立可靠的 ppp / tcpip 链接时遇到了很多麻烦。
我的硬件拓扑有点复杂。
该系统采用：
- 无线电链路两端均运行 raspbian stretch (RPI) 的 Raspberry Pi 3B
- RFDesign RFD900x 无线调制解调器（通过 FTDI 电缆通过 USB 连接到 RPI）（RFD900）
- Linksys 无线路由器，通过 NATing（WIFI）连接到卫星服务（SkyMuster - 澳大利亚），再连接到澳大利亚未知的 POP，最后连接到互联网（SAT）
- 通过 SAT 的 vpn（vpnc）连接到由路由器终止的另一个澳大利亚 ISP 静态 IP。（这是 RPI3Bs 的默认路由）
- （VPN）VPN 端点通过静态 IP 连接到网络（结束）
我相信问题出在 RFD900x 调制解调器上，与无线电丢包时发生的 TCP 拥塞回退有关，但我提供了其他详细信息以供参考，以防我遗漏了一些愚蠢的事情。
这些问题可以在 RFD900 上的 RPI 之间重现。
从端点（最麻烦的一点）到互联网的链接如下：
RPI -> RFD900 -> RFD900 -> RPI -> VPN -> WIFI -> SAT -> 结束。
再次重申上述内容。
RFD900 会因为距离和障碍物而大量丢包。我尝试过各种天线配置，但都无济于事（全向天线、Yaggi 天线、直接天线和从花岗岩悬崖上反弹）。我尝试过调整调制解调器、MTU、PPP 设置等各种参数，以实现 TCP/IP 可靠性，但都无济于事。
空中速度为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 报头压缩被认为对有损链路存在问题，并且 RFC 在压缩技术方面取得了进展，例如 ROHC - RObust 报头压缩，包括一个 ROHC 工作组，似乎已经出现了各种开源中不可用的专有压缩协议。
- 对于依赖专有协议的蜂窝链路（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 拥塞设置是否值得研究？