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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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@xxxxxxxxxxxxxxx>

[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux