Perguntas mais freqüentes sobre FreeBSD 2.X, 3.X e 4.X
Anterior |  | Próxima

# Capítulo 14. PPP

14.1. Não consigo fazer meu ppp(8) funcionar. O que estou fazendo de errado?
14.2. Por que o ppp(8) fica pendurado quando eu o inicializo?
14.3. Porque o ppp(8) não disca em modo`-auto`
14.4. O que `No route to host` significa?
14.5. Porque minha conexão cai depois de (em média) 3 minutos?
14.6. Por que minha conexão cai quando está sobrecarregada?
14.7. Por que minha conexão cai após um período aleatório de tempo?
14.8. Por que minha conexão fica pendurada depois de um período aleatório de tempo?
14.9. A extremidade remota não está respondendo. O que eu posso fazer?
14.10. O ppp(8) está travado. O que eu posso fazer?
14.11. Por que não acontece nada depois da mensagem Login OK!?
14.12. Eu vejo os mesmos erros sobre `magic is the same`. O que significa?
14.13. As negociações LCP continuam até que a conexão seja fechada. O que está errado?
14.14. Por que o ppp(8) trava logo apó a conexão?
14.15. Por que o ppp(8) trava quando executo comandos shell pelo ppp(8)?
14.16. Como uma conexão por ppp(8) usando um nunca termina?
14.17. Por que o ppp(8) disca sem nenhuma razão no modo -auto?
14.18. O que estes erros de CCP significam?
14.19. Por que o ppp(8) trava durante a transferência de arquivo com erros de IO(Input/Output)?
14.20. Por que o ppp(8) não loga minha velocidade de conexão?
14.21. Por que o ppp(8) ignora o caracter `\` no meu script de conversação?
14.22. Por que o ppp(8) dá um seg-fault, mas eu não vejo nenhum arquivo `ppp.core`?
14.23. Por que o processo que força a discagem em auto mode nunca conecta?
14.24. Por que a maioria dos jogos não funciona com a opção -nat?
14.25. Alguém fez uma lista de número de portas úteis?
14.26. O que são erros FCS?
14.27. Por que a conexão do MacOS e Windows98 travam ao rodar o PPPoE no gateway?
14.28. Nada disso me ajudou - Eu estou desesperado! O que eu posso fazer?

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

Deve-se primeiro ler a man page do ppp(8) e seção PPP do Manual do FreeBSD. Habilite os logs com o comando

    set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando pode ser digitado no prompt do ppp(8) ou pode ser colocado no `/etc/ppp/ppp.conf` (A seção `default` no início do arquivo é o melhor lugar para colocar isso). Tenha certeza de que seu`/etc/syslog.conf` (veja syslog.conf(5)) tenha as linhas

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

e que o arquivo `/var/log/ppp.log` exista. Agora pode-se ver o que está acontecendo analisando seu arquivo de log. Não se preocupe se isso não faz sentido mas se precisar de ajuda, esta informação fará sentido a eles.

Se a sua versão do ppp(8) não suporta o comando set log ,deve-se fazer o download da versão mais recente. O FreeBSD 2.1.5 (e posteriores) suporta a compilação do código mais recente.

14.2. Por que o ppp(8) fica pendurado quando eu o inicializo?

Isso normalmente acontece porque seu hostname não esta sendo resolvido. A melhor maneira de corrigir isso é certificar-se de que o `/etc/hosts` está sendo consultado pelo resolvedor; editando primeiro o `/etc/host.conf` e colocando `hosts` na primeira linha. Para isso, simplesmente adicione no `/etc/hosts/` uma entrada para sua máquina local. Se não tem nenhuma rede local, mude a linha do `localhost`:

    127.0.0.1        foo.example.com foo localhost

Senão, adicione uma outra entrada para seu host. Consulte as man pages relevantes para maiores detalhes.

Ao terminar, deve ser possível dar um `ping -c1 `nomedohost`` com sucesso.

14.3. Porque o ppp(8) não disca em modo`-auto`

Primeiro verifique se há uma rota padrão. Ao executar um `netstat -rn` (veja netstat(1)), devem aparecer duas entradas como essas:

    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

Assume-se o uso do endereço recomendado pelo Manual do FreeBSD, páginas de manual ou no arquivo ppp.conf.sample. Se a rota padrão não foi definida, é possível que a versão do ppp(8) seja antiga, uma vez que não entendem a palavra `HISADDR` no arquivo ppp.conf. Se a versão do seu FreeBSD for anterior a 2.2.5, mude a linha

    add 0 0 HISADDR

para

    add 0 0 10.0.0.2

Outra razão para a rota padrão estar ausente, pode ser porquê você equivocadamente definiu uma rota default em seu arquivo `/etc/rc.conf` (veja rc.conf(5)) (este arquivo era chamado `/etc/sysconfig` nas versões anteriores a 2.2.2) e omitiu a linha

    delete ALL

no `ppp.conf`. Se este for o problema, volte para seção de configurações Finais do Manual do FreeBSD.

14.4. O que `No route to host` significa?

Este erro é causado pela falta das linhas

    MYADDR:
      delete ALL
      add 0 0 HISADDR

no seu arquivo `/etc/ppp/ppp.linkup`. Isso somente é necessário se você tem um IP dinâmico ou não sabe o endereço do seu gateway. Se você esta usando o modo interativo, pode-se digitar o seguinte, depois de ter entrado no `modo packet` (O modo packet é indicado pelo PPP maiísculo no prompt):

    delete ALL
    add 0 0 HISADDR

Consulte a seção PPP e Endereços IPs dinâmicos do Manual do FreeBSD para maiores detalhes

14.5. Porque minha conexão cai depois de (em média) 3 minutos?

O default timeout do PPP é de 3 minutos. Isso pode ser ajustado com a linha

    set timeout NNN

Onde NNN é o número em segundos de inatividade antes da conexão ser fechada. Se `NNN` é zero a conexão nunca será fechada devido a um timeout. É possível colocar esse comando no `ppp.conf` ou digitá-lo no modo interativo. Também é possível que isso seja ajustado enquanto sua conexão esta ativa conectando pelo socket do servidor ppp usando telnet(1) ou pppctl(8). Consulte a man page do ppp(8) para maiores detalhes.

14.6. Por que minha conexão cai quando está sobrecarregada?

Se você tem o relatório da qualidade da ligação (opção LPR) configurado é possível que muitos pacotes LQR entre sua máquina e a origem estejam sendo perdidos. O ppp deduz que sua linha deve ser ruim e desconecta. Antes da versão 2.2.5 do FreeBSD, o LQR era habilitado por default. Agora ele é desabilitado por default. O LQR pode ser desabilitado com a linha

    disable lqr

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

Às vezes, em uma linha telefônica com ruídos, ou quando a linha tem espera de ligações, seu modem pode desligar, pensando (incorretamente) que perdeu o sinal de linha.

Existem ajustes em grande parte dos modems determinando o quão tolerante ele deve ser a respeito de perdas de sinal de linha. No USR Sportster, por exemplo, isso é medido pelo registrador S10 em décimos de segundo. Para fazer com que seu modem não caia, poderia-se adicionar a seguinte string dial up para envio/espera:

    set dial "...... ATS10=10OK......"

Consulte o manual do seu modem para detalhes.

14.8. Por que minha conexão fica pendurada depois de um período aleatório de tempo?

Muitas pessoas experimentam conexões presas sem aparentemente nenhuma explicação.

Se você usa um modem externo, você simplesmente pode tentar um ping(8) para ver se a luz TD fica piscando quando você transmite dados. Se piscar (e a luz do RD não), o problema é com a extremidade remota. Se o TD não piscar, o problema é local. Com um modem interno você precisará usar o comando `set server` no seu arquivo ppp.conf. Quando ocorrer de cair, conecte com o ppp(8) usando o pppctl(8). Se a conexão de sua rede voltar de repente (o ppp voltou devido a atividade no diagnóstico do socket) ou se você não consegue conectar (assumindo que o comando `set socket` foi iniciado com sucesso) o problema é local. Se você puder conectar e ainda as coisas estiverem "penduradas" habilite os logs do async local com o comando `set log local async` e use o ping(8) de outra janela ou terminal para forçar a atividade da conexão. Os logs async irão mostrar os dados que estão sendo transmitidos e recebidos durante a ligação. Se os dados estão indo e não estão voltando, o problema é remoto.

Tendo estabelecido que o problema é local ou remoto, você tem agora duas possibilidades:

- Se o problema é remoto, leia a secção P: 14.9..

- Se o problema for remoto, leia a secção P: 14.10..

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

Há muito pouco que pode ser feito em relação a isso. A maioria dos provedores irão recusar ajuda-lo se você não usar o Windows. Você pode habilitar a `lqr` no seu arquivo `ppp.conf`, permitindo ao ppp(8) detectar a falha remota e desligar-se, mas essa detecção é relativamente lenta e consequentemente inútil. Pode-se querer evitar dizer ao seu provedor que você está rodando o user-ppp....

Primeiro tente desabilitar toda compressão local adicionando o seguinte em sua configuração:

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

Então reconecte para assegurar de que isso não fez diferença. Se as coisas melhoraram ou se o problema foi resolvido completamente, determine quais ajustes fizeram a diferença através de tentativas e erros. Isto fornecerá uma boa cartada quando você contactar seu provedor (embora possa parecer que você não esteja rodando um produto Microsoft).

Antes de contactar seu provedor, habilite o log async localmente e aguarde até que sua conexão caia novamente. Isto pode usar um bocado de espaço em disco. A última leitura de dados da porta pode ser de seu interesse. São geramente dados em ascii, e podem mesmo descrever o problema (Memory fault, core dumped?).

Se seu provedor for prestativo, ele deve ser capaz de habilitar o log da extremidade da conexão dele, então quando a proxima queda de link ocorrer, eles podem ser capazes de dizer porque o seu lado esta tendo problemas. Sinta-se livre para enviar os detalhes para Brian Somers `<brian@FreeBSD.org>` ou peça para seu provedor contactá-lo diretamente.

14.10. O ppp(8) está travado. O que eu posso fazer?

A melhor coisa a fazer aqui é recompilar o ppp(8) adicionando `CFLAGS+=-g` e `STRIP=` no final do Makefile, depois faça `make clean && make && make install`. Quando o ppp(8) ficar travado, procure o id do processo com um `ps ajxww | fgrep ppp` e execute `gdb ppp` PID. No prompt do gdb você pode então usar o `bt` para obter um rastreamento da pilha.

Envie os resultados para: `<brian@Awfulhak.org>`.

14.11. Por que não acontece nada depois da mensagem Login OK!?

Antes da versão 2.2.5 do FreeBSD, uma vez que a conexão foi estabelecida, o ppp(8) espera que o modem remoto inicie o protocolo do controle de linha (LCP), Muitos provedores não iniciarão a negociação e esperarção que o cliente a faça. Para forçar o ppp(8) para iniciar o LCP, use a seguinte linha:

    set openmode active

> Nota: Nota: isto geralmente não prejudica em nada se a negociação for iniciada por ambos os lados, assim, a opção openmode é agora ativada por padrão. Entretanto, na próxima seção será explicado quando isso realmente proporciona algum problema.

14.12. Eu vejo os mesmos erros sobre `magic is the same`. O que significa?

Ocasionalmente, depois da conexão, você pode ver mensagens no log dizendo "magic is the same". Às vezes essas mensagens são sem importância e as vezes um lado ou o outro sai. A maioria das implementações do ppp não consegue continuar com esse problema, e mesmo se a conexão estiver para ser estabelecida, você verá repetidas requisições de configuração e reconhecimentos de configuração no arquivo de log até que o ppp(8) eventualmente desista e feche a conexão.

Isto normalmente acontece em máquinas com discos lentos que estão dando spawning getty na porta e executam o ppp(8) através de um login script ou programa depois do login. Eu também ouvi relatórios disso estar acontecendo consistentemente ao usar slirp. A razão é que no tempo entre saída do getty(8) e a inicialização do ppp(8), o ppp(8) do lado cliente começa a emitir pacotes do protocolo do controle da linha LCP). Porque o ECHO ainda esta ligado na porta do servidor, o cliente então vê esses pacotes serem refletidos de volta.

Uma parte da negociação LCP deve estabelecer um número mágico para cada lado da ligação de modo que as reflexões possam ser detectadas. O protocolo diz que quando um ponto tenta negociar o mesmo número mágico, um NAK deve ser emitido e um novo número mágico deve ser escolhido. Durante o período que a porta do server tem o ECHO ligado, o ppp(8) cliente manda pacotes LCP, vê o mesmo número mágico nos pacotes refletidos e manda NAKs a ele. Ve-se também o NAK que foi refletido (que significa que o ppp(8) deve mudar o seu número mágico). Isto produz um número potencialmente enorme de mudanças de números mágicos que estão sendo empilhados no buffer do tty do servidor. Tão logo o ppp(8) se inicia no servidor, ele é inundado com mudanças de números mágicos imediatamente ao negociar o LCP, e desiste. Enquanto isso, o cliente não vê por muito tempo as reflexões e fica feliz apenas por algum tempo, até receber a desconexão do servidor.

Isto pode ser evitado permitindo que a negociação seja iniciada pelo servidor (peer), adicionando a seguinte linha no seu arquivo ppp.conf:

    set openmode passive

Isso diz ao ppp(8) para esperar que o servidor inicie as negociações LCP. Alguns servidores, entretanto, podem nunca iniciar as negociações. Se este for o caso, você deve fazer algo como:

    set openmode active 3

Isto diz ao ppp(8) para ser passivo durante 3 segundos, e então começar a enviar requisições LCP. Se o servidor (peer) começar a enviar requisições durante esse período, o ppp(8) irá responder imediatamente, ao invés de aguardar pelo período completo de 3 segundos.

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

Há atualmente uma característica faltando no ppp onde ele não associa respostas LCP , CCP & IPCP com suas requisições originais. Como consequência, se uma implementação ppp é 6 segundos mais lenta do que o outro lado, esse lado emitirá duas requisões adicionais de configuração LCP. Isto é fatal.

Considere duas implementações, `A` e `B`. `A` emite requisições LCP imediatamente após a conexão e `B` leva 7 segundos para iniciar. Quando `B` inicia, `A` emitiu 3 LCP REQs. Nós estamos supondo que a linha ECHO esteja desabilitada, senão nós veríamos problemas com número mágico como descritos na seção anterior. `B` emite um REQ, entao um ACK para o primeiro dos REQs de `A`. Isto resulta em `A` entrando no estado OPENED e enviando um ACK (o primeiro) de volta a `B`. Enquanto isso, `B` envia de volta mais dois ACKs em resposta aos dois REQs adicionais enviados por `A` antes de `B` ter iniciado. `B` então recebe o primeiro ACK de `A` e também entra no estado de OPENED. `A` recebe o segundo ACK de `B` e retorna ao estado de REQ-SENT, enviando um outro (seguinte) REQ conforme a RFC ordena. Então, recebe o terceiro ACK e entra no estado OPENED. Enquanto isso, `B` recebe REQ (posterior) de `A`, tendo como resultado uma reversão para o estado ACK-SENT e enviando um outro (segundo) REQ e (depois) ACK conforme a RFC. Conseguindo o REQ, `A` entra em REQ-SENT e envia outro REQ. Imediatamente recebe o ACK seguinte e entra em OPENED.

Isto continuará até que um dos lados descubra que eles não estão indo a lugar algum e desista.

A melhor maneira de evitar isso é configurar um lado para ser `passivo` - isso faz com que um lado espere pelo outro para iniciar uma negociação. Isto pode ser feito com o comando

    set openmode passive

Deve-se ter cuidado com esta opção. Você também deve usar o comando

    set stopped N

para limitar a quantidade de tempo que o ppp(8) esperará pelo outro lado iniciar a negociação. Alternativamente o comando

    set openmode active N

(onde `N` é o número de segundos para esperar antes de iniciar as negociações) pode ser usado. Consulte as páginas de manual para detalhes.

14.14. Por que o ppp(8) trava logo apó a conexão?

Antes da versão 2.2.5 do FreeBSD, era possível que sua ligação fosse desabilitada logo após a conexão, devido a incapacidade de negociação da compressão Predictor1 do ppp(8). Isto aconteceria somente se ambos os lados tentassem negociar protocolos diferentes do controle da compressão (CCP). Este problema atualmente esta corrigido, mas se você ainda roda uma versão antiga do ppp(8), o problema pode ser resolvido com a linha:

    disable pred1

14.15. Por que o ppp(8) trava quando executo comandos shell pelo ppp(8)?

Quando executa-se o `shell` com o comando `!` , o ppp(8) executa um shell (ou se você passar quaisquer argumentos, o ppp(8) executará aqueles argumentos). Ppp aguardará o comando terminar antes de continuar. Se você tentar usar a sua ligaço ppp enquanto é executado o comando, a ligação aparacerá congelada. Isto porque o ppp estará esperando pelo finalização da comando.

Se você desejar executar comandos assim, use o comando `!bg`. Ele executará o comando em background e o ppp(8) poderá continuar a servir a conexão normalmente.

14.16. Como uma conexão por ppp(8) usando um nunca termina?

Não há nenhuma maneira para que o ppp(8) determine automaticamente que uma conexão direta caiu. Isto é devido às linhas que são usadas na série de cable null modems. Ao usar esse tipo de conexão o LQR deve sempre ser habilitado com a linha:

    enable lqr

A LQR é aceita por padrão, se negociada com o outro lado.

14.17. Por que o ppp(8) disca sem nenhuma razão no modo -auto?

Se o ppp(8) esta discando inesperadamente, você deve determinar a causa, e setar os filtros de discagem (dfilters) para evitar esse comportamento.

Para determinar a causa, use a seguinte linha:

    set log +tcp/ip

Isto registrará todo o tráfego através da conexão. A próxima vez que a linha acima for ativada, você verá a razão logada.

Você pode agora desabilitar a discagem sob estas circunstâncias. Geralmente, este tipo de problema ocorre devido aos lookups do DNS. Para evitar que os lookups do DNS estabeleçam uma conexão (isto não impedirá que o ppp(8) passe os pacotes através de uma conexão já estabelecida) 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

Nem sempre isso é apropriado, porque irá interromper suas capacidades de discagem por demanda - a maioria dos programas precisarão de lookup do DNS antes de fazer alguma outra coisa relacionada a rede.

No caso do DNS, você deve tentar determinar o que esta realmente tentando resolver um hostname. Na maioria das vezes o sendmail(8) é o culpado. Você deve certificar-se que o sendmail não deve fazer nenhum DNS lookup em seu arquivo de configuração. Veja na seção Configuração de Mail para detalhes de como criar seu próprio arquivo de configuração e o que deve conter nele. Você pode também adicionar a seguinte linha ao seu arquivo `.mc`:

    define(`confDELIVERY_MODE', `d')dnl

Isto fará o sendmail enfileirar tudo, até que a fila esteja funcionando (normalmente o sendmail é invocado com `-bd -q30m`, dizendo a ele para rodar a fila (queue) a cada 30minutos) ou até que o `sendmail` -q seja feito (talvez do arquivo ppp.linkup)

14.18. O que estes erros de CCP significam?

Eu estou vendo os seguintes erros em meus logs:

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

Isto é porque o ppp(8) esta tentando negociar a compressão Predictor1, e o outro ponto não quer negociar nenhuma compressão. As mensagens são inofensivas, mas se você desejar remove-las, poderá desabilitar a compressão Predictor1 também localmente:

    disable pred1

14.19. Por que o ppp(8) trava durante a transferência de arquivo com erros de IO(Input/Output)?

No FreeBSD 2.2.2 e anteriores, havia um bug no driver tun, que impedia pacotes de entrada de um tamanho maior do que o MTU da interface. O O recebimento de pacotes maiores que o MTU da interface resulta em erro de IO que é logado através do syslogd.

A especificação do ppp diz que um MTU de 1500 deve ser sempre aceito como mínimo. Apesar de todas as negociações de LCP, é possível diminuir o MTU para menos de 1500, independentemente disso, seu provedor irá transmitir pacotes de 1500 para você, e isso travará sua conexão.

O problema pode ser contornado por nunca ajustar um MTU menor que 1500 sobre o FreeBSD 2.2.2 ou anteriores.

14.20. Por que o ppp(8) não loga minha velocidade de conexão?

A fim de logar todas as linhas de conversação de seu modem você deve habilitar o seguinte:

    set log +connect

Isto irá fazer o ppp(8) logar tudo, até a ultima requisição expect.

Se você desejar ver sua velocidade de conexão e estiver usando PAP ou CHAP (e consequentemente não tenha qualquer coisa para o chat depois do CONNECT no script de discagem - no `set login` script), você deve certificar-se que instruiu o ppp(8) a ``a esperar" a linha inteira CONNECT, algo como:

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

Aqui nosso CONNECT, não envia nada, ele espera então um line-feed, forçando o ppp(8) a ler toda a resposta do CONNECT.

14.21. Por que o ppp(8) ignora o caracter `\` no meu script de conversação?

O Ppp analiza cada linha no seu arquivo de configuração, então isso pode ser interpretado como string tal como `set phone "123 456 789"` corretamente e compreende de fato que o número é um único argumento. A fim de especificar um caracter`"`, você deve escapar desse comportamento, usando um a barra invertida `\`.

Quando o script de conversação analizar cada argumento, ele reinterpretará o argumento a fim de encontrar quaisquer sequências especiais como `\P` ou `\T` (veja a man page). Como resultado desta dupla análise, você deve conseguir usar o número correto de espaços.

Se você deseja enviar um caracter `\` para dizer a seu modem, você precisará de algo assim:

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

resultando a seguinte sequência:

    ATZ
    OK
    AT\X
    OK

ou

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

resultando na seguindo sequência:

    ATZ
    OK
    ATDT1234567

14.22. Por que o ppp(8) dá um seg-fault, mas eu não vejo nenhum arquivo `ppp.core`?

O Ppp (ou qualquer programa desta natureza) nunca dever dar core dump. Porque o ppp(8) roda com um e-userid (effective user id) 0, o sistema operacional não irá escrever a imagem do core do ppp(8) em disco antes de terminá-lo. Mas se acontecer de o ppp(8) terminar devido a uma falha de segmentação ou algum outro sinal que normalmente causaria um core dumped, e você tem certeza de que esta usando uma versão mais recente do ppp (veja o começo desta seção), você deve fazer o seguinte:

    % tar xfz ppp-*.src.tar.gz
    % cd ppp*/ppp
    % echo STRIP= >>Makefile
    % echo CFLAGS+=-g >>Makefile
    % make clean all
    % su
    # make install
    # chmod 555 /usr/sbin/ppp

Você agora tem uma versão debugável do ppp(8) instalada. Você precisará ser `root` para rodar o ppp porque todos os seus privilégios foram revogados. Quando você iniciar o ppp(8), tome nota com cuidado de qual era o seu diretório corrente naquele instante.

Agora, quando o ppp(8) receber uma violação de segmento (seg-fault), você terá um arquivo chamado ppp.core. Você deve então fazer o seguinte:

    % su
    # gdb /usr/sbin/ppp ppp.core
    (gdb) bt
    .......
    (gdb) f 0
    ......
    (gdb) i args
    ......
    (gdb) l
    .......

Toda essa informação deve ser dada com a sua pergunta, sendo possível agora diagnosticar o problema.

Se você é familiarizado com o gdb, você pode desejar encontrar alguns outros bits e partes como as que causaram o dump e também os endereços e valores das variáveis revelantes.

14.23. Por que o processo que força a discagem em auto mode nunca conecta?

Este era um problema conhecido na configuração ppp(8) para negociar um IP local dinâmico com o outro ponto no auto mode. Isto foi corrigido na versão mais recente. Procure na man page do ppp(8) por `iface`.

O problema era que quando este programa inicial chamava o connect(2), o número IP da interface tun estava atribuído ao endpoint do soquete. O kernel cria o primeiro pacote de saída e escreve-o no dispositivo tun. O ppp(8) então lê o pacote e estabelece a conexão. Se em consequência da atribuição dinâmica do IP do ppp(8) o endereço da interface for mudado, o endpoint do soquete original será inválido. Todos os pacotes subsequentes emitidos ao outro ponto serão geralmente descartados. Mesmo se não forem descartados, nenhuma das respostas irá voltar pela rota da máquina de origem, isto porque o número IP já não pertence a essa máquina.

Há diversas maneiras teóricas para abordargem desse problema. Seria mais agradável se o ponto reatribuísse, se possível o mesmo número IP `:-)` A versão atual do ppp(8) faz isso, mas a maioria das outras implementações não.

O método mais fácil do nosso lado, seria nunca mudar o número IP da interface tun, mas ao invés disso, mudar todos os pacotes de saída de modo que a origem do número IP é mudada da interface IP para o IP negociado dinâmicamente. Isto é essencialmente o que a opção `iface-alias` na versão mais recente do ppp faz (com a ajuda da libalias(3) e da opção `-nat` do ppp(8)) - esta mantendo endereços anteriores da interface e fazendo NAT do último endereço negociado.

Uma outra alternativa (e provavelmente a mais confiável) seria implementar uma chamada de sistema que mudasse todos os soquetes ligados de um IP para outro. O ppp(8) usaria essa chamada para modificar os soquetes de todos os programas em execução quando um novo endereço IP é negociado. O mesmo sistema de chamadas poderia ser usado por clientes dhcp quando são forçados a religar seus soquetes.

Ainda, outra possibilidade é permitir a interface para ser ativada sem um número IP. Os pacotes de saída seriam dados um número IP 255.255.255.255 até que a primeira SIOCAIFADDR ioctl esteja pronta. Isto resultaria na completa ligação com o soquete. Seria até o ppp(8) mudar o número IP de origem, mas somente se foi setado para 255.255.255.255, e somente o número IP e o IP checksum deveriam ser mudados. Isto porém, é um pequeno hack do kernel que deve estar enviando maus pacotes para uma interface configurada, na suposição de que algum outro mecanismo é capaz de corrigir as coisas de forma restrospectiva.

14.24. Por que a maioria dos jogos não funciona com a opção -nat?

A razão para os jogos e outros programas não funcionarem quando a libalias esta em uso é porque a máquina de fora irá tentar abrir uma conexão ou enviar pacotes UDP (não solicitados) para a máquina de dentro. O software NAT não sabe que deve enviar esses pacotes para a máquina interna.

Para que as coisas funcionem, certifique-se de que a única coisa que esta rodando é o software que você esta tendo problemas, a seguir rode o tcpdump na interface tun do gateway ou habilite ppp(8) tcp/ip logging (`set log+tcp/ip`) na gateway.

Quando você iniciar o software, você deve ver pacotes passando através da máquina gateway. Quando alguma coisa volta vindo de fora, será descartado (este é o problema). Tome nota do número da porta desses pacotes e a seguir feche o software. Faça isso algumas vezes para ver se os números da porta são consistentes. Se eles forem, a seguinte linha no `/etc/ppp/ppp.conf` fará o software funcional:

    nat port protomáquinainterna:
    portaporta

Onde `proto` é ou `tcp` ou `udp`, `máquinainterna` é a máquina de onde você quer que os pacotes sejam enviados e `porta` é número da porta de destino dos pacotes.

Você não poderá usar o software em outras máquinas sem mudar o comando acima, e rodar o software em duas máquinas internas ao mesmo tempo é fora de questão - Apesar de tudo, o lado de fora esta vendo toda sua rede interna como sendo somente uma máquina.

Se os números da porta não são consistentes, há ainda mais 3 opções.

1. Enviar o suporte na libalias. Exemplos de 'casos especiais' podem ser encontrados em `/usr/src/lib/libalias/alias_*.c` (`alias_ftp.c` eh um bom tipo de protocolo). Isto geralmente envolve ler determinados pacotes reconhecidos na saída, identificando a instrução que chama a máquina externa para iniciar a conexão de volta para a máquina interna em uma porta (aleatória) específica e setar a rota na tabela de aliases de modo que os pacotes subsequentes saibam para onde ir.

   Esta solução é a mais difícil, mas é a melhor e irá fazer o software trabalhar com múltipla máquinas.

2. Use um proxy. A aplicação poderá suportar sock5 por exemplo, ou (como no caso do cvsup) pode ter uma opção passive que evita sempre requisições feitas pelo outro ponto de volta para a máquina local.

3. Redirecione tudo para a máquina interna usando `nat addr`. Pode-se dizer que essa seja a apelação.

14.25. Alguém fez uma lista de número de portas úteis?

Não ainda, mas a intensão é produzir tal lista (se algum interesse for mostrado). Em cada exemplo, `internal` deve ser substítuido pelo IP da máquina que esta jogando o jogo.

- Asheron's Call

  `nat port udp `internal`:65000 65000`

  Mude manualmente o número da porta dentro do jogo para 65000. Se você começar com um determinado número de máquinas que você deseja jogar atribua uma porta para cada (por ex 65001, 65002, etc) e adicione uma `porta nat` para cada uma.

- Half Life

  `nat port udp `internal`:27005 27015`

- PCAnywhere 8.0

  `nat port udp `internal`:5632 5632`

  `nat port tcp `internal`:5631 5631`

- Quake

  `nat port udp `internal`:6112 6112`

  Alternativamente, você pode querer ir em www.batle.net para dar uma olhada no suporte de proxy do quake.

- Quake 2

  `nat port udp `internal`:27901 27901`

  `nat port udp `internal`:60021 60021`

  `nat port udp `internal`:60040 60040`

- Red Alert

  `nat port udp `internal`:8675 8675`

  `nat port udp `internal`:5009 5009`

14.26. O que são erros FCS?

FCS significa `F`rame `C`heck `S`equence. Cada pacote do ppp tem um checksum anexado para assegurar-se de que os dados que estão sendo recebidos sejam os dados que estão sendo emitidos. Se o FCS de um pacote de entrada estiver incorreto, o pacote sera perdido e a contagem do HDLC FCS é aumentada. Os valores de erro HDLC podem ser mostrados usando o comando `show hdlc`.

Se a sua ligação é ruim ou se o driver serial esta perdendo pacotes), você irá ver ocasionalmente erros FCS. Isto geralmente não é motivo para se preocupar, embora diminua substancialmente os protocolos de compressão. Se você tem um modem externo, certifique-se que seu cabo esteja protegido corretamente de interferências - Isso pode erradicar o problema.

Se sua ligação congelar assim que você conectar e vier um grande número de erros FCS, pode ser porque seu link não esta com o bit 8 limpo. Certifique-se que seu modem não esteja usando o controle de fluxo do software (XON/XOFF). Se o seu datalink deve usar software de controle de fluxo, use o comando `set accmap 0x000a0000` para dizer ao ppp para ignorar os caracteres `^Q` e `^S`.

Uma outra razão para estar vendo muitos erros FCS pode ser que a extremidade remota parou de comunicar com o PPP. Você pode querer habilitar registros `async` neste ponto para determinar se os dados entrantes são realmente um alerta de início de sessão do prompt da shell. Se você tiver um prompt shell na extremidade remota, é possível terminar o ppp(8) sem deixar cair a linha usando o comando `close lcp` (o comando `term` irá reconectar você shell da máquina remota). Se nada em seus logs indicar o porque de sua ligação ter sido terminada, você pode perguntar ao administrador remoto (do seu provedor?) porque a sessão foi terminada.

14.27. Por que a conexão do MacOS e Windows98 travam ao rodar o PPPoE no gateway?

Agradecimentos a Michael Wozniak `<mwozniak@netcom.ca>` por descobrir o problema, e a Dan Flemming `<danflemming@mac.com>` pela solução do Mac:

Isto é devido ao que é chamado de roteador Buraco Negro (Black Hole). MacOS e Windows98 (e talvez outros SO's da Microsoft) envia m pacotes TCP com um tamanho de segmento requisitado muito grande para ser contido em um frame do PPPoE (MTU por default na ethernet é de 1500) e tenha o não fragmento do bit ajustado (default do TCP) e o roteador Telco não esta enviando ICMP deve ser fragmentado de volta ao sitio www que você esta tentando carregar. (Alternativamente o roteador está enviando pacotes ICMP corretamente, mas o firewall no sitio www esta deixando perdê-los). Quando o servidor www esta enviando seus frames que não cabem no pipe do PPPoE o roteador Telco deixa-os perder e sua página não é carregada (algumas páginas gráficas carregam porque são menores que um MSS). Esta parece ser a configuração default da maioria dos Telco PPPoE (somente eles sabem como programar o roteador).

Um maneira de fixar isso é usando o regedit em sua seu Windows 95/98 e adicionar a seguinte entrada de registro:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU

Deve ser uma string com um valor 1436, porque há relatos de que alguns roteadores ADSL são incapazes de tratar os pacotes maiores que esse. Esta chave de registro foi mudada para `Tcpip\Parameters\Interfaces\`ID-para-o-adptador`\MTU` no windows 2000 e tornou-se um DWORD.

Consulte os documentos da Microsoft Q158474 - Windows TCPIP Entradas de registroi e Q120642 - TCPIP & NBT Parametros de configuração para Windows NT para maiores informacoes sobre alterações de MTU no Windows para funcionar com um roteador NAT.

Uma outra possibilidade do regedit sob o Windows 2000 é setar `Tcpip\Parameters\Interfaces\`ID-para-o-adaptador`\EnablePMTUBHDetect` DWORD para 1 como mencionado no documento original da Microsoft 120642 comentado acima.

Infelizmente o MacOS não oferece uma mudança TCP/IP nas configurações da interface. Entretanto, há um software comercial disponível, o OTAdvancedTuner (OT para OpenTransport, a pilha TCP/IP do MacOS) feito pela Sustainable Softworks, ele permite aos usuários customizar as configurações TCP/IP. Os usuários de NAT do MacOS devem selecionar o `ip_interface_MTU` no menu drop-down, colocar `1450` em vez de `1500`, clique na caixa próximo ao `Save as Auto Configure`, e clique em `Make Active`.

Versões mais recentes do ppp(8) (2.3 ou mais recente) tem o comando `enable tcpmssfixup` que irá automaticamente ajustar um valor apropriado ao MSS. Esta facilidade é habilitada por default. Se você for apaixonado pela versão mais antiga do ppp(8) você pode querer dar uma olhada no `port` do tcpmssd.

14.28. Nada disso me ajudou - Eu estou desesperado! O que eu posso fazer?

Se tudo falhar, envie o máximo de informacões que você puder, incluindo seus arquivos de configuração, a forma como está iniciando o ppp(8), os trechos relevantes de seu arquivo de log e a saída do comando `netstat -rn` (antes e depois de conectado) para a lista lista de discussão FreeBSD de perguntas genéricas [English Content/Conteúdo em Inglês] `<freebsd-questions@FreeBSD.org>` ou para o grupo de notícias comp.unix.bsd.freebsd.misc. Alguém deve ajudar a solucionar seu problema.

Anterior | Principal | Próxima
Segurança |  | Comunicações Seriais

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.