Como eu faço o ppp confiável sobre os modems de rádio com perdas usando as configurações do kernel pppd e tcp no debian? [fechadas]

Question

Estou tendo muitos problemas para estabelecer um link ppp / tcpip confiável entre dois sistemas debian em modems de rádio.

Minha topologia de hardware é um pouco complexa.

O sistema usa:

• Raspberry Pi 3B em cada extremidade do link de rádio executando raspbian alongamento (RPI)
• RFDesign RFD900x modems de rádio (conectados via cabo FTDI via USB para os RPIs) (RFD900)
• Um roteador wifi da Linksys que é NAT (WIFI) Para um serviço de satélite (SkyMuster - Austrália) para um desconhecido POP em AUS para a Internet (SAT)
• Um vpn (vpnc) sobre o SAT para outro Aus ISP IP estático terminado por um roteador. (qual é a rota padrão para o RPI3Bs)
• (VPN) O ponto final vpn é conectado à rede com um ip estático (END)

Acredito que o problema esteja nos modems RFD900x, relacionados a congestionamentos de congestionamento TCP que ocorrem quando o rádio libera pacotes, embora eu forneça os outros detalhes para o contexto e caso eu esteja perdendo alguma coisa boba.

Os problemas são reprodutíveis entre os RPIs sobre o RFD900.

Do ponto final (com mais problemas), o link para a Internet é o seguinte:

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

Novamente, o acima para o contexto.

Os RFD900s reduzem bastante os pacotes com a distância e os obstáculos envolvidos. Eu tentei todos os tipos de configurações aéreas sem sucesso (omni, yaggi, direto contra quicando penhascos de granito). Eu tentei ajustar todos os tipos de parâmetros nos modems, mtu, configurações de ppp etc para obter confiabilidade TCP / IP sem sucesso.

A velocidade do ar é de 64kb. A velocidade serial é de 57kb.

Notas de diagrama:

• Em comunicações simples de série para serial sobre o RFD900 a várias distâncias o tamanho da MTU de rádio de 131 bytes ou 151 bytes tem melhor taxa de transferência.
• A taxa de transferência é confiável, embora seja "intermitente" - > burst, burst, burst, em vez de fluxo contínuo.
• Eu suspeito que esse "burstiness" é uma função do TCP ver os dropouts do pacote de rádio como um congestionamento que progride para uma saturação de repetição inevitável.
• Quando satura, as sessões (ssh, scp, apt etc) parecem congelar quantidades variáveis de tempo prolongado (segundos, frequentemente 2-3 minutos, às vezes > 10 minutos).
• o apt geralmente falhará. scp e ssh tendem a continuar e chegar lá eventualmente, embora geralmente com várias barracas e tempos de delay malucos.
• Interativamente sobre o ssh, o link é utilizável, desde que não haja respostas longas - por exemplo, um longo ls -la.
• O controle de fluxo para os modems (nenhum, RTSCTS, XONXOFF) parece irrelevante para meus testes.
• Diferentes formas de compressão de payload do ppp parecem inconseqüentes (BSD, Predictor, deflate etc).
• A compactação de cabeçalho de Van Jacobsen aumenta o rendimento por burst, mas agrava as interrupções e atrasos
• Pesquisei extensivamente por soluções (mesmo voltando e lendo as RFCs).
• Parece que a compilação de cabeçalho VJ foi identificada como problemática para links com perdas e houve avanços de RFC nas técnicas de compressão, por exemplo, ROHC - RObust Header Compression, incluindo um grupo de trabalho ROHC parece ter surgido vários protocolos de compactação proprietários que não são disponível em código aberto.
• O problema parece bem resolvido para links de celular (ambos com ppp e RLP) - que dependem de protocolos proprietários.

Eu também posto aqui meu script atual que executa o pppd (incluindo as várias opções que eu tentei - veja # linhas comentadas.):

# 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

Alguém já resolveu isso com o pppd de código aberto? Existem outras opções ou tecnologias que seriam uma alternativa?

As configurações de congestionamento de TCP do kernel valem a pena?