From owner-freebsd-current Thu Nov 13 15:41:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03810 for current-outgoing; Thu, 13 Nov 1997 15:41:28 -0800 (PST) (envelope-from owner-freebsd-current) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03786 for ; Thu, 13 Nov 1997 15:41:16 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id XAA21225; Thu, 13 Nov 1997 23:39:27 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199711132339.XAA21225@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Johan Granlund" cc: Brian Somers , current@FreeBSD.ORG Subject: Re: ppp and ascend router problems In-reply-to: Your message of "Thu, 13 Nov 1997 19:08:04 +0100." <199711131806.NAA02823@mailman.iuinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Nov 1997 23:39:27 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Hi > > > Once upon a (long) time (ago) i had ppp working, not any more. It has ben > > > some traffic about ppp and i decided to get it working again. > > > When trying from a 2.2-stable from around 1 month ago it works fine, but not > > > from my current machine. > > > My ISP has some sort of big Ascend router. WinNT and Win95 works. > > > > > > Sending ppp.log and hopes anyone have a clue why? > > > > > > >From ppp.conf: > > > > > > disable lqr > > > deny lqr > > > set openmode active > > > disable pred1 > > > deny pred1 > > > > > > >From ppp.log: > > > > > > Nov 12 22:34:58 phoenix ppp[621]: tun0: IPCP: Using trigger address > > > 255.255.255.0 > > > > Why are you using this ? Change it to 0.0.0.0 (or remove it > > altogether). It's the 4th arg to "set ifaddr". This isn't the > > problem though, you're not getting as far as IPCP negotiation. > > > > >From ppp.conf.sample (cut and paste) :-) I hate to be pedantic, but grepping for all "ifaddr" strings in all revisions of ppp.conf that have 4 or more args, I get: rev 1.21: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.21: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.22: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.22: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.23: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.23: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.24: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 rev 1.24: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 I've never seen a ppp implementation that requires anything other than 0.0.0.0 as that forth arg (bearing in mind that actually requiring the forth arg means the implementation is broken to start with). But, we digress. We're not getting that far, and chances are that, given that the other side is a good implementation, it'll handle the 255.255.255.0 anyway ! > This is a log from a 2.2-stable system as of 97-10-02. ppp.conf and > ppp.linkup is copied from the -current system with only the devicename and > phonenumber changed. The log is from a connect / disconnect. > > Nov 13 08:52:20 daemon ppp[3298]: tun0: Connect: CONNECT > Nov 13 08:52:20 daemon ppp[3298]: tun0: Phase: *Connected! > Nov 13 08:52:20 daemon ppp[3298]: tun0: IPCP: Using trigger address > 255.255.255.0 > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: State change > Initial --> Closed > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: LcpSendConfigReq > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: ACFCOMP > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: ACCMAP [6] 00000000 > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: MRU [4] 1500 > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: MAGICNUM [6] 6149e1d2 > Nov 13 08:52:20 daemon ppp[3298]: tun0: HDLC: HdlcOutput > Nov 13 08:52:20 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 > Nov 13 08:52:20 daemon ppp[3298]: tun0: LCP: State change Closed --> Req-Sent > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: LcpSendConfigReq > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: ACFCOMP > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: ACCMAP [6] 00000000 > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: MRU [4] 1500 > Nov 13 08:52:23 daemon ppp[3298]: tun0: LCP: MAGICNUM [6] 6149e1d2 > Nov 13 08:52:23 daemon ppp[3298]: tun0: HDLC: HdlcOutput > Nov 13 08:52:23 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: HdlcInput: > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 01 01 00 1f 01 04 > 05 f4 02 06 00 0a > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: 00 00 03 04 > c0 23 07 02 08 02 13 09 03 00 c0 7b > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: 6e ee c5 d8 f1 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: Received Configure Request (1) > state = Req-Sent (6) > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: MRU 1524 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACCMAP 000a0000 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: AUTHPROTO proto = c023 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACFCOMP > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ???[13] > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: SendConfigRej(Req-Sent) > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ???[13] > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: HdlcOutput > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: HdlcInput: > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 01 02 00 16 01 04 > 05 f4 02 06 00 0a > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: 00 00 03 04 > c0 23 07 02 08 02 88 75 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: Received > Configure Request (2) state = Req-Sent (6) > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: MRU 1524 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACCMAP 000a0000 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: AUTHPROTO proto = c023 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACFCOMP So the second CONFIG REQ *doesn't* contain a ``13''. This is what we expect, so we can now ACK the REQ and things will proceed. Note, this *isn't* what happened last time (through no apparent fault of the local ppp). > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: SendConfigAck(Req-Sent) > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: MRU 1524 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACCMAP 000a0000 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: AUTHPROTO proto = c023 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: ACFCOMP > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: HdlcOutput > Nov 13 08:52:24 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 > Nov 13 08:52:24 daemon ppp[3298]: tun0: LCP: State change Req-Sent --> > Ack-Sent > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: LcpSendConfigReq > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: ACFCOMP > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: PROTOCOMP > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: ACCMAP [6] 00000000 > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: MRU [4] 1500 > Nov 13 08:52:26 daemon ppp[3298]: tun0: LCP: MAGICNUM [6] 6149e1d2 > Nov 13 08:52:26 daemon ppp[3298]: tun0: HDLC: HdlcOutput > Nov 13 08:52:26 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 > Nov 13 08:52:27 daemon ppp[3298]: tun0: HDLC: HdlcInput: > Nov 13 08:52:27 daemon ppp[3298]: tun0: HDLC: ff 03 c0 21 02 03 00 18 08 02 > 07 02 02 06 00 00 > Nov 13 08:52:27 daemon ppp[3298]: tun0: HDLC: 00 00 01 04 > 05 dc 05 06 61 49 e1 d2 4e 29 > Nov 13 08:52:27 daemon ppp[3298]: tun0: LCP: Received Configure Ack (3) state > = Ack-Sent (8) > Nov 13 08:52:27 daemon ppp[3298]: tun0: LCP: State change Ack-Sent --> Opened We've both received a CONFIG ACK - we can proceed. [.....] The peer is behaving differently. If this is the same peer, I'd be surprised. The funny thing here is that we manage to squeeze two CONFIG REQs out before the peer sends anything. The peer doesn't REQ for four seconds. The ``uninteresting'' thing is that your last posting detailed exactly the same behaviour (3 seconds that time), *except* that the second CONFIG REQ from the peer asked for the [13] again and again the first time 'round. This time, it behaves correctly and removes the [13] from the REQ. I'd examine this with whoever controls (and hopefully understands) the peer. Basically, if we send a REJ, the peer *must not* REQ the things that we REJ. We are entitled to drop the connection immediately if this happens because the peer is violating the ppp protocol. Perhaps you ought to get these guys to update to the next (apparently daily) version of software :-I > ___________________________________________________________ > > Internet: Johang@Algonet.se > > I don't even speak for myself -- Brian , , Don't _EVER_ lose your sense of humour....