Capítulo 14. PPP

14.1. Não consigo fazer o ppp(8) funcionar. O que estou fazendo de errado?
14.2. Por que o ppp(8) é interrompido quando eu o executo?
14.3. Por que o ppp(8) não disca no modo -auto?
14.4. O que o erro No route to host significa?
14.5. Por que minha conexão cai depois de 3 minutos?
14.6. Por que minha conexão cai sob carga pesada?
14.7. Por que minha conexão cai depois de um período de tempo aleatório?
14.8. Por que minha conexão cai após um período aleatório de tempo?
14.9. A ponta remota não está respondendo. O que eu posso fazer?
14.10. ppp(8) foi desativado. O que eu posso fazer?
14.11. Eu continuo vendo erros sobre a magia sendo a mesma. O que isso significa?
14.12. As negociações LCP continuam até que a conexão seja encerrada. O que está errado?
14.13. Por que ppp(8) bloqueia quando eu me deponho a testá-lo?
14.14. Por que ppp(8) sobre um cabo de modem nulo nunca finaliza?
14.15. Por que o ppp(8) disca sem motivo no modo -auto?
14.16. O que esses erros de CCP significam?
14.17. Por que o ppp(8) não registra minha velocidade de conexão?
14.18. Por que o ppp(8) ignora o caractere \ no meu script de bate-papo?
14.19. Quais são os erros do FCS?
14.20. Nada disso ajudou - estou desesperado! O que eu posso fazer?

14.1.

Não consigo fazer o ppp(8) funcionar. O que estou fazendo de errado?

Primeiro, leia o ppp(8) e o seção sobre PPP do Handbook. Para ajudar na solução de problemas, ative os logs com o seguinte comando:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando pode ser digitado no prompt de comando ppp(8) ou pode ser inserido no início da seção default do arquivo /etc/ppp/ppp.conf. Certifique-se de que o arquivo /etc/syslog.conf contenha as linhas abaixo e de que o arquivo /var/log/ppp.log exista:

!ppp
*.*        /var/log/ppp.log

Muito sobre o que está acontecendo pode ser aprendido no arquivo de log. Não se preocupe se isso não faz sentido, pois pode fazer sentido para outra pessoa.

14.2.

Por que o ppp(8) é interrompido quando eu o executo?

Geralmente, isso ocorre porque o nome do host não será resolvido. A melhor maneira de corrigir isso é certificar-se de que /etc/hosts seja lido primeiro, garantindo que a linha hosts seja listada primeiro em /etc/host.conf. Em seguida, insira uma entrada em /etc/hosts para a máquina local. Se não houver nenhuma rede local, altere a linha localhost:

127.0.0.1        foo.example.com foo localhost

Caso contrário, adicione outra entrada para o host. Consulte as páginas de manual relevantes para mais detalhes.

Quando terminar, verifique se este comando foi bem sucedido: ping -c1 `hostname`.

14.3.

Por que o ppp(8) não disca no modo -auto?

Primeiro, verifique se existe uma rota padrão. Este comando deve exibir duas entradas:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Se uma rota padrão não estiver listada, certifique-se de que a linha HISADDR foi adicionada ao /etc/ppp/ppp.conf.

Outro motivo para a falta da linha de rota padrão é que uma rota padrão foi adicionada ao /etc/rc.conf e esta linha está faltando no arquivo /etc/ppp/ppp.conf:

delete ALL

Se esse for o caso, volte para seção Configuração final do sistema no Handbook.

14.4.

O que o erro No route to host significa?

Este erro geralmente ocorre porque a seguinte seção está faltando no arquivo /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Isso é necessário apenas para um endereço IP dinâmico ou quando o endereço do gateway padrão é desconhecido. Ao usar o modo interativo, o seguinte pode ser digitado depois de entrar no modo de pacote. O modo de pacote é indicado pelo PPP em letras maiúsculas no prompt:

delete ALL
add 0 0 HISADDR

Consulte a seção Endereços IP dinâmicos e PPP do manual para mais detalhes.

14.5.

Por que minha conexão cai depois de 3 minutos?

O tempo limite padrão do PPP é de 3 minutos. Isso pode ser ajustado com a seguinte linha:

set timeout NNN

onde NNN é o número de segundos de inatividade antes que a conexão seja fechada. Se NNN for zero, a conexão nunca será fechada devido a um tempo limite. É possível colocar este comando em ppp.conf, ou digitá-lo no prompt no modo interativo. Também é possível ajustá-lo rapidamente enquanto a linha está ativa conectando-se ao socket de servidor do ppp usando telnet(1) ou pppctl(8). Consulte a página do manual ppp(8) para obter mais detalhes.

14.6.

Por que minha conexão cai sob carga pesada?

Se o relatório de qualidade de link (LQR) estiver configurado, é possível que muitos pacotes LQR sejam perdidos entre o sistema FreeBSD e o peer. ppp(8) deduz que a linha deve ser ruim e desconectada. O LQR vem desativado por padrão e pode ser ativado com a seguinte linha:

enable lqr

14.7.

Por que minha conexão cai depois de um período de tempo aleatório?

Às vezes, em uma linha telefônica barulhenta ou mesmo em uma linha com a chamada em espera ativada, o modem pode desligar porque acha incorretamente que perdeu conexão com a operadora.

Há uma configuração na maioria dos modems para determinar quão tolerante deve ser a perda temporária de conexão com portadora. Consulte o manual do modem para detalhes.

14.8.

Por que minha conexão cai após um período aleatório de tempo?

Muitas pessoas experimentam conexões pendentes sem explicação aparente. A primeira coisa a estabelecer é de que lado do link está pendurado.

Ao usar um modem externo, tente usar ping(8) para ver se a luz de TD está piscando quando os dados são transmitidos . Se piscar, mas a luz de RD não, o problema é com a extremidade remota. Se TD não piscar, o problema é local. Com um modem interno, use o comando set server em ppp.conf. Quando o problema ocorrer, conecte-se ao ppp(8) usando pppctl(8). Se a conexão de rede reviver repentinamente devido à atividade no socket de diagnóstico ou se não se conectar, mas o comando set socket for bem-sucedido na inicialização, o problema é local. Se ele puder se conectar, mas as coisas ainda estiverem travadas, ative o log local com set log local async e use ping(8) de outra janela ou terminal para fazer uso do link. O registro assíncrono mostrará os dados sendo transmitidos e recebidos no link. Se os dados estão saindo e não voltando, o problema é remoto.

Tendo estabelecido se o problema é local ou remoto, existem agora duas possibilidades:

  • Se o problema for remoto, leia a entrada P: 14.9.

  • Se o problema é local, leia a entrada P: 14.10.

14.9.

A ponta remota não está respondendo. O que eu posso fazer?

Há muito pouco que pode ser feito sobre isso. Muitos ISPs recusam-se a ajudar usuários que não estejam executando um SO da Microsoft®. Adicione enable lqr ao /etc/ppp/ppp.conf, permitindo ppp(8) para detectar a falha remota e desligar. Essa detecção é relativamente lenta e, portanto, não é tão útil.

Primeiro, tente desativar toda a compactação local adicionando o seguinte à configuração:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Em seguida, reconecte para garantir que isso não faz diferença. Se as coisas melhorarem ou se o problema for resolvido completamente, determine qual configuração faz a diferença através de tentativa e erro. Esta é uma boa informação para o ISP, embora possa tornar aparente que não é um sistema Microsoft®.

Antes de entrar em contato com o ISP, ative o registro assíncrono localmente e aguarde até que a conexão seja interrompida novamente. Isso pode usar um pouco de espaço em disco. Os últimos dados lidos da porta podem ser de interesse. Geralmente são dados ASCII e podem até descrever o problema (Memory fault, Core dumped).

Se o ISP for útil, eles devem ser capazes de habilitar o log em sua finalização, então quando o próximo link falhar, eles poderão dizer por que seu lado está tendo um problema.

14.10.

ppp(8) foi desativado. O que eu posso fazer?

Nesse caso, reconstrua o ppp(8) com informações de depuração e, em seguida, use gdb(1) para pegar um rastrear uma pilha do processo ppp que está travado. Para reconstruir o utilitário ppp com informações de depuração, digite:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Em seguida, reinicie o ppp e espere até que ele seja interrompido novamente. Quando a compilação de depuração do ppp é interrompida, inicie o gdb no processo travado digitando:

# gdb ppp `pgrep ppp`

No prompt gdb, use os comandos bt ou where para obter um rastreamento de pilha. Salve a saída da sessão gdb e desconecte do processo em execução, digitando quit .

14.11.

Eu continuo vendo erros sobre a magia sendo a mesma. O que isso significa?

Ocasionalmente, logo após a conexão, pode haver mensagens no log que digam que Magic é o mesmo. Às vezes, essas mensagens são inofensivas e, às vezes, um lado ou outro termina. A maioria das implementações do PPP não pode sobreviver a esse problema, e mesmo se o link aparecer, haverá solicitações de configuração repetidas e configuração de reconhecimentos no arquivo de log até que o ppp(8) eventualmente desiste e fecha a conexão.

Isso normalmente acontece em máquinas servidor com discos lentos que estão gerando um getty(8) na porta e executando ppp(8) a partir de um script de login ou programa após o login. Houve relatos de que isso acontecia de forma consistente ao usar slirp. A razão é que no tempo entre getty(8) terminar e o ppp(8) iniciar, o cliente ppp(8) inicia o envio de pacotes do protocolo de controle de linha (LCP). Como o ECHO ainda está ligado à porta do servidor, o cliente ppp(8) vê esses pacotes sendo refletidos de volta.

Uma parte da negociação do LCP é estabelecer um número mágico para cada lado do link para que as reflexões possam ser detectadas. O protocolo diz que quando o parceiro tenta negociar o mesmo número mágico, um NAK deve ser enviado e um novo número mágico deve ser escolhido. Durante o período em que a porta do servidor tem o ECHO ligado, o cliente ppp(8) envia pacotes LCP, vê o mesmo numero mágica no pacote refletido e reflete o NAK. Ele também vê a reflexão NAK (que também significa que o ppp(8) deve mudar seu numero magico). Isso produz um número potencialmente enorme de mudanças no número mágico, todas as quais estão se acumulando alegremente no buffer tty do servidor. Assim que ppp(8) é iniciado no servidor, ele é inundado com alterações de numeros mágicos e quase imediatamente decide que tentou o suficiente para negociar LCP e desiste. Enquanto isso, o cliente, que não vê mais as reflexões, fica feliz a tempo de ver um desligamento do servidor.

Isto pode ser evitado permitindo que o par comece a negociar com a seguinte linha em ppp.conf:

set openmode passive

Isto diz ao ppp(8) para esperar que o servidor inicie as negociações do LCP. Alguns servidores, no entanto, nunca podem iniciar negociações. Nesse caso, tente algo como:

set openmode active 3

Isso informa ao ppp(8) para ser passivo por 3 segundos e, em seguida, para iniciar o envio de solicitações de LCP. Se o peer começar a enviar pedidos durante este período, ppp(8) responderá imediatamente, em vez de esperar pelo período completo de 3 segundos.

14.12.

As negociações LCP continuam até que a conexão seja encerrada. O que está errado?

Há atualmente uma implementação incorreta no ppp(8) onde ele não associa LCP, CCP & Respostas IPCP com seus pedidos originais. Como resultado, se uma implementação de PPP for mais de 6 segundos mais lenta do que o outro lado, o outro lado enviará duas solicitações adicionais de configuração de LCP. Isso é fatal.

Considere duas implementações, A e B. A começa a enviar solicitações LCP imediatamente após a conexão e B leva 7 segundos para iniciar. Quando B é iniciado, A enviou 3 LCP REQs. Estamos supondo que a linha esteja com ECHO desligado, caso contrário, veríamos problemas com números mágicos conforme descrito na seção anterior. B envia um REQ e, em seguida, um ACK para o primeiro dos REQs de A. Isso resulta em A inserindo o estado OPENED e enviando e ACK (o primeiro) de volta para B. Enquanto isso, B envia de volta mais dois ACKs em resposta aos dois REQs adicionais enviados por A antes de B ser iniciado. B recebe o primeiro ACK de A e entra no estado OPENED. A recebe o segundo ACK de B e retorna ao estado de REQ-SENT, enviando outro (adiante) REQ de acordo com o RFC. Em seguida, recebe o terceiro ACK e entra no estado OPENED. Enquanto isso, B recebe o quarto REQ de A, resultando na sua reversão para o estado ACK-SENT e enviando outro (segundo) REQ e (adiante) ACK de acordo com o RFC. A obtém o REQ, entra em REQ-SENT e envia outro REQ. Ele recebe imediatamente o seguinte ACK e insere OPENED.

Isso continua até que um lado conclui que eles estão chegando a lugar nenhum e desiste.

A melhor maneira de evitar isso é configurar um lado para ser passivo - isto é, fazer um lado esperar que o outro comece a negociar. Isso pode ser feito com o seguinte comando:

set openmode passive

Deve ser tomado cuidado com esta opção. Este comando também pode ser usado para limitar a quantidade de tempo que o ppp(8) aguarda que o par inicie as negociações:

set stopped N

Alternativamente, o seguinte comando (onde N é o número de segundos a aguardar antes de iniciar as negociações) pode ser usado:

set openmode active N

Verifique a página de manual para detalhes.

14.13.

Por que ppp(8) bloqueia quando eu me deponho a testá-lo?

Ao usar shell ou !, ppp(8) executa um shell ou os argumentos passados. O programa ppp aguardará a conclusão do comando antes de continuar. Qualquer tentativa de usar o link PPP durante a execução do comando aparecerá como um link congelado. Isso ocorre porque ppp(8) está aguardando a conclusão do comando.

Para executar comandos como este, use !bg. Isso executará o comando fornecido em segundo plano e ppp(8) pode continuar a fornecer o link.

14.14.

Por que ppp(8) sobre um cabo de modem nulo nunca finaliza?

Não há nenhuma maneira do ppp(8) determinar automaticamente que uma conexão direta foi eliminada. Isso se deve às linhas usadas em um cabo serial de modem nulo. Ao usar esse tipo de conexão, o LQR deve estar sempre ativado com a seguinte linha:

enable lqr

O LQR é aceito por padrão se negociado pelo par.

14.15.

Por que o ppp(8) disca sem motivo no modo -auto?

Se o ppp(8) estiver discando inesperadamente, determine a causa e configure os filtros de discagem para evitar que isso ocorra.

Para determinar a causa, use a seguinte linha:

set log +tcp/ip

Isso registrará todo o tráfego através da conexão. Na próxima vez que a linha conectar inesperadamente, o motivo será registrado e terá um carimbo conveniente com a data e hora ao lado dele.

Em seguida, desative a discagem nessas circunstâncias. Geralmente, esse tipo de problema surge devido a pesquisas de DNS. Para impedir que as pesquisas de DNS estabeleçam uma conexão (isso não impedirá que o ppp(8) passe os pacotes através de um diretório estabelecido) conexão), use o seguinte:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Isso nem sempre é adequado, já que efetivamente quebra os recursos de discagem por demanda. A maioria dos programas precisará de uma pesquisa de DNS antes de fazer qualquer outra coisa relacionada à rede.

No caso do DNS, tente determinar o que realmente está tentando resolver um nome de host. A maior parte do tempo, o Sendmail é o culpado. Certifique-se de configurar o Sendmail para não fazer nenhuma pesquisa de DNS em seu arquivo de configuração. Veja a seção sobre usando e-mail com uma conexão discada no manual do FreeBSD para detalhes. Você também pode adicionar a seguinte linha ao .mc:

define(`confDELIVERY_MODE', `d')dnl

Isso fará com que o Sendmail enfileire tudo até que a fila seja executada, normalmente, a cada 30 minutos, ou até que um sendmail -q seja feito, talvez do /etc/ppp/ppp.linkup.

14.16.

O que esses erros de CCP significam?

Eu continuo vendo os seguintes erros no meu arquivo de log:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Isso ocorre porque o ppp(8) está tentando negociar a compactação Predictor1, mas o par não deseja negociar nenhuma compactação. As mensagens são inofensivas, mas podem ser silenciadas desativando a compactação:

disable pred1

14.17.

Por que o ppp(8) não registra minha velocidade de conexão?

Para registrar todas as linhas da conversação do modem, ative o seguinte:

set log +connect

Isso fará com que o ppp(8) registre tudo até a última string expect seja solicitada.

Para ver a velocidade de conexão ao usar o PAP ou o CHAP, certifique-se de configurar ppp(8) para esperar toda a linha CONNECT, usando algo assim:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Isso obtém o CONNECT, não envia nada, então espera um avanço de linha, forçando o ppp(8) a ler toda a resposta CONNECT.

14.18.

Por que o ppp(8) ignora o caractere \ no meu script de bate-papo?

O utilitário ppp analisa cada linha em seus arquivos de configuração para que ela possa interpretar corretamente seqüências de caracteres como set phone "123 456 789" e perceber que o número é realmente apenas um argumento . Para especificar um caractere ", escape-o usando uma barra invertida (\).

Quando o interpretador de conversas analisa cada argumento, ele reinterpreta o argumento para encontrar qualquer sequência especiais escapadas, como \P ou \T. Como resultado dessa análise dupla, lembre-se de usar o número correto de escapes.

Para realmente enviar um caractere \ , faça algo como:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Isso resultará na seguinte seqüência:

ATZ
OK
AT\X
OK

Ou:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Isso resultará na seguinte seqüência:

ATZ
OK
ATDT1234567

14.19.

Quais são os erros do FCS?

FCS significa Sequência de Verificação de Quadro. Cada pacote PPP tem uma soma de verificação anexada para garantir que os dados sendo recebidos sejam os dados que estão sendo enviados. Se o FCS de um pacote de entrada estiver incorreto, o pacote será descartado e a contagem HDLC FCS será aumentada. Os valores de erro HDLC podem ser exibidos usando o comando show hdlc.

Se o link for ruim ou se o driver serial estiver descartando pacotes, ele produzirá o erro ocasional de FCS. Isso geralmente não vale a pena se preocupar, embora deixe substancialmente lento os protocolos de compactação.

Se o link congelar assim que se conectar e produzir um grande número de erros de FCS, verifique se o modem não está usando o controle de fluxo de software (XON/XOFF). Se o link precisar usar o controle de fluxo de software, use set accmap 0x000a0000 para informar o ppp(8) para escapar o ^Q e caracteres ^S.

Outra razão para muitos erros de FCS, pode ser que o terminal remoto parou de falar com PPP. Nesse caso, ative o log do async para determinar se os dados recebidos são realmente um login ou prompt de shell. Se for um prompt de shell no final remoto, é possível terminar o ppp(8) sem eliminar a linha usando close lcp seguido de term) para reconectar ao shell na máquina remota.

Se nada no arquivo de log indicar por que o link foi encerrado, pergunte ao administrador remoto ou ISP por que a sessão foi encerrada.

14.20.

Nada disso ajudou - estou desesperado! O que eu posso fazer?

Se tudo mais falhar, envie os detalhes do erro, os arquivos de configuração, como ppp(8) está sendo iniciado, as partes relevantes no arquivo de log , e a saída de netstat -rn, antes e depois de conectar, para a Lista de discussão de questões gerais do FreeBSD.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.