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?

2

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 IP estático Aus ISP 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 de 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 a taxa de transferência por burst, mas agrava as paralisações e atrasos
  • Pesquisei extensivamente por soluções (mesmo voltando e lendo as RFCs).
  • Parece que o cabeçalho de VJ foi identificado como problemático 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 do qual parece ter surgido vários protocolos de compactação proprietários nã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?

    
por BrendanMcL 09.05.2018 / 03:51

1 resposta

1

Como resposta parcial à minha própria pergunta, fiz melhorias significativas de confiabilidade por meio do seguinte:

Mudar o plugin do kernel tcp_congestion_control do padrão cúbico para bbr foi endereçado significativamente ao bufferbloat que, junto com uma conexão de rádio com perdas, está no centro do problema.

Isso exigiu o carregamento do módulo de kernel tcp_bbr e também a mudança do modelo de disciplina de enfileiramento net.core para enfileiramento justo para fornecer o ritmo para o módulo bbr.

Nos RPIs, os padrões são:

net.ipv4.tcp_congestion_control = cubic

net.core.default_qdisc = pfifo_fast

Os comandos para alterar isso em tempo de execução são:

modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

Eu atualmente os executo a partir de um script chamado de /etc/rc.local. Eles podem ser facilmente tornados permanentes com modificações em modprode.d e sysctl.conf ou como um arquivo em sysctl.d.

O resultado é uma resposta muito mais suave em relação à ssh e à transferência em massa muito mais confiável, que ainda consegue recuperar rapidamente e ser concluída de forma confiável, retornando ao prompt de comando imediatamente (em vez de pausar em 100% por períodos prolongados - por exemplo 1 - 3 minutos antes de retornar como foi o caso com o controle de congestionamento cúbico).

O trade-off é a velocidade geral, porém a confiabilidade é mais importante. Por exemplo, a transferência de um arquivo 283k através do link de rádio usando scp agora resulta em:

100%  283KB   2.5KB/s   01:51

Este é um compromisso que eu estou feliz o suficiente por agora. No entanto, os processos de transferência em massa de longa duração ainda são problemáticos e, eventualmente, param e nunca são concluídos.

Por exemplo, o apt-get update, rodando por mais de uma hora (paralisando o arquivo de 11.7MB), requer retornos ocasionais através do terminal ssh para continuar rodando, e eventualmente diminuir a latência, embora não falhando todos juntos.

No seguinte raspar de tela, o processo durou mais de 1 hora, com alguns CRs a cada 10-15 minutos e um atraso de aproximadamente 5 minutos entre quando ^ C foi enviado versus o terminal respondendo:

root@priotdev2:~# apt-get update
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian stretch InRelease [15.0 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [145 kB]                                                   
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [30.7 kB]                                                    
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
23% [3 Packages 270 kB/11.7 MB 2%]                                                                            2,864 B/s 1h 6min 15s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
29% [3 Packages 1,263 kB/11.7 MB 11%]                                                                          131 B/s 22h 2min 19s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
60% [3 Packages 5,883 kB/11.7 MB 50%]                                                                        16 B/s 4d 4h 13min 58s
60% [3 Packages 5,902 kB/11.7 MB 51%]                                                                         1,531 B/s 1h 2min 38s
66% [3 Packages 6,704 kB/11.7 MB 58%]                                                                                              

66% [3 Packages 6,704 kB/11.7 MB 58%]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
66% [3 Packages 6,735 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,746 kB/11.7 MB 58%]                                                                          230 B/s 5h 55min 46s

66% [3 Packages 6,747 kB/11.7 MB 58%]                                                                          148 B/s 9h 12min 47s^C
root@priotdev2:~# ^C
root@priotdev2:~# 
root@priotdev2:~# 

Rolando para a direita no dump acima pode ser visto o abismal através de colocar (até 16 e 32 bytes por segundo, em alguns casos).

Para remover as variáveis de ponta a ponta que também envolvem o link do satélite, o processo apt está realmente usando o RPI upstream como um cache do apt (que está atualizado), as transferências representam apenas o tráfego através do link de rádio.

Qualquer esclarecimento da comunidade sobre outras melhorias seria bem-vindo.

    
por 10.05.2018 / 03:49

Tags