From: James Carlson <carlsonj@workingcode.com>
To: linux-ppp@vger.kernel.org
Subject: Re: Control pppd behaviour
Date: Fri, 12 Feb 2010 12:55:05 +0000 [thread overview]
Message-ID: <4B754FA9.4040302@workingcode.com> (raw)
In-Reply-To: <27543592.post@talk.nabble.com>
On 02/11/10 21:12, Ashmath Khan wrote:
> Thanks James.
>
> Here is the current options file for our pppd.
> plugin pppoe.so eth1
> nodetach
> nodefaultroute
> persist
As I said before, you don't want the "persist" option. That tells pppd
to wait a bit, then reopen the serial link and try again after any link
establishment failure.
> maxfail 0
And that tells pppd (when "persist" is set) to try "forever" to get a
link. You also don't want that.
> lcp-max-failure 5
> lcp-max-configure 10
> lcp-max-terminate 2
> lcp-restart 3
Those are mostly the defaults. You really don't want to set those.
In general, pppd works best when configured least. The default settings
are generally chosen wisely so that they work well for the largest
possible group of users.
Your best bet is to configure *precisely* and *only* the things that you
know for certain you need to configure, and do so with reference to the
pppd man page for each one.
> So I think setting maxfail to 1 should do the trick i.e, pppd should
> exit immediately after a failed connection attempt. Will pppd exit if
> lcp echo timesout as well ?
That's a different kind of failure. If you need to manage failures that
occur after the link is up and running (as opposed to offering different
authentication or dialing options for problems detected during link
establishment; as I originally thought you were doing), then you need
"nodetach" instead of "updetach". The "nodetach" option keeps pppd from
ever becoming a daemon. It stays in the foreground until the session
terminates.
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
next prev parent reply other threads:[~2010-02-12 12:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-11 8:10 Control pppd behaviour Hashmat Khan
2010-02-11 9:03 ` walter harms
2010-02-11 12:05 ` Ashmath Khan
2010-02-11 13:18 ` James Carlson
2010-02-11 13:39 ` James Carlson
2010-02-11 13:43 ` Ashmath Khan
2010-02-11 13:49 ` Ashmath Khan
2010-02-11 14:41 ` James Carlson
2010-02-11 14:45 ` James Carlson
2010-02-11 14:51 ` Ashmath Khan
2010-02-11 14:51 ` Ashmath Khan
2010-02-11 14:58 ` James Carlson
2010-02-11 14:59 ` Ashmath Khan
2010-02-11 15:15 ` Ashmath Khan
2010-02-11 15:45 ` James Carlson
2010-02-11 16:50 ` Ashmath Khan
2010-02-11 17:01 ` James Carlson
2010-02-11 17:44 ` James Carlson
2010-02-11 17:48 ` Ashmath Khan
2010-02-11 17:52 ` Charlie Brady
2010-02-12 2:24 ` Ashmath Khan
2010-02-12 8:04 ` James Chapman
2010-02-12 12:55 ` James Carlson [this message]
2010-02-12 14:20 ` Ashmath Khan
2010-02-12 14:32 ` James Carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B754FA9.4040302@workingcode.com \
--to=carlsonj@workingcode.com \
--cc=linux-ppp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.