Control pppd behaviour

Control pppd behaviour

[Hashmat Khan]

Hello,

I understand that pppd uses parameters from different files such as those
located in /etc/ppp directory to control its behaviours on failures etc.

I wanted to know if its possible to say for example implement a different
retry algorithm(user defined). Is this possible without modifying code ?

thank you
Hashmat
-- 
View this message in context: http://old.nabble.com/Control-pppd-behaviour-tp27543592p27543592.html
Sent from the linux-ppp mailing list archive at Nabble.com.

Re: Control pppd behaviour

[walter harms]

Hashmat Khan schrieb:
> Hello,
> 
> I understand that pppd uses parameters from different files such as those
> located in /etc/ppp directory to control its behaviours on failures etc.
> 
> I wanted to know if its possible to say for example implement a different
> retry algorithm(user defined). Is this possible without modifying code ?
> 


What do you try "to retry" ? when one provider is down you can easy switch to others.
like this (not working) example:

#!/bin/sh
for PROV in prov1 prov2 prov2
do
	pppd call $PROV
	if [ everythink_works ]
		exit 0
done

exit 1


re,
 wh

Re: Control pppd behaviour

[Ashmath Khan]

I am not looking for multiple options with which pppd needs to try.
Let me give an example, normally if auth fails...it will retry after
'a' seconds for 'n' number of times.
What I would need is say it should try after 'a' seconds for first
retry, after '2a' seconds for second try after first retry fails and
so on..etc. Basically I want to change the retry mechanism. Is there a
way to change without changing the code ?

thanks.

On Thu, Feb 11, 2010 at 2:33 PM, walter harms <wharms@bfs.de> wrote:
>
>
> Hashmat Khan schrieb:
>> Hello,
>>
>> I understand that pppd uses parameters from different files such as those
>> located in /etc/ppp directory to control its behaviours on failures etc.
>>
>> I wanted to know if its possible to say for example implement a different
>> retry algorithm(user defined). Is this possible without modifying code ?
>>
>
>
> What do you try "to retry" ? when one provider is down you can easy switch to others.
> like this (not working) example:
>
> #!/bin/sh
> for PROV in prov1 prov2 prov2
> do
>        pppd call $PROV
>        if [ everythink_works ]
>                exit 0
> done
>
> exit 1
>
>
> re,
>  wh
>
>
>
>
>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> I am not looking for multiple options with which pppd needs to try.
> Let me give an example, normally if auth fails...it will retry after
> 'a' seconds for 'n' number of times.
> What I would need is say it should try after 'a' seconds for first
> retry, after '2a' seconds for second try after first retry fails and
> so on..etc. Basically I want to change the retry mechanism. Is there a
> way to change without changing the code ?

It's still unclear what you're after.

Are you asking about the details of how the protocol itself works?  In
other words, are you asking about how you can modify the algorithm that
decides when to send PPP negotiation packets?

If so, then you'll need to change the source code and recompile.  There
are documented parameters that allow you to change the maximum number of
retries and the interval between retries, but none that change the
algorithm used to determine when retries occur.  The algorithm is simple
and fixed: when the timer expires and there are retries left, the TO+
event is delivered, and that causes the timer to be restarted and a new
message to be generated.

Perhaps the real question here is: "what are you trying to do?"  If you
could explain what higher-level problem you're trying to solve, it might
be possible for someone to give you a better answer.

Are you trying to work around a problem?  If so, what problem, with what
symptoms and debug log messages?  Are you trying to interoperate with a
peer that has bugs?  Are you trying to experiment with PPP itself?

On the off chance that you're trying to "work around" an error message
such as "LCP: timeout sending Config-Requests", you shouldn't.  That
message doesn't mean there's anything wrong with the timer algorithm.
It means that either the physical link isn't working properly or that
the peer just isn't running PPP at all.  With a dial-up link, it usually
means that the chat script has failed.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> Thanks James for long explanation.
> 
> Let me explain. I am actually looking for a different retry mechanism
> for failures. My retry interval would vary depending on the number of
> retries. To given an example:
> nth retry is to be attempted at (n - 1)3 x 10 secs after previous attempt

Why?  You still haven't explained what you're doing.

What problem are you attempting to solve?  Can you give us any hints at all?

> So the retry interval is not constant but derived from a formula.
> 
> Are such things possible without modifying the code ?

No.  See pppd/fsm.c, f->timeouttime, and the TIMEOUT() macro.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[Ashmath Khan]

Thanks James for long explanation.

Let me explain. I am actually looking for a different retry mechanism
for failures. My retry interval would vary depending on the number of
retries. To given an example:
nth retry is to be attempted at (n - 1)3 x 10 secs after previous attempt

So the retry interval is not constant but derived from a formula.

Are such things possible without modifying the code ?

thanks.



On Thu, Feb 11, 2010 at 6:48 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> I am not looking for multiple options with which pppd needs to try.
>> Let me give an example, normally if auth fails...it will retry after
>> 'a' seconds for 'n' number of times.
>> What I would need is say it should try after 'a' seconds for first
>> retry, after '2a' seconds for second try after first retry fails and
>> so on..etc. Basically I want to change the retry mechanism. Is there a
>> way to change without changing the code ?
>
> It's still unclear what you're after.
>
> Are you asking about the details of how the protocol itself works?  In
> other words, are you asking about how you can modify the algorithm that
> decides when to send PPP negotiation packets?
>
> If so, then you'll need to change the source code and recompile.  There
> are documented parameters that allow you to change the maximum number of
> retries and the interval between retries, but none that change the
> algorithm used to determine when retries occur.  The algorithm is simple
> and fixed: when the timer expires and there are retries left, the TO+
> event is delivered, and that causes the timer to be restarted and a new
> message to be generated.
>
> Perhaps the real question here is: "what are you trying to do?"  If you
> could explain what higher-level problem you're trying to solve, it might
> be possible for someone to give you a better answer.
>
> Are you trying to work around a problem?  If so, what problem, with what
> symptoms and debug log messages?  Are you trying to interoperate with a
> peer that has bugs?  Are you trying to experiment with PPP itself?
>
> On the off chance that you're trying to "work around" an error message
> such as "LCP: timeout sending Config-Requests", you shouldn't.  That
> message doesn't mean there's anything wrong with the timer algorithm.
> It means that either the physical link isn't working properly or that
> the peer just isn't running PPP at all.  With a dial-up link, it usually
> means that the chat script has failed.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: Control pppd behaviour

[Ashmath Khan]

Ok.
Its a requirement from my customer which I need to implement !
My customer doesn't want normal retries but want this to be tried. As
simple as that.
In addtion:and after m retries, I would want to switch to some default
credentials and continue the retries.
Does this explain ?

On Thu, Feb 11, 2010 at 7:09 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> Thanks James for long explanation.
>>
>> Let me explain. I am actually looking for a different retry mechanism
>> for failures. My retry interval would vary depending on the number of
>> retries. To given an example:
>> nth retry is to be attempted at (n - 1)3 x 10 secs after previous attempt
>
> Why?  You still haven't explained what you're doing.
>
> What problem are you attempting to solve?  Can you give us any hints at all?
>
>> So the retry interval is not constant but derived from a formula.
>>
>> Are such things possible without modifying the code ?
>
> No.  See pppd/fsm.c, f->timeouttime, and the TIMEOUT() macro.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> Ok.
> Its a requirement from my customer which I need to implement !
> My customer doesn't want normal retries but want this to be tried. As
> simple as that.
> In addtion:and after m retries, I would want to switch to some default
> credentials and continue the retries.
> Does this explain ?

Unfortunately, no, but we're getting closer.

Are you talking about PPP negotiation or about separate invocations of pppd?

If it's separate invocations of pppd, then you can certainly wrap pppd
with a script that checks the exit code (make sure you use the
"updetach" option so you get something sensible), and use the exit code
to determine what to do next.  See the man page for details.

If you're talking about the individual PPP negotiation messages that a
single pppd invocation sends to its peer (i.e., you want to send PAP
Authenticate-Request using user "joe" the first two times and then "bob"
the next two times), then you'll need to modify the source to do as
you're asking.

Fortunately, it's pretty easy to modify.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> James or others,
> 
> Is there a documentation explaining what each ppp option stands for
> options file, I do understand some but others I want to know in detail
> eg:
> plugin pppoe.so eth1
> nodetach
> nodefaultroute
> persist
> maxfail 0
> noauth
> user ashmat
> nopcomp
> lcp-max-failure 5
> lcp-max-configure 10
> lcp-max-terminate 2
> lcp-restart 3
> lcp-echo-failure 3
> lcp-echo-interval 10
> mru 1492

Have you read the man page?  How about RFC 1661?

What more details would you like to have?  Which particular options are
confusing?  (Or are they all troublesome?)

Perhaps we could offer some help here or fix the man page where it's
deficient, but please give us some idea what you need.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[Ashmath Khan]

James or others,

Is there a documentation explaining what each ppp option stands for
options file, I do understand some but others I want to know in detail
eg:
plugin pppoe.so eth1
nodetach
nodefaultroute
persist
maxfail 0
noauth
user ashmat
nopcomp
lcp-max-failure 5
lcp-max-configure 10
lcp-max-terminate 2
lcp-restart 3
lcp-echo-failure 3
lcp-echo-interval 10
mru 1492
thanks


On Thu, Feb 11, 2010 at 7:19 PM, Ashmath Khan <hashmat.email@gmail.com> wrote:
> Ok.
> Its a requirement from my customer which I need to implement !
> My customer doesn't want normal retries but want this to be tried. As
> simple as that.
> In addtion:and after m retries, I would want to switch to some default
> credentials and continue the retries.
> Does this explain ?
>
> On Thu, Feb 11, 2010 at 7:09 PM, James Carlson <carlsonj@workingcode.com> wrote:
>> Ashmath Khan wrote:
>>> Thanks James for long explanation.
>>>
>>> Let me explain. I am actually looking for a different retry mechanism
>>> for failures. My retry interval would vary depending on the number of
>>> retries. To given an example:
>>> nth retry is to be attempted at (n - 1)3 x 10 secs after previous attempt
>>
>> Why?  You still haven't explained what you're doing.
>>
>> What problem are you attempting to solve?  Can you give us any hints at all?
>>
>>> So the retry interval is not constant but derived from a formula.
>>>
>>> Are such things possible without modifying the code ?
>>
>> No.  See pppd/fsm.c, f->timeouttime, and the TIMEOUT() macro.
>>
>> --
>> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>>
>

Re: Control pppd behaviour

[Ashmath Khan]

What would I need to do so that pppd doesn't retry for any failures? thanks.

On Thu, Feb 11, 2010 at 8:15 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> James or others,
>>
>> Is there a documentation explaining what each ppp option stands for
>> options file, I do understand some but others I want to know in detail
>> eg:
>> plugin pppoe.so eth1
>> nodetach
>> nodefaultroute
>> persist
>> maxfail 0
>> noauth
>> user ashmat
>> nopcomp
>> lcp-max-failure 5
>> lcp-max-configure 10
>> lcp-max-terminate 2
>> lcp-restart 3
>> lcp-echo-failure 3
>> lcp-echo-interval 10
>> mru 1492
>
> Have you read the man page?  How about RFC 1661?
>
> What more details would you like to have?  Which particular options are
> confusing?  (Or are they all troublesome?)
>
> Perhaps we could offer some help here or fix the man page where it's
> deficient, but please give us some idea what you need.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> What would I need to do so that pppd doesn't retry for any failures? thanks.

Can you define precisely what you mean by "retry" and "failure" and what
particular cases you're concerned about?

Sorry to be obtuse here, but it's just plain unclear to me what you're
after, and I'd very much like to be helpful.

The Point-to-Point Protocol includes a negotiation mechanism that
resends messages when there's no response and sometimes when there are
disagreements between the peers.  I *suspect* you're not really
interested in that, though you seem to have expressed interest in
changing it.

The pppd implementation also includes ways to restart the entire
connection after failure.  That behavior is not the default.  You must
use options such as "demand" or "persist" in order to get the daemon to
retry after fatal problems, such as authentication rejection or
parameter negotiation failure.

If you don't want it to do that, then just don't use those options.

Please see the pppd man page for details on these options, and post a
*precise* description of what you want it to do and under what conditions.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[Ashmath Khan]

Its neither about PPP negotiation nor about separate invocation of pppd.

As I mentioned its about retry mechanism or the algorithm or you can
call it the strategy employed to retry if things fail.

For the normal retries if the retry interval is 30 secs and max retries is 5 ...
then the 1st retry is at 30 secs
2nd at 60 secs
3rd at 90 secs

But I need it something like this:
1st retry at 30 secs
2nd retry at 120 secs
3rd retry at 300 secs etc..

Hope its clear. thanks.

On Thu, Feb 11, 2010 at 8:11 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> Ok.
>> Its a requirement from my customer which I need to implement !
>> My customer doesn't want normal retries but want this to be tried. As
>> simple as that.
>> In addtion:and after m retries, I would want to switch to some default
>> credentials and continue the retries.
>> Does this explain ?
>
> Unfortunately, no, but we're getting closer.
>
> Are you talking about PPP negotiation or about separate invocations of pppd?
>
> If it's separate invocations of pppd, then you can certainly wrap pppd
> with a script that checks the exit code (make sure you use the
> "updetach" option so you get something sensible), and use the exit code
> to determine what to do next.  See the man page for details.
>
> If you're talking about the individual PPP negotiation messages that a
> single pppd invocation sends to its peer (i.e., you want to send PAP
> Authenticate-Request using user "joe" the first two times and then "bob"
> the next two times), then you'll need to modify the source to do as
> you're asking.
>
> Fortunately, it's pretty easy to modify.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: Control pppd behaviour

[Ashmath Khan]

I want to consider all failure cases(at lcp, at chap etc), any
negotiation failure etc, for which pppd would retry with the server
from scratch.
Basically I don't pppd to retry after a failure but I want pppd to
exit, and then the retry will be done by my program by relaunching
pppd. is this possible ? maybe i need to keep the retries as zero ?
thanks.

On Thu, Feb 11, 2010 at 8:28 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> What would I need to do so that pppd doesn't retry for any failures? thanks.
>
> Can you define precisely what you mean by "retry" and "failure" and what
> particular cases you're concerned about?
>
> Sorry to be obtuse here, but it's just plain unclear to me what you're
> after, and I'd very much like to be helpful.
>
> The Point-to-Point Protocol includes a negotiation mechanism that
> resends messages when there's no response and sometimes when there are
> disagreements between the peers.  I *suspect* you're not really
> interested in that, though you seem to have expressed interest in
> changing it.
>
> The pppd implementation also includes ways to restart the entire
> connection after failure.  That behavior is not the default.  You must
> use options such as "demand" or "persist" in order to get the daemon to
> retry after fatal problems, such as authentication rejection or
> parameter negotiation failure.
>
> If you don't want it to do that, then just don't use those options.
>
> Please see the pppd man page for details on these options, and post a
> *precise* description of what you want it to do and under what conditions.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> Its neither about PPP negotiation nor about separate invocation of pppd.
> 
> As I mentioned its about retry mechanism or the algorithm or you can
> call it the strategy employed to retry if things fail.
> 
> For the normal retries if the retry interval is 30 secs and max retries is 5 ...
> then the 1st retry is at 30 secs
> 2nd at 60 secs
> 3rd at 90 secs
> 
> But I need it something like this:
> 1st retry at 30 secs
> 2nd retry at 120 secs
> 3rd retry at 300 secs etc..
> 
> Hope its clear. thanks.

Ashmath Khan wrote:
> I want to consider all failure cases(at lcp, at chap etc), any
> negotiation failure etc, for which pppd would retry with the server
> from scratch.
> Basically I don't pppd to retry after a failure but I want pppd to
> exit, and then the retry will be done by my program by relaunching
> pppd. is this possible ? maybe i need to keep the retries as zero ?
> thanks.

How about using the pppd "updetach" option, and using a script to invoke
and retry pppd as desired?

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[Ashmath Khan]

Thanks James.
From man page:
updetach
    With this option, pppd will detach from its controlling terminal
once it has successfully established the ppp connection (to the point
where the first network control protocol, usually the IP control
protocol, has come up).

How about if chap authentication fails ? then updetach won't work.
what is controlling terminal here ?

On Thu, Feb 11, 2010 at 9:15 PM, James Carlson <carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> Its neither about PPP negotiation nor about separate invocation of pppd.
>>
>> As I mentioned its about retry mechanism or the algorithm or you can
>> call it the strategy employed to retry if things fail.
>>
>> For the normal retries if the retry interval is 30 secs and max retries is 5 ...
>> then the 1st retry is at 30 secs
>> 2nd at 60 secs
>> 3rd at 90 secs
>>
>> But I need it something like this:
>> 1st retry at 30 secs
>> 2nd retry at 120 secs
>> 3rd retry at 300 secs etc..
>>
>> Hope its clear. thanks.
>
> Ashmath Khan wrote:
>> I want to consider all failure cases(at lcp, at chap etc), any
>> negotiation failure etc, for which pppd would retry with the server
>> from scratch.
>> Basically I don't pppd to retry after a failure but I want pppd to
>> exit, and then the retry will be done by my program by relaunching
>> pppd. is this possible ? maybe i need to keep the retries as zero ?
>> thanks.
>
> How about using the pppd "updetach" option, and using a script to invoke
> and retry pppd as desired?
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>
>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> Thanks James.
>>From man page:
> updetach
>     With this option, pppd will detach from its controlling terminal
> once it has successfully established the ppp connection (to the point
> where the first network control protocol, usually the IP control
> protocol, has come up).
> 
> How about if chap authentication fails ? then updetach won't work.

If authentication fails, then pppd exits with an error code as
documented.  The man page entry for updetach documents the _latest_
point at which the daemon will exit, not the earliest point.

Basically, by using updetach, you can rely on the exit code from pppd to
tell you whether it was successful in starting the session (exit code 0)
and is now running in the background, or whether it failed to start
(exit code != 0).

I suspect this is the behavior you're looking for.

> what is controlling terminal here ?

It's a UNIX term.  Processes may or may not have what's called a
"controlling terminal."

When you start a process from a shell, the controlling terminal is
usually your tty.  This allows you to (for instance) press ^C and
interrupt that process.  It's what also terminates any lingering
processes with SIGHUP when you log out.

Processes that run as daemons generally disconnect from the controlling
terminal, so that they are no longer affected by the user who originally
started the process (unless explicitly sent a signal with "kill").

For more information, you may want to try googling the term.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[James Carlson]

Ashmath Khan wrote:
> Thanks James.
> 
> I do understand the daemon part. We do run the pppd as daemon that is
> in the background, we don't run from terminal but an application runs
> this. And able to catch exit codes as well !

The controlling terminal in that case is the one (if any) that's
inherited from your application.

> But pppd doesn't exit if say authetication fails, instead it will retry.

Then I think you've got it misconfigured.  pppd doesn't do that by default.

If you see otherwise, then please post complete debug logs along with
all of your configuration settings.

> I did have a look at maxfail:
> maxfail n
>     Terminate after n consecutive failed connection attempts. A value
> of 0 means no limit. The default value is 10.
> 
> I wanted to have 0 retries. Is there a way ?

Using 1 would do what you want.

But that parameter has no meaning if you've configured pppd correctly
for your situation.  "maxfail" does something if you're using "persist"
or "demand."  It doesn't do anything otherwise.

You shouldn't have to touch that.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Control pppd behaviour

[Ashmath Khan]

Thanks James.

I do understand the daemon part. We do run the pppd as daemon that is
in the background, we don't run from terminal but an application runs
this. And able to catch exit codes as well !
But pppd doesn't exit if say authetication fails, instead it will retry.

I did have a look at maxfail:
maxfail n
    Terminate after n consecutive failed connection attempts. A value
of 0 means no limit. The default value is 10.

I wanted to have 0 retries. Is there a way ?


On Thu, Feb 11, 2010 at 10:31 PM, James Carlson
<carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> Thanks James.
>>>From man page:
>> updetach
>>     With this option, pppd will detach from its controlling terminal
>> once it has successfully established the ppp connection (to the point
>> where the first network control protocol, usually the IP control
>> protocol, has come up).
>>
>> How about if chap authentication fails ? then updetach won't work.
>
> If authentication fails, then pppd exits with an error code as
> documented.  The man page entry for updetach documents the _latest_
> point at which the daemon will exit, not the earliest point.
>
> Basically, by using updetach, you can rely on the exit code from pppd to
> tell you whether it was successful in starting the session (exit code 0)
> and is now running in the background, or whether it failed to start
> (exit code != 0).
>
> I suspect this is the behavior you're looking for.
>
>> what is controlling terminal here ?
>
> It's a UNIX term.  Processes may or may not have what's called a
> "controlling terminal."
>
> When you start a process from a shell, the controlling terminal is
> usually your tty.  This allows you to (for instance) press ^C and
> interrupt that process.  It's what also terminates any lingering
> processes with SIGHUP when you log out.
>
> Processes that run as daemons generally disconnect from the controlling
> terminal, so that they are no longer affected by the user who originally
> started the process (unless explicitly sent a signal with "kill").
>
> For more information, you may want to try googling the term.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>
>

Re: Control pppd behaviour

[Charlie Brady]

On Thu, 11 Feb 2010, Ashmath Khan wrote:

> But pppd doesn't exit if say authetication fails, instead it will retry.

Really? Do you have evidence for that? Why would pppd retry if 
authentication fails - the authentication is unlikely to succeed when 
retried.

> I did have a look at maxfail:
> maxfail n
>    Terminate after n consecutive failed connection attempts. A value
> of 0 means no limit. The default value is 10.
>
> I wanted to have 0 retries. Is there a way ?

"maxfail 1" will not retry ("terminate after 1 failed connection attempt").

Re: Control pppd behaviour

[Ashmath Khan]

Thanks James.

Here is the current options file for our pppd.
plugin pppoe.so eth1
nodetach
nodefaultroute
persist
maxfail 0
noauth
user ashmat
nopcomp
lcp-max-failure 5
lcp-max-configure 10
lcp-max-terminate 2
lcp-restart 3
lcp-echo-failure 3
lcp-echo-interval 10
mru 1492
usepeerdns
linkname 2
unit 2

I do see the nodetach option. I have to understand this from my
colleagues why its not running as daemon.

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 ?

On Thu, Feb 11, 2010 at 11:14 PM, James Carlson
<carlsonj@workingcode.com> wrote:
> Ashmath Khan wrote:
>> Thanks James.
>>
>> I do understand the daemon part. We do run the pppd as daemon that is
>> in the background, we don't run from terminal but an application runs
>> this. And able to catch exit codes as well !
>
> The controlling terminal in that case is the one (if any) that's
> inherited from your application.
>
>> But pppd doesn't exit if say authetication fails, instead it will retry.
>
> Then I think you've got it misconfigured.  pppd doesn't do that by default.
>
> If you see otherwise, then please post complete debug logs along with
> all of your configuration settings.
>
>> I did have a look at maxfail:
>> maxfail n
>>     Terminate after n consecutive failed connection attempts. A value
>> of 0 means no limit. The default value is 10.
>>
>> I wanted to have 0 retries. Is there a way ?
>
> Using 1 would do what you want.
>
> But that parameter has no meaning if you've configured pppd correctly
> for your situation.  "maxfail" does something if you're using "persist"
> or "demand."  It doesn't do anything otherwise.
>
> You shouldn't have to touch that.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>
>

Re: Control pppd behaviour

[James Chapman]

Ashmath Khan wrote:
> Thanks James.
> 
> Here is the current options file for our pppd.
> plugin pppoe.so eth1
> nodetach
> nodefaultroute
> persist
> maxfail 0
> noauth
> user ashmat
> nopcomp
> lcp-max-failure 5
> lcp-max-configure 10
> lcp-max-terminate 2
> lcp-restart 3
> lcp-echo-failure 3
> lcp-echo-interval 10
> mru 1492
> usepeerdns
> linkname 2
> unit 2
> 
> I do see the nodetach option. I have to understand this from my
> colleagues why its not running as daemon.

You probably do a fork and exec to run pppd so that your app can catch
pppd exiting.

> 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 ?

As you're using persist, your app wants pppd to do the retries. Have you
considered changing your app to respawn pppd when it fails? i.e. remove
the persist and maxfail options. That way, you could implement the
exponential backoff retry algorithm in your app rather than in pppd.

Maybe pppd needs a new option to enable exponential backoff of retries
when persist is enabled?

> 
> On Thu, Feb 11, 2010 at 11:14 PM, James Carlson
> <carlsonj@workingcode.com> wrote:
>> Ashmath Khan wrote:
>>> Thanks James.
>>>
>>> I do understand the daemon part. We do run the pppd as daemon that is
>>> in the background, we don't run from terminal but an application runs
>>> this. And able to catch exit codes as well !
>> The controlling terminal in that case is the one (if any) that's
>> inherited from your application.
>>
>>> But pppd doesn't exit if say authetication fails, instead it will retry.
>> Then I think you've got it misconfigured.  pppd doesn't do that by default.
>>
>> If you see otherwise, then please post complete debug logs along with
>> all of your configuration settings.
>>
>>> I did have a look at maxfail:
>>> maxfail n
>>>     Terminate after n consecutive failed connection attempts. A value
>>> of 0 means no limit. The default value is 10.
>>>
>>> I wanted to have 0 retries. Is there a way ?
>> Using 1 would do what you want.
>>
>> But that parameter has no meaning if you've configured pppd correctly
>> for your situation.  "maxfail" does something if you're using "persist"
>> or "demand."  It doesn't do anything otherwise.
>>
>> You shouldn't have to touch that.
>>
>> --
>> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>>
>>


-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

Re: Control pppd behaviour

[James Carlson]

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>

Re: Control pppd behaviour

[Ashmath Khan]

Thanks James.

I am thinking of this:
maxfail 1
persist # or demad

Keeping these two options will make pppd exit and my app can later
control starting pppd later depending on the exit code and the
algorithm.
Sometimes we also use demand instead of persist depending on the user
configuration from UI.

What do you think ?

On Fri, Feb 12, 2010 at 1:34 PM, James Chapman <jchapman@katalix.com> wrote:
> Ashmath Khan wrote:
>> Thanks James.
>>
>> Here is the current options file for our pppd.
>> plugin pppoe.so eth1
>> nodetach
>> nodefaultroute
>> persist
>> maxfail 0
>> noauth
>> user ashmat
>> nopcomp
>> lcp-max-failure 5
>> lcp-max-configure 10
>> lcp-max-terminate 2
>> lcp-restart 3
>> lcp-echo-failure 3
>> lcp-echo-interval 10
>> mru 1492
>> usepeerdns
>> linkname 2
>> unit 2
>>
>> I do see the nodetach option. I have to understand this from my
>> colleagues why its not running as daemon.
>
> You probably do a fork and exec to run pppd so that your app can catch
> pppd exiting.
>
>> 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 ?
>
> As you're using persist, your app wants pppd to do the retries. Have you
> considered changing your app to respawn pppd when it fails? i.e. remove
> the persist and maxfail options. That way, you could implement the
> exponential backoff retry algorithm in your app rather than in pppd.
>
> Maybe pppd needs a new option to enable exponential backoff of retries
> when persist is enabled?
>
>>
>> On Thu, Feb 11, 2010 at 11:14 PM, James Carlson
>> <carlsonj@workingcode.com> wrote:
>>> Ashmath Khan wrote:
>>>> Thanks James.
>>>>
>>>> I do understand the daemon part. We do run the pppd as daemon that is
>>>> in the background, we don't run from terminal but an application runs
>>>> this. And able to catch exit codes as well !
>>> The controlling terminal in that case is the one (if any) that's
>>> inherited from your application.
>>>
>>>> But pppd doesn't exit if say authetication fails, instead it will retry.
>>> Then I think you've got it misconfigured.  pppd doesn't do that by default.
>>>
>>> If you see otherwise, then please post complete debug logs along with
>>> all of your configuration settings.
>>>
>>>> I did have a look at maxfail:
>>>> maxfail n
>>>>     Terminate after n consecutive failed connection attempts. A value
>>>> of 0 means no limit. The default value is 10.
>>>>
>>>> I wanted to have 0 retries. Is there a way ?
>>> Using 1 would do what you want.
>>>
>>> But that parameter has no meaning if you've configured pppd correctly
>>> for your situation.  "maxfail" does something if you're using "persist"
>>> or "demand."  It doesn't do anything otherwise.
>>>
>>> You shouldn't have to touch that.
>>>
>>> --
>>> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>>>
>>>
>
>
> --
> James Chapman
> Katalix Systems Ltd
> http://www.katalix.com
> Catalysts for your Embedded Linux software development
>
>

Re: Control pppd behaviour

[James Carlson]

On 02/12/10 09:08, Ashmath Khan wrote:
> Thanks James.
> 
> I am thinking of this:
> maxfail 1
> persist # or demad
> 
> Keeping these two options will make pppd exit and my app can later
> control starting pppd later depending on the exit code and the
> algorithm.
> Sometimes we also use demand instead of persist depending on the user
> configuration from UI.
> 
> What do you think ?

Do what you want, but I recommend omitting both options based on your
previously stated goal of having pppd exit on failure.

If you do use "demand" with your current configuration, I recommend
including "nopersist" in order to get the failure semantics desired.

I'm not sure I see how "demand" really fits in here, but you haven't
revealed enough information to give better advice.  And I'm not going to
continue playing 20 questions to get it.  :-/

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>