Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 09 Aug 1999 18:14:22 +0100
From:      Brian Somers <brian@FreeBSD.org.uk>
To:        Rowan Crowe <rowan@sensation.net.au>
Cc:        Brian Somers <brian@FreeBSD.org.uk>, freebsd-isp@FreeBSD.ORG
Subject:   Re: problem with user level ppp, using multilink functionality 
Message-ID:  <199908091714.SAA52188@keep.lan.Awfulhak.org>
In-Reply-To: Your message of "Tue, 10 Aug 1999 02:59:20 %2B1000." <Pine.BSF.4.01.9908100252180.16934-100000@velvet.sensation.net.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 10 Aug 1999, Rowan Crowe wrote:
> 
> >  clone 1,2
> >  link deflink remove
> 
> Following on from the last message, I think this is where the extra links
> are coming from. The man page doesn't say you *don't* have to clone on the
> server side, so it looks like that was my mistake! I commented out the
> above 2 lines and it's now working [better].

You've got to bear in mind that ppp allows you to create new links 
even in -direct mode.  This will facilitate BACP nicely when I get 
time to implement it.  You only need to create links you plan to use.

Ppp is smart on the incoming side.  You make two links to machine A, 
and two ppp processes start up.  When they realize that they should 
be part of the same link, one invocation passes the link to the other 
then hangs around 'till the other version of ppp is finished with it 
(so that getty doesn't grab and revoke() the line).

> There's still the problem of the carrier drop not being detected - very
> strange. Until the LQR kicks in no IP traffic passes over the mppp link,
> but the good news is that once that happens everything seems to exit and
> clean up; a subsequent redial attempt of the downed modem succeeds and IP
> traffic is once again passed over the mppp link.
> 
> I've downed each modem once and the number of ppp processes is staying
> stable at 2 once the modem comes back up.
> 
> I'm wondering how to fix the CD problem. Does the 'set cd' command work
> for the server side? The way I read it it's only relevant for scripted
> dialins (ie the client side).

The server side will do the same as the client side except that it 
uses descriptor 0 (as set up by getty) rather than opening its own 
device.  You need to enable ``debug'' logging to see what's going on 
there.  A ``set cd 1!'' will tell ppp to wait up to 1 second for 
carrier and then close the link if it's not there - it may be worth 
experimenting with.  You may also want something like ``set cd 3!'' 
if your modems are slow at asserting carrier (I've only seen one such 
report before).

> Cheers.
> 
> 
> --
> Rowan Crowe                              http://www.rowan.sensation.net.au/
> Sensation Internet Services                    http://www.sensation.net.au/
> Melbourne, Australia                                 Phone: +61-3-9388-9260

-- 
Brian <brian@Awfulhak.org>                        <brian@FreeBSD.org>
      <http://www.Awfulhak.org>;                   <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour !          <brian@FreeBSD.org.uk>




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908091714.SAA52188>