* pppclient
@ 1995-08-10 18:18 presotto
0 siblings, 0 replies; 6+ messages in thread
From: presotto @ 1995-08-10 18:18 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* pppclient
@ 1995-08-21 9:03 Nigel
0 siblings, 0 replies; 6+ messages in thread
From: Nigel @ 1995-08-21 9:03 UTC (permalink / raw)
Following Boyd's problems with pppclient, I had a different problem.
My pppserver (demon internet) wants to do (2d 15 1) compression
which is fine. What nadgers it is that pppclient then negotiates for
VJ TCP compression and IL compression. Demon's pppserver hasn't heard
of IL compression (can't blame it) so sends Configure NAK. I think I
then hit the same problem as Boyd in that pppclient keeps trying the
same Configure Request and getting Configure NAK until the server
starts saying Configure REJ (presumably out of frustration). The fix
is simple. Delete the IL compression request. It was simpler than
trying to implement Configure Req backoff. Then I get the connectiion
up. What I haven't figured yet is what else to do to actually get the
packets sent up the ppp link.....
^ permalink raw reply [flat|nested] 6+ messages in thread
* pppclient
@ 1995-08-15 2:43 presotto
0 siblings, 0 replies; 6+ messages in thread
From: presotto @ 1995-08-15 2:43 UTC (permalink / raw)
I agree, we wrote a different version for brazil. Unfortunately, they
share no code except for the tcp compression. This one went out with
the release in the hope that a plan 9 version would be useful to someone.
It has worked talking to xylogics annex boxes.
------ original message follows ------
>From cse.psu.edu!9fans-outgoing-owner Mon Aug 14 22:42:30 EDT 1995
Received: by psuvax1.cse.psu.edu id <34220>; Mon, 14 Aug 1995 22:09:40 -0400
Received: from plan9.cs.su.oz.au ([129.78.96.2]) by psuvax1.cse.psu.edu with SMTP id <34230>; Mon, 14 Aug 1995 20:52:06 -0400
From: Boyd Roberts <boyd@plan9.cs.su.oz.au>
Date: Mon, 14 Aug 1995 19:27:36 -0400
To: 9fans@cse.psu.edu
Subject: re: pppclient
In-Reply-To: <199508140955.518.9.babip@plan9.cs.su.oz.au>
Message-ID: <199508150927.1656.9.babis@plan9.cs.su.oz.au>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
Looking further into the IPCP code I see that its not likely
to converge when negociating with my server. The configuration
request/nak/reject code is just wrong. I'm not going to try
and fix it any further. It just doesn't hold enough state
to ensure the negociation will converge; it's nearly stateless,
but not quite.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pppclient
@ 1995-08-14 23:27 Boyd
0 siblings, 0 replies; 6+ messages in thread
From: Boyd @ 1995-08-14 23:27 UTC (permalink / raw)
Looking further into the IPCP code I see that its not likely
to converge when negociating with my server. The configuration
request/nak/reject code is just wrong. I'm not going to try
and fix it any further. It just doesn't hold enough state
to ensure the negociation will converge; it's nearly stateless,
but not quite.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pppclient
@ 1995-08-13 23:55 Boyd
0 siblings, 0 replies; 6+ messages in thread
From: Boyd @ 1995-08-13 23:55 UTC (permalink / raw)
i pulled the ppp docs and have added the code to handle slot id compression.
i think what i see now is that the ack is mangled, i'm not sure. i'll
try and check it out today. things are a bit slow as the source is
not where i am so the compile edit run cycle is a bit arduous.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pppclient
@ 1995-08-10 2:07 Boyd
0 siblings, 0 replies; 6+ messages in thread
From: Boyd @ 1995-08-10 2:07 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1995-08-21 9:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-08-10 18:18 pppclient presotto
-- strict thread matches above, loose matches on Subject: below --
1995-08-21 9:03 pppclient Nigel
1995-08-15 2:43 pppclient presotto
1995-08-14 23:27 pppclient Boyd
1995-08-13 23:55 pppclient Boyd
1995-08-10 2:07 pppclient Boyd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).