Как сделать 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, включая рабочую группу 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?