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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
