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

["Morel Bérenger" <berenger.morel@sga-automation.com>]

[-- 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 --]