Wie mache ich ppp über verlustbehaftete Funkmodems mit pppd und tcp-Kerneleinstellungen unter debian zuverlässig?

Ich habe große Probleme, eine zuverlässige ppp / tcpip-Verbindung zwischen zwei Debian-Systemen über Funkmodems herzustellen.

Meine Hardware-Topologie ist etwas komplex.

Das System verwendet:

• Himbeer-Pi 3B an jedem Ende der Funkverbindung mit Raspbian-Stretch (RPI)
• RFDesign RFD900x-Funkmodems (über FTDI-Kabel über USB an die RPIs angeschlossen) (RFD900)
• Ein Linksys-WLAN-Router, den es NATing (WIFI) zu einem Satellitendienst (SkyMuster - Australien) zu einem unbekannten POP in AUS zum Internet (SAT) gibt
• Ein vpn (vpnc) über den SAT zu einer anderen statischen IP-Adresse des ISP, die von einem Router terminiert wird. (Dies ist die Standardroute für die RPI3Bs)
• (VPN) Der VPN-Endpunkt ist mit einer statischen IP (END) mit dem Netz verbunden.

Ich glaube, das Problem besteht darin, über die RFD900x-Modems zu sein, was auf TCP-Überlastungsrückwirkungen zurückzuführen ist, die auftreten, wenn das Funkgerät Pakete ablegt, obwohl ich die anderen Details für den Kontext zur Verfügung stelle und für den Fall, dass mir etwas Dummes fehlt.

Die Probleme sind zwischen den RPIs über den RFD900 reproduzierbar.

Vom Endpunkt (mit den meisten Problemen) ist die Verbindung zum Internet wie folgt:

RPI -> RFD900 -> RFD900 -> RPI -> VPN -> WIFI -> SAT -> END.

Wieder das obige für den Kontext.

Die RFD900s legen Pakete mit der Entfernung und den beteiligten Hindernissen ab. Ich habe alle Arten von Luftkonfigurationen ohne Erfolg ausprobiert (omni, yaggi, direkt oder abspringen von Granitfelsen). Ich habe versucht, alle möglichen Parameter in den Modems, mtu, ppp-Einstellungen usw. einzustellen, um die TCP / IP-Zuverlässigkeit ohne Erfolg zu erreichen.

Luftgeschwindigkeit beträgt 64kb. Die Seriengeschwindigkeit beträgt 57kb.

Diag Notizen:

• Bei einfachen seriellen zu seriellen Kommunikationen über den RFD900 in verschiedenen Entfernungen hat die Funk-MTU-Größe von 131 Bytes oder 151 Bytes den besten Durchsatz.
• Der Durchsatz ist zuverlässig, obwohl "Burst" -> Burst, Burst, Burst statt kontinuierlicher Fluss.
• Ich vermute, diese "Burstiness" ist eine Funktion des TCP, der die Ausfall von Funkpaketen als Überlastung betrachtet, die zu einer unvermeidlichen Wiederholungssättigung führt.
• Wenn die Sättigung erreicht ist, scheinen die Sitzungen (ssh, scp, apt usw.) für unterschiedliche Zeitspannen (Sekunden, oft 2-3 Minuten, manchmal> 10 Minuten) einzufrieren.
• apt wird in der Regel scheitern. scp und ssh neigen dazu, irgendwann weiterzukommen und dort hin zu gelangen, allerdings meist mit mehreren Ständen und verrückten Verzögerungszeiten.
• Interaktiv über ssh ist der Link verwendbar, sofern keine langen Antworten involviert sind - zB ein langer ls -la.
• Die Flusssteuerung der Modems (keine, RTSCTS, XONXOFF) scheint für meine Tests unerheblich.
• Unterschiedliche Formen der ppp-Payload-Komprimierung sind nicht relevant (BSD, Predictor, deflate usw.).
• Die Kopfkompression von Van Jacobsen erhöht den Durchsatz pro Burst, erhöht jedoch die Verzögerungen und Verzögerungen
• Ich habe ausgiebig nach Lösungen gesucht (sogar zurückgehen und die RFCs lesen).
• Es scheint, dass VJ-Header-Comp als problematisch für verlustbehaftete Verbindungen identifiziert wurde und RFC-Fortschritte bei Komprimierungstechniken aufgetreten sind, z. B. ROHC - RObust Header Compression, einschließlich einer ROHC-Arbeitsgruppe, aus der offenbar verschiedene proprietäre Komprimierungsprotokolle hervorgegangen sind Quelle.
• Das Problem scheint für zellulare Verbindungen (sowohl mit ppp als auch mit RLP) gelöst zu sein, die auf proprietären Protokollen beruhen.

Ich poste hier auch mein aktuelles Skript, das pppd ausführt (einschließlich der verschiedenen Optionen, die ich ausprobiert habe - siehe #kommentierte Zeilen.):

# 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 

Hat jemand das mit Open Source pppd gelöst? Gibt es andere Optionen oder Technologien, die eine Alternative wären?

Sind die TCP-Überlastungseinstellungen des Kernels einen Blick wert?