Date: Sat, 23 May 1998 13:34:57 +0100 From: Brian Somers <brian@Awfulhak.org> To: Julian Elischer <julian@whistle.com> Cc: Brian Somers <brian@Awfulhak.org>, freebsd-current@FreeBSD.ORG, Archie Cobbs <archie@whistle.com> Subject: Re: **HEADS UP** user-ppp has changed ! Message-ID: <199805231234.NAA07729@awfulhak.org> In-Reply-To: Your message of "Fri, 22 May 1998 10:26:20 PDT." <Pine.BSF.3.95.980522102523.24421B-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> did you test it against mpd?
I've now tested against mpd for a single link. Unfortunately, ppp
still has a known bug playing server mode. It can't continue to use
real tty device descriptors after they've been passed through a local
socket (via SCM_RIGHTS) - as soon as the controlling process group
goes away, a d_close happens at the device level despite the open
descriptor. AFAICT this is *not* just a descriptor-passing-through-socket
bug - my diagnostics see the devices' d_close being called more than
once even before the descriptor has had anything special done to it.
See my unanswered posting to -hackers with a subject line ``SCM_RIGHTS
& session ids''....
Anyway, the upshot of it all is that YES, PPP TALKS TO MPD OK (first
time too), but I have the following observations to make about mpd
(Archie cc'd):
o Version reported at startup is incorrect (reports 1.0b2, not 1.0b4)
o Why is more than one bundle allowed ? Isn't two mpd invocations
more practical ? I considered doing this as an exercise in ppp but
decided in the end that it had no practical use.
o With the following mpd.links:
bang:
link bang
The command `new b bang' aborts (as in abort()).
o With the following in mpd.links:
x:
The commands `new b x' followed by `link y' says
`link "b" is not defined' instead of `link "y"'.
o Mpd rejects short sequence number requests & endpoint discriminator
requests, but mpd sends a MAC-type discriminator :-/ That's
playing a bit unfair isn't it ? What's wrong with simply ACKing
the discriminator - nothing needs to be done after that (except
comparisons with other links).
o Mpd doesn't support CCP at the bundle layer but fails to send a
protocol reject.
o If I *don't* `set link disable chap', sending name Pbrian and
password Pbrian from the peer I get
[dgb1] LCP: phase shift ESTABLISH --> AUTHENTICATE
[dgb1] LCP: auth: peer wants CHAP, I want CHAP
[dgb1] CHAP: sending CHALLENGE
[dgb1] LCP: LayerUp
[dgb1] CHAP: rec'd RESPONSE #1
Bad packet
[dgb1] CHAP: sending FAILURE
[dgb1] LCP: authorization failed
Peer doesn't want CHAP, it was never even REQ'd.
The CHAP password sent by the peer was correct :-/
o If I `set link disable chap' and `set link enable pap', sending
name Pbrian and password Pbrian from the peer I get:
[dgb1] LCP: phase shift ESTABLISH --> AUTHENTICATE
[dgb1] LCP: auth: peer wants nothing, I want PAP
[dgb1] LCP: LayerUp
[dgb1] PAP: rec'd REQUEST #1
Peer name: ""
No secret for "" found
[dgb1] PAP: sending NAK
[dgb1] LCP: authorization failed
The auth: line is correct, but still authentication fails.
It was really interesting configuring mpd. The whole approach Archie
took is enormously different from the one I took :-)
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805231234.NAA07729>