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