On Wed, 25 Jun 2003 17:35:49 PDT, Stephen Hemminger said:
> Try this patch, it is more paranoid in some of the code paths.
> I did get PPP over a null modem cable working between 2.4.18 and 2.5.73 with
the PPP patches.
I wasn't able to get this patch to apply cleanly to either the replacement .c
you sent or
to any of the .c's I already had - which version was this based from?
Also, the entire-replacement .c showed the same symptoms of a quick death as
the problem cset from bitkeeper. Here's some more info: In the *working*
version,
the first few lines logged by 'pppd -d' are:
Jun 27 10:02:28 turing-police pppd[999]: Using interface ppp0
Jun 27 10:02:28 turing-police pppd[999]: Connect: ppp0 <--> /dev/ttyS14
Jun 27 10:02:28 turing-police /etc/hotplug/net.agent: NET add event not
supported
Jun 27 10:02:29 turing-police pppd[999]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x7e941686> <pcomp> <accomp>]
Jun 27 10:02:32 turing-police pppd[999]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x7e941686> <pcomp> <accomp>]
(broken version dies here)
Jun 27 10:02:32 turing-police pppd[999]: rcvd [LCP ConfReq id=0xa3 <asyncmap
0xa0000> <auth pap> <magic 0xa55eea11> <pcomp> <accomp>]
Jun 27 10:02:32 turing-police pppd[999]: sent [LCP ConfAck id=0xa3 <asyncmap
0xa0000> <auth pap> <magic 0xa55eea11> <pcomp> <accomp>]
Jun 27 10:02:32 turing-police pppd[999]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x7e941686> <pcomp> <accomp>]
so I'm thinking there's some breakage decoding that next rcvd packet...
My next step is to go through each separate change in the cset that's causing
the
problem and apply it, and see which one breaks it.
pgphh5OMgAx0S.pgp
Description: PGP signature
|