From owner-freebsd-current Sat May 23 05:38:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19563 for freebsd-current-outgoing; Sat, 23 May 1998 05:38:24 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19552 for ; Sat, 23 May 1998 05:38:20 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id NAA07729; Sat, 23 May 1998 13:34:58 +0100 (BST) (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199805231234.NAA07729@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Julian Elischer cc: Brian Somers , freebsd-current@FreeBSD.ORG, Archie Cobbs Subject: Re: **HEADS UP** user-ppp has changed ! In-reply-to: Your message of "Fri, 22 May 1998 10:26:20 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 May 1998 13:34:57 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 , , 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