archive mirror
 help / color / mirror / Atom feed
From: James Carlson <>
Subject: Re: PPP cycling between UP and DOWN
Date: Thu, 28 May 2020 13:59:13 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2020-05-27 15:16, Patrick Mahan wrote:
> I have a script that monitors by this by having a modified ip-up and
> ip-down script write a value to a specific file under /var/run/pppd/ and
> if it is ip-down, then I schedule a restart of pppd to occur once the
> pppd image exits.  I have assumed that ip-down being triggered is and
> indication that PPPoE connection is down and over.

That's the most likely case.  It would help to have _complete_ debug
logs showing what's happening.

(For what it's worth, another person posting to this list recently was
having PPPoE problems that ended up tracking back to a bad Ethernet
driver.  The driver allowed receive of unicast packets with someone
else's address, and the PPPoE kernel code accepted a stray PADT that
caused the link to go down.)  (PPPoE, as a protocol, is pretty nasty stuff.)

> But I am now seeing that this assumption could be incorrect.  I don't
> claim to understand the entire protocol layers involved.  But is it
> supported that a PPPoE connection can shift back from the IPCP layer to
> the LCP layer?  Then back?

IPCP can certainly be taken down without taking down LCP.  And LCP can
be renegotiated (implicitly taking down IPCP as well) at any time.
However, I've yet to find a commercial service provider that actually
supports anything like this.  All of the systems they use are much more
limited implementations.

It sounds like a stretch to me.  A debug log would show for sure, though.

> Or is this a ppp protocol issue.  I see in the pppd code that we can
> moved to a down state if we get a request to restart negotiations, so I
> can see that my assumption may be incorrect.

It can, as described above, but it's not something that's commonly (or
"ever") implemented, at least in my experience.  Renegotiation almost
always leads to complete teardown.  (Depending on the vendor, some will
start doing LCP Protocol-Reject on the NCP protocols like IPCP if you
attempt that.)

This doesn't sound likely to me.  But, again, debug logs are your friend

Use the pppd 'debug' option.  By itself, that'll write the log
information to syslog daemon.debug (be sure to redirect that to a file).
 Or use the "logfile /path/to/file" option to write the messages to a
file.  Then post those logs.

It's important to understand that PPP is just one protocol layer.  PPPoE
itself is distinct, with its own messages and states.  The actions of
PPPoE are seen by PPP as just underlying link up/down states -- very
much like the signals PPP would get from a modem.

James Carlson         42.703N 71.076W         <>

  reply	other threads:[~2020-05-28 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 19:16 PPP cycling between UP and DOWN Patrick Mahan
2020-05-28 13:59 ` James Carlson [this message]
2020-05-28 17:54 ` Patrick Mahan
2020-06-08 17:04 ` Patrick Mahan
2020-06-08 17:15 ` James Carlson
2020-06-08 21:32 ` David Balažic
2020-06-08 22:51 ` Patrick Mahan
2020-06-08 22:52 ` Patrick Mahan
2020-06-09 18:03 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).