active network connection stops working...

[Rick Sewill]

On Thu, 2009-07-23 at 02:18 -0500, charles zeitler wrote:

> 
> Jul 22 22:29:00 cthuga kernel: PPP generic driver version 2.4.2
> Jul 22 22:29:00 cthuga pppd[1964]: Warning: can't open options
> file /root/.ppprc: Permission denied
> Jul 22 22:29:00 cthuga pppd[1964]: pppd 2.4.4 started by root, uid 0
> Jul 22 22:29:00 cthuga pppd[1964]: Using interface ppp0
> Jul 22 22:29:00 cthuga pppd[1964]: Connect: ppp0 <--> /dev/pts/0
> Jul 22 22:29:00 cthuga pppoe[1965]: PPP session is 2563 (0xa03)
> Jul 22 22:29:01 cthuga pppd[1964]: PAP authentication succeeded
> Jul 22 22:29:01 cthuga pppd[1964]: local  IP address 76.236.148.89
> Jul 22 22:29:01 cthuga pppd[1964]: remote IP address 151.164.182.119
> Jul 22 22:29:01 cthuga pppd[1964]: primary   DNS address 68.94.156.1
> Jul 22 22:29:01 cthuga pppd[1964]: secondary DNS address 68.94.157.1
> Jul 22 22:29:01 cthuga pppd[1972]: Can't execute /etc/ppp/ip-up:
> Permission denied
> Jul 22 22:29:02 cthuga ntpd[1512]: Listening on interface #5 ppp0,
> 76.236.148.89#123 Enabled
> 

I could be way off base.  I haven't used ppp in years.

My instinct is there are a number of possibilities why the link would go
down.  The following are a few I can think of:
1) PPP decides the peer is dead
2) PPP decides the link is idle and wishes to disconnect

Let me talk about these two possibilites.

1) PPP decides the peer is dead

   If PPP is not directly tied to a physical interface,
   and in your case, I assume PPP is going over ethernet to a 
   DSL interface and will not know the status of the physical DSL  
   interface, PPP could use LCP Echo to determine if the peer is dead.

   I would guess either:
   a) PPP is not using LCP Echo and decides the peer is dead -or-
   b) PPP is using LCP Echo and decides the peer is dead

I guess the first question, is PPP using LCP Echo?

I can think of three ways to find out:
a) Use Wireshark to sniff the physical interface for PPP packets.
   This is not the PPP interface.  This is the interface PPP uses,
   did you say it was ethernet or DSL, to get to the peer.

b) One could examine configuration files to see if LCP Echo is enabled.
Please let me copy some of the "man pppd" page here:
"
lcp-echo-failure n
       If  this  option is given, pppd will presume the peer to be dead
       if n LCP echo-requests are sent without receiving  a  valid  LCP
       echo-reply.   If  this  happens, pppd will terminate the connec-
       tion.  Use of this option requires  a  non-zero  value  for  the
       lcp-echo-interval  parameter.  This option can be used to enable
       pppd to terminate after the physical connection has been  broken
       (e.g.,  the  modem  has hung up) in situations where no hardware
       modem control lines are available.

lcp-echo-interval n
       If this option is given, pppd  will  send  an  LCP  echo-request
       frame  to  the  peer  every n seconds.  Normally the peer should
       respond to the echo-request  by  sending  an  echo-reply.   This
       option  can  be  used with the lcp-echo-failure option to detect
       that the peer is no longer connected.
"
I do not remember which configuration file would contain the above
options.  Can you do a grep in your /etc/ppp directory...we may get
lucky.

c) One could turn on debugging options to see what PPP negotiates with
the peer and see if PPP is actually sending LCP Echo packets.
Let me quote from the "man pppd" page again:
"
debug  Enables  connection  debugging  facilities.   If  this option is
       given, pppd will log the contents of all control packets sent or
       received  in  a  readable  form.  The packets are logged through
       syslog with facility daemon and level debug.   This  information
       can  be directed to a file by setting up /etc/syslog.conf appro-
       priately (see syslog.conf(5)).
"

2) PPP decides the link is idle and wishes to disconnect

The other possibility I can think of is PPP decides the connection is
idle.  Did you, at one time, use PPP for dial-up and then switch to DSL?

If so, you may still have PPP options telling PPP to disconnect after a
certain level of inactivity.  Let me quote from "man pppd":
"
demand Initiate the link only on demand,  i.e.  when  data  traffic  is
       present.  With this option, the remote IP address must be speci-
       fied by the user on the command line  or  in  an  options  file.
       Pppd will initially configure the interface and enable it for IP
       traffic without connecting to the peer.  When traffic is  avail-
       able,  pppd  will  connect  to the peer and perform negotiation,
       authentication, etc.  When this is completed, pppd will commence
       passing data packets (i.e., IP packets) across the link.

       The demand option implies the persist option.  If this behaviour
       is not desired,  use  the  nopersist  option  after  the  demand
       option.  The idle and holdoff options are also useful in conjuc-
       tion with the demand option.
"
If the demand option is present, and again I don't remember which
configuration file holds this option, PPP will decide to disconnect
should PPP decide the connection is idle.

A "quick" and "dirty" passive test to see if PPP is disconnecting
because PPP thinks the connection is idle might be to set up a ping
command that pings, once a minute, a well-known website.  One could see
if this ping activity keeps the PPP connection alive.
ping -i 60 www.google.com
This is not the best way of finding out if PPP is disconnecting because
PPP thinks the connection is idle...but is quick and dirty and easy.
I guess the best way would be to use wireshark, as described above, to
see if PPP sends terminate requests to the peer to actually bring the
connection down after a certain period of time -or- to enable
debugging--the debug option described above.  

Sometimes, quick and dirty tests are easier to do and can point one to
doing more elaborate tests if necessary.  I actually prefer wireshark
and would run to wireshark in a heart-beat, but to each his own.

Again, I could be putting you on a wild goose chase, but these are two
possibilities I can think of.

There are other possibilities...a bug might exist in your PPP
implementation.  I hope a bug doesn't exist.

The peer might not be configured properly.  Again, I hope this is
not the case.  If this were the case, you'd need to use wireshark
or turn on the debugging option described above or scream bloody
murder at your ISP...or all three.

-Rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20090723/e7118257/attachment-0001.sig>