Subject: Re: PPP problems on Multia
To: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
From: Greg Oster <oster@cs.usask.ca>
List: port-alpha
Date: 10/18/1996 10:29:26
Chris_G_Demetriou@ux2.sp.cs.cmu.edu writes:
> >Has anyone else encountered PPP problems on a Multia (or any other alpha as
> I
> >doubt if this is Multia specific)?
> >[ ... ]
>
> I seem to recall people mentioning PPP problems in the past.
Yeah, I trolled through the old port-amiga messages, and found mention of
it...
(I *had* read through that just after I got my Multia, but should have checked
again before sending my post...)
> I could definitely believe there are 64-bitness errors in that code...
Well, I've done some more digging into this and have come up with the
following:
1) pppd seems to be working just fine. The problem seems to be at a lower
layer.
2) I turned on the SC_LOG_OUTPKT and SC_LOG_FLUSH flags for the PPP driver.
With those on, I get the following output:
ppp0 output: ff03c021010100180104012802060000000005062c96472407020802
ppp0 output: ff03c021010100180104012802060000000005062c96472407020802
ppp0 output: ff03c021010100180104012802060000000005062c96472407020802
...
(this line repeats once for each LCP sent, and continues until it times out)
The corresponding line in the syslog file is (ignoring the timestamp, etc):
sent [LCP ConfReq id=0x1 <mru 296> <asyncmap 0x0> <magic 0x2c964724> <pcomp>
<accomp>]
I did a detailed analysis of the above ppp0 output lines, and they look 100%
correct (I can mail anyone the detail if they are interested). The data is
consistent with that added by lcp_addci() (in lcp.c) which is called via
fsm_sconfreq() in fsm.c. From there the data goes to fsm_sdata(), where
output() (in sys-bsd.c) is called. The step after that is the write(), which
returns successfully. Since the data is making it to pppdumpm() in
/src/sys/net/if_ppp.c, I'm thinking it's got to be a problem
at a lower level...
3) I guess the next step is to keep following this little packet through the
various layers in the hopes of determining where it's getting lost :-/
Anyone have any ideas as to what's wrong, or where else I might look?
Later...
Greg Oster
oster@cs.usask.ca
Department of Computer Science
University of Saskatchewan, Saskatoon, Saskatchewan, CANADA