Subject: Re: IPCP within MP?

From: Archie Cobbs <[email-masked]>
Date: Mon, 1 May 2000 11:56:52 -0700 (PDT)

Vernon Schryver writes:
> > >   3.  My side attempts to send an IPCP Configure-Request that's
> > >       split into two parts and sent as two multi-link fragments
> > >       over the two links.
> >
> > No problem with that.  (I don't think I've seen an implementation yet
> > that does this, though ...)
> >
> > >   4.  The remote side responds with an LCP Protocol-Reject
> > >       of protocol 0x003d (the multilink protocol) on link #2,
> > >       and ignores my IPCP Configure-Request. The protocol
> > >       reject contains enough of the packet to show that it's
> > >       rejecting one of the IPCP Configure-Request MP fragments.
> >
> > Assuming that the second link is actually configured to run MP, that's
> > a rather horrible bug.
> 
> Yes, #4 indicates serious problems in the peer, but ...
> while #3 doesn't violate the standard, it does violate the dictum to be
> conservative in what you send.  Given how many PPP implementations are
> put together, fragmenting any PPP control packet is asking for trouble.
> 
> Consider also that IPCP Configure-Requests are necessarily very tiny,
> and that fragmenting tinygrams is a bad idea on performance grounds.

FYI,

After a little more testing it appears that what's really happening
is that the device can't handle IPCP being negotiated *after* both
links have come up. It has nothing to do with how the IPCP packets
are fragmented, or even whether they are contained in MP or not.

That is, this works:

  - Link 1 reaches NETWORK phase
  - IPCP is negotiated
  - Link 2 reaches NETWORK phase

But this fails:

  - Link 1 reaches NETWORK phase
  - Link 2 reaches NETWORK phase
  - IPCP is negotiated

Whatever.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com