Date: Thu, 13 Nov 1997 23:39:27 +0000 From: Brian Somers <brian@awfulhak.org> To: "Johan Granlund" <johang@mail.algonet.se> Cc: Brian Somers <brian@awfulhak.org>, current@FreeBSD.ORG Subject: Re: ppp and ascend router problems Message-ID: <199711132339.XAA21225@awfulhak.demon.co.uk> In-Reply-To: Your message of "Thu, 13 Nov 1997 19:08:04 %2B0100." <199711131806.NAA02823@mailman.iuinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > > 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 <brian@Awfulhak.org>, <brian@FreeBSD.org>, <bri@OpenBSD.org>
<http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711132339.XAA21225>