У меня много проблем с установлением надежной связи 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?