On Thu, 31 Jul 2003 11:06:57 -0300 Mario Olimpio de Menezes <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- ^X^C q quit :q ^C end x exit ZZ ^D ? help .
