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 !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 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: | |
14.3. | Por que o ppp(8) não disca no modo |
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 Outro motivo para a falta da linha de rota padrão é que uma rota padrão foi adicionada ao 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 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 onde | |
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 Tendo estabelecido se o problema é local ou remoto, existem agora duas possibilidades: | |
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 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:
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:
No prompt gdb, use os comandos | |
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 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, 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 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 Alternativamente, o seguinte comando (onde set openmode active Verifique a página de manual para detalhes. | |
14.13. | Por que ppp(8) bloqueia quando eu me deponho a testá-lo? |
Ao usar Para executar comandos como este, use | |
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 |
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 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 | |
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 |
O utilitário ppp analisa cada linha em seus arquivos de configuração para que ela possa interpretar corretamente seqüências de caracteres como Quando o interpretador de conversas analisa cada argumento, ele reinterpreta o argumento para encontrar qualquer sequência especiais escapadas, como Para realmente enviar um caractere 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 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 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 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 |
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>.