pppclient

[presotto@plan9.att.com presotto@plan9.att.com]

We're the ones that are wrong, sort of.  For the second number 

0 == don't compress connection id (or slot number or whatever you call it)
1 == connection id may be compressed

Our code only knows about the second and rejects compression otherwise.
It would be easy enough easy to change, just remember that the other
requested no compression and change the comparison on line 192 of
compress.l.

However, the foriegn PPP should be accepting the Nak and just
not compressing.  Perhaps we're screwing up the Nak.

I'll leave it up to someone who really uses it do the change.  Noone
here has used the code since a summer student wrote it a few years ago.

------ original message follows ------

>From cse.psu.edu!9fans-outgoing-owner Wed Aug  9 22:58:49 EDT 1995
Received: by psuvax1.cse.psu.edu id <34096>; Wed, 9 Aug 1995 22:37:19 -0400
Received: from plan9.cs.su.oz.au ([129.78.96.33]) by psuvax1.cse.psu.edu with SMTP id <34106>; Wed, 9 Aug 1995 22:29:22 -0400
From:	Boyd Roberts <boyd@plan9.cs.su.oz.au>
Date:	Wed, 9 Aug 1995 22:07:15 -0400
To:	9fans@cse.psu.edu
Subject: pppclient
Message-ID: <199508101207.1625.9.babim@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu

I've been trying to get pppclient to go with a foreign ppp server.
I think it's getting hung up in compression negotiation: the
remote requests Van Jacobsen compression and pppclient says nak, then
the remote request it again.  So I see:

    Peer wants to do compress 2d 15 0

It's the 0 that's the problem as ppp.l says if (15 != 15 || 0 != 1) return nak.

So is my server bust?  What's the deal?