Как сделать ppp надежным для радиомодемов с потерями, используя настройки ядра pppd и tcp в debian?

У меня много проблем с установлением надежной связи ppp / tcpip между двумя системами Debian по радиомодемам.

Моя аппаратная топология немного сложна.

Система использует:

• Raspberry Pi 3B на каждом конце радиолинии, на которой работает растяжка (RPI)
• Радиомодемы RFDesign RFD900x (подключенные через кабель FTDI через USB к RPI) (RFD900)
• Wi-Fi-роутер linksys, к которому он подключается (WIFI) к спутниковой службе (SkyMuster - Австралия), к неизвестному POP в AUS к Интернету (SAT)
• Vpn (vpnc) через SAT на другой статический IP-адрес Aus ISP, завершенный маршрутизатором. (который является маршрутом по умолчанию для RPI3B)
• (VPN) Конечная точка vpn подключена к сети со статическим ip (END)

Я полагаю, что проблема заключается в использовании модемов RFD900x, связанных с перегрузками TCP, которые возникают, когда радиостанция отбрасывает пакеты, хотя я предоставляю другие подробности для контекста и в случае, если я что-то глупо пропускаю.

Проблемы воспроизводимы между RPI по RFD900.

С конечной точки (с наибольшим количеством проблем) ссылка на Интернет выглядит следующим образом:

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

Снова выше для контекста.

RFD900s много отбрасывает пакеты с учетом расстояния и препятствий. Я пробовал всевозможные конфигурации антенн, но безрезультатно (омни, ягги, прямой против отскока от гранитных скал). Я пытался настроить всевозможные параметры в модемах, настройках mtu, ppp и т. Д., Чтобы добиться надежности TCP / IP, но безрезультатно.

Скорость воздуха составляет 64 КБ. Серийная скорость 57kb.

Diag notes:

• Для простых последовательных соединений по RFD900 на различных расстояниях наилучшим значением пропускной способности является радиотранслятор MTU размером 131 байт или 151 байт.
• Пропускная способность является надежной, хотя она является «пачкой» -> пачка, пачка, пачка, а не непрерывный поток.
• Я подозреваю, что это "прерывание" является функцией TCP, рассматривающей выпадения радиопакетов как перегрузку, которая приводит к неизбежному насыщению повторных попыток.
• Когда он насыщается, сеансы (ssh, scp, apt и т. Д.) Просто замирают на переменное количество продолжительного времени (секунды, часто 2-3 минуты, иногда> 10 минут).
• apt вообще потерпит неудачу. scp и ssh имеют тенденцию продолжать идти и добираются там в конечном счете, хотя обычно с несколькими киосками и сумасшедшими временами задержки.
• В интерактивном режиме через ssh ссылка пригодна для использования, при условии, что длинные ответы не используются - например, long ls -la.
• Контроль потока для модемов (нет, RTSCTS, XONXOFF) кажется несущественным для моих тестов.
• Различные формы сжатия полезной нагрузки ppp кажутся несущественными (BSD, Predictor, deflate и т. Д.).
• Сжатие заголовка Van Jacobsen увеличивает пропускную способность на пакетную передачу, но усугубляет задержки и задержки
• Я много искал решения (даже возвращаясь и читая RFC).
• Кажется, что компоновка заголовка VJ была определена как проблематичная для каналов с потерями, и были достигнуты усовершенствования RFC по методам сжатия, например, ROHC - RObust Header Compression, включая рабочую группу ROHC, из которой, по-видимому, появились различные проприетарные протоколы сжатия, которые не доступны в открытом доступе. источник.
• Эта проблема кажется хорошо решенной для сотовых каналов связи (как с 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?