How to know when a link is established or destroyed?

How to know when a link is established or destroyed?

[Morel Bérenger]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Hello.

I am using pppd to have network access through GPRS/3G/4G on systems I
do not have physical access to.

Since I want the system to be up almost always, I am trying to manage
my daemons through runit (daemontools), which works by keeping child
process foreground and restart it when it dies for a reason or another,
eventually logging whatever came on stdout.

I can run pppd in that way, but I have no idea about how to know if the
connection is really established or not, and on some systems manual
reboot is sometimes needed, because it seems that pppd only tries 3 or
4 times to restore connection when link is cut, and if not it just
stays alive doing nothing.

So, I think either I missed the options needed to do what I need, or
there is a tool to manage pppd that I don't know, or it is not
implemented at all.

If if is not implemented at all, is it intended? Would it be fine if I
submit a patch doing this?

Note:
I am using the 2.4.7 version from the Debian 9 (stretch) package
2.4.7-1+4 on amd64.
$ uname -a
Linux PC-dev2 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
x86_64 GNU/Linux

Thanks in advance.

PS: I'm not registered to this list, so I added my mail in the CC field.

-- 
SGA Automation
27 Rue Jean-Philippe Rameau
Pôle Delta
76000 Rouen
Tel : 02 32 10 38 53
Fax : 02 32 10 11 30
www.sga-automation.com
Email : berenger.morel@sga-automation.com

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How to know when a link is established or destroyed?

[James Carlson]

On 10/22/18 06:28, Morel Bérenger wrote:
> I am using pppd to have network access through GPRS/3G/4G on systems I
> do not have physical access to.
> 
> Since I want the system to be up almost always, I am trying to manage
> my daemons through runit (daemontools), which works by keeping child
> process foreground and restart it when it dies for a reason or another,
> eventually logging whatever came on stdout.

Please post the pppd options you're using today.  I'm going to guess
that you're using at least "nodetach".  Anything else?  (See the man
page for sources of options; /etc/ppp/options is the main one.)

Please post debug traces, or a link to them; particularly those you feel
highlight problems that you're seeing.  It's almost impossible to
determine the source of problems without traces.  There are multiple
ways to get a trace.  The simplest is to use the "debug" option, and get
the log messages via syslog.  Use "logfile /path/to/some/file" if you
can't use syslog for some reason.  (Note: don't use kdebug unless there
are kernel-level problems.  This doesn't sound like a kernel-level problem.)

The usual way to set up an always-on connection with pppd is NOT via
some external utility, but by using the built-in restart capability in
pppd.  You can use use the external utility if you want, but I think
it'll be harder to manage.

To use the built-in restart, set "persist maxfail 0" as options.

If you insist on using an external utility to do this, you will probably
want something like "maxfail 1" or "maxfail 2" instead.

If the peer you're talking to is willing, I recommend using the
lcp-echo-interval and lcp-echo-failure options with any sort of link
that needs to be reliable.  These options (when usable -- the peer may
balk, if the peer is poorly implemented) allow PPP to detect when the
point-to-point link has lost connectivity, and will shut down (and
retry, if "persist" is enabled or if some sort of external restart
utility is used).

Note that most GPRS implementations, at least the ones I've seen, are
horror shows, and that stems, at least in part, from execrable
"standards" set for their use of Internet protocols.  Your mileage may vary.

> I can run pppd in that way, but I have no idea about how to know if the
> connection is really established or not, and on some systems manual
> reboot is sometimes needed, because it seems that pppd only tries 3 or
> 4 times to restore connection when link is cut, and if not it just
> stays alive doing nothing.

The connection is up for IPv4 traffic when the optional executable
script (or program) /etc/ppp/ip-up is invoked.  It's down when
/etc/ppp/ip-down is invoked.  You should also see the IFF_UP flag on the
interface change state; a routing socket might be good for monitoring that.

Having the PPP link up and having LCP+auth+IPCP negotiated (and thus the
local IP interface marked IFF_UP) does *NOT*, of course, guarantee that
you have a path to "the Internet" (or whatever wider network you believe
you're connecting to).  It merely means that an IP path has been
established to the peer -- PPP is point-to-point, of course.  Whether
that peer is capable and willing to transport IP traffic for you is a
completely separate matter.

If your "failures" involve losing IP routing while the PPP link is up,
then that may just be par for the course.  You'll need some other
monitoring system to tell you when or if that happens.  There's nothing
that PPP can possibly do to help with that; it's only a link layer protocol.

> So, I think either I missed the options needed to do what I need, or
> there is a tool to manage pppd that I don't know, or it is not
> implemented at all.
> 
> If if is not implemented at all, is it intended? Would it be fine if I
> submit a patch doing this?

Submitting patches is fine, but if you do so, please indicate precisely
what the patch does and (if possible) why the existing features don't
fulfill your needs.  It's often very hard to review changes out of the
blue that don't appear to solve problems.

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

Re: How to know when a link is established or destroyed?

[Morel Bérenger]

[-- Attachment #1.1: Type: text/plain, Size: 4497 bytes --]

Sorry for the late reply, I had not a lot of time recently.

Le Mon, 22 Oct 2018 10:40:16 -0400,
James Carlson <carlsonj@workingcode.com> a écrit :

> On 10/22/18 06:28, Morel Bérenger wrote:
> > I am using pppd to have network access through GPRS/3G/4G on
> > systems I do not have physical access to.
> > 
> > Since I want the system to be up almost always, I am trying to
> > manage my daemons through runit (daemontools), which works by
> > keeping child process foreground and restart it when it dies for a
> > reason or another, eventually logging whatever came on stdout.  
> 
> Please post the pppd options you're using today.

$ grep -v -e '^#' -e '^$' /etc/ppp/options 
asyncmap 0
auth
crtscts
lock
hide-password
modem
lcp-echo-interval 30
lcp-echo-failure 4
noipx

$ cat /etc/ppp/peers/bouygues
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs_bouygues -T
pcebouygtel.com" /dev/ttyUSB4
noipdefault
defaultroute
usepeerdns
persist
noauth
hide-password

$ cat etc/chatscripts/gprs_bouygues    
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO DIAL TONE"
ABORT "NO ANSWER"
ABORT "DELAYED"
ABORT "ERROR"
ABORT "+CGATT :0"

""                            AT
TIMEOUT                       12
OK                            ATH
OK                            ATE1
OK                            "AT+CPIN?"
"+CPIN: READY-AT+CPIN=0000-"  AT+CGDCONT=1,"IP","\T","",0,0
OK                            \d\d\dATD*99#
TIMEOUT                       22
CONNECT                       ""

I hope I included every useful information?

> Please post debug traces

I have attached a tarball containing pppd & chat logs on my current
configuration to this mail, on a system that had the problem, I hope it
is ok?
Lines showing the problem starts at "Nov  7 15:10:15".

> The simplest is to use the "debug" option, and get the log messages
> via syslog.  Use "logfile /path/to/some/file" if you can't use syslog
> for some reason.  (Note: don't use kdebug unless there are
> kernel-level problems.  This doesn't sound like a kernel-level
> problem.)

Are logs sent to a file exactly the same as those sent to syslog?

> The usual way to set up an always-on connection with pppd is NOT via
> some external utility, but by using the built-in restart capability in
> pppd.  You can use use the external utility if you want, but I think
> it'll be harder to manage.

I would prefer to avoid external tools, however I am using runit
(like daemontools) to manage my daemons.
I would like to integrate pppd, because I believe (but may be wrong)
that it would simplify things for me to have only 1 system ensuring
every services are doing their job.

> To use the built-in restart, set "persist maxfail 0" as options.
> 
> If you insist on using an external utility to do this, you will
> probably want something like "maxfail 1" or "maxfail 2" instead.

Thanks, I'll try that.

> Note that most GPRS implementations, at least the ones I've seen, are
> horror shows, and that stems, at least in part, from execrable
> "standards" set for their use of Internet protocols.  Your mileage
> may vary.

I guess it's "good" to know.

> If your "failures" involve losing IP routing while the PPP link is up,
> then that may just be par for the course.  You'll need some other
> monitoring system to tell you when or if that happens.  There's
> nothing that PPP can possibly do to help with that; it's only a link
> layer protocol.

Of course, but from what I can see from logs, the problem seems to come
from the point-to-point link.

> > So, I think either I missed the options needed to do what I need, or
> > there is a tool to manage pppd that I don't know, or it is not
> > implemented at all.
> > 
> > If if is not implemented at all, is it intended? Would it be fine
> > if I submit a patch doing this?  
> 
> Submitting patches is fine, but if you do so, please indicate
> precisely what the patch does and (if possible) why the existing
> features don't fulfill your needs.  It's often very hard to review
> changes out of the blue that don't appear to solve problems.

Indeed, and this is why I asked before wasting everyone's time.

Thanks for all the valuable informations.


-- 
SGA Automation
27 Rue Jean-Philippe Rameau
Pôle Delta
76000 Rouen
Tel : 02 32 10 38 53
Fax : 02 32 10 11 30
www.sga-automation.com
Email : berenger.morel@sga-automation.com

[-- Attachment #1.2: pppd.log.tar.gz --]
[-- Type: application/gzip, Size: 3124 bytes --]

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How to know when a link is established or destroyed?

[James Carlson]

On 11/13/18 07:08, Morel Bérenger wrote:
>> The simplest is to use the "debug" option, and get the log messages
>> via syslog.  Use "logfile /path/to/some/file" if you can't use syslog
>> for some reason.  (Note: don't use kdebug unless there are
>> kernel-level problems.  This doesn't sound like a kernel-level
>> problem.)
> 
> Are logs sent to a file exactly the same as those sent to syslog?

Yes, if you use the "logfile /path/to/some/file" option.

Missing from the logs you sent is the "debug" option, so the information
you've provided is *very* sketchy and not very useful.  However, I do
have some questions about it.  During the first 197.7 minute-long
session, did you successfully connect?  Did you get actual IP service on
the initial try?

I don't know whether you have a completely failing connection (which
would point towards one set of problems) or a connection that merely
fails on retry (which points to a different set of problems).

If you kill off pppd, wait a few seconds, and then start it again, will
you get another successful session at the start?  Is it only having
trouble during a post-failure retry (i.e., during 'persist')?

Based on the following messages, I can make at least one somewhat
educated guess.

Nov  7 15:15:13 700009-vnf-180918 pppd[1161]: Remote message: Greetings!!
Nov  7 15:15:13 700009-vnf-180918 pppd[1161]: PAP authentication succeeded
Nov  7 15:15:13 700009-vnf-180918 pppd[1161]: Hangup (SIGHUP)
Nov  7 15:15:13 700009-vnf-180918 pppd[1161]: Modem hangup
Nov  7 15:15:13 700009-vnf-180918 pppd[1161]: Connection terminated.


As I said in my previous message, GPRS is really quite horrible.  One of
the horrible aspects of it is that it deliberately *lies* to the peer
during the PPP authentication phase.  If you pass bad credentials
(either via one of the PPP authentication protocols or via some 'hidden'
channel, such as your subscriber ID / telephone number), a GPRS server
will send back a fake "success" message.  The actual authentication work
in GPRS is (inexplicably) delayed until the PPP Network phase.  This
means that an authentication failure perversely manifests as IPCP
negotiation failure.  Instead of getting a good address to use, you get
a garbage address that doesn't work, or no address at all, and the
system just waits for you to hang up in frustration with no outward
indication of the real problem.

So, at a glance, and without the strength of seeing the actual pppd
"debug" messages I originally requested, the summary informational
messages above *may* tend to indicate that your user name or password
are not valid, or that something about your local configuration isn't
right with respect to credentials, or the account that you're using to
connect to this GPRS server is itself not authorized, or that you're
violating some policy rule that the GPRS provider has in place (e.g.,
maximum number of connected minutes per day or minimum time between
successive connection attempts or some such rule).

When I was PPPEXT chair, I argued with the GPRS people until I was blue
in the face.  It did no good, of course.  I'm sorry you're one of the
victims here.

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