Re: itelefonica

[Christoph Simon <ciccio@kiosknet.com.br>]

On Thu, 31 Jul 2003 11:06:57 -0300
Mario Olimpio de Menezes <mario@curiango.ipen.br> wrote:

> On Thu, Jul 31, 2003 at 10:22:10AM -0300, Christoph Simon wrote:
> > On Thu, 31 Jul 2003 09:54:47 -0300
> > Mario Olimpio de Menezes <mario@curiango.ipen.br> wrote:
> > 
> > >   No PPP-HowTo não consegui encontrar informação sobre o que
> > >   acontece. Abaixo, um pequeno trecho do log:
> > > 
> > > [A] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x61befd0d>
> > > <pcomp> <accomp>][B] rcvd [LCP ConfReq id=0x1 <00 04 00 00> <mru
> > > 1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp> <mrru 1524>
> > > <endpoint [MAC:00:d0:52:01:34:1a]>][C] sent [LCP ConfRej id=0x1 <00
> > > 04> 00 00> <mrru 1524>]
> > 
> > O que parece acontecer é: Primeiro, você manda um conjunto de opções
> > solicitando o peer para aceitar (request) [A]. Mas o peer tem outra
> > idéia das configurações e manda um request para você[B], e você denega
> > (reject) [C]. O que chama a atenção é que o seu request não inclue o
> > pap e o request do peer sim. Será que você não configurou
> > correctamente o pap?
> 
> é estranho, pois o mesmo acontece quando conecto no iG.
> pelo que entendi, o meu ppp rejeita o mru proposto pelo provedor (mru
> 1524); está muito parecido com o que ocorre quando conecto pelo iG:
> 
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8cbe049a> <pcomp>
> <accomp>] rcvd [LCP ConfReq id=0x1 <mru 1514> <asyncmap 0x0> <auth pap>
> <magic 0x2d78971c> <pcomp> <accomp> <mrru 1514> <endpoint [null]>] sent
> [LCP ConfRej id=0x1 <mrru 1514>]
> 
> depois disto, o provedor parece aceitar a minha proposta: 
> (iG e iTelefonica: a linha é a mesma para os dois).
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x8cbe049a> <pcomp>
> <accomp>]
> 
> 
> de qq modo vou tentar subir o mru para o que ele está propondo e ver o 
> que ocorre.
> 

Infelizmente, o Sylpheed destruiu o formateo e agora estou sem vontade
de concertar as linhas de novo.

Parece que errei com a linha ConRej que escolhi (a primeira). Um reject
não necessariamente conduz para um aborto. Talvez tinha sido o outro
reject, no final, "rcvd [CCP ConfRej id=0x2]".

MRRU é "Maximum Reconstructed Receive Unit", uma coisa usada para o
PPP MP (multi link protocol) o que serve por exemplo com ISDN usando
os dois canais B ao mesmo tempo. Não deve confundir MRRU com MRU,
pois, se eu entendi correctamente, a MRU é uma fração da MRRU: MRU é o
máximo que você recebe num pacote e MRRU é a soma dos pacots recebidos
(por mais de uma linha) e reconstruidos. Neste caso, você não solicita
nenhuma MRRU e o peer sim. Como tudo isso continua, eu assumiria que o
Linux aceito o valor do peer e reconfigurou ele mesmo.

CCP é o Compression Control Protocol, provavelmente o jeito como os
dois concordam sobre o algoritmo de compressão. Como é a última coisa
antes de cair a linha, parece que um dos dois não pode viver com essa
situação. Você recebe o reject e fecha. Por tanto acho quem não gosta
disso é o seu linux.

> mas é estranho! realmente parece coisa de configuração feita para
> Windows apenas.

Num caso assim, o que é estranho geralmente só indica que não
entendimos bem a situação. A lindeza dos protocolos na Internet é que
nem a Microsoft pode mudar eles sem quebrar absolutamente tudo. Só
graças a este fato ainda podemos ter redes mixtas com Windows e Unix.

Se você tentou aquilo que outra pessoa sugeriu (colocar um nome de
usuário como se for um endereço de email com domínio; a Terra também
gosta dessa) e não adiantou, eu acho que pode estar relacionado com as
compressões. Eu começaria com a revisão das opções no kernel.

-- 
Christoph Simon
ciccio@kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.