Capítulo 14. PPP

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.

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.

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.

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

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.

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

À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.

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..

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.

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>.

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

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.

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.

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

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.

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.

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)

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

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.

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.

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

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.

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.

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.

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

FCS significa Frame Check Sequence. 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.

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.

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.