Re: PPP trashed in 2.1.109?

Thomas Molina (tmolina@probe.net)
Sun, 19 Jul 1998 02:08:55 -0500 (CDT)

Is there anything I can contribute to the search for an answer? Far
from the experiences of others I'm seeing rock solid performance of ppp
on 2.1.109. I have RedHat 5.1, monolithic kernel, ppp 2.3.5, and I'm
using the demand dialing feature, which as I've said before, finally
works as advertised for the first time in 2.1.109. I'm not sure what
else might be significant. The only difference might be the fact that I
appear to be one of the few people using monolithic kernels.

On Sat, 18 Jul 1998, Chris Noe wrote:

>
> On Fri, 17 Jul 1998, Bruce A. Locke wrote:
>
> >
> > Hello...
> >
> > As the subject states I believe that PPP in 2.1.109 is trashed. I have
> > spoken to several ppl on irc and have heard a report of one person's kernel
> > "sending fragmented packets from random ip sources". While I have not had
> > this problem, my problem with 2.1.109 is worse... I can't even connect.
> >
> [...]
>
> Grr. I have to take back what I had earlier said about the 2.1.109 ppp
> changes. They are now causing no end of problems here. Observe, it's the
> same exact symptoms that described:
>
> pppd 2.3.5 started by stiker, uid 501
> Serial connection established.
> Using interface ppp0
> Connect: ppp0 <--> /dev/modem
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x2 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x2 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x3 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x3 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x4 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x4 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x5 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x5 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x6 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x6 <asyncmap0x0> <magic 0x8cdee3a2> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap0x0> <magic 0xa6a3cc5a> <pcomp> <accomp>]
> [...]
> LCP: timeout sending Config-Requests
>
> Looks like the new ppp code has a crush on ConfReq 0x1, eh?
>
> Funny thing is though, this only happens after I forcefully kill pppd.
> Everything is fine until 'ppp-off' is run, then it's LCP timeouts in
> their full glory. And it won't work again 'til I reboot.
>
> My crazy guess is that this is a strange interaction between the new
> kernel code, and the old user-space pppd? Will check tonight.
>
> Chris Noe
> (stiker@northlink.com)
>
> --
> ---------------------------------------------------------
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> ---- http://online.offshore.com.ai/arms-trafficker/ -----
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html