Irving Kimura <(E-Mail Removed)> wrote:
> My PPP dial-up at home is suddenly not working. It worked fine
> the day before yesterday, but last night I could not connect.
> For several days now, I have done absolutely nothing that could
> have affected the PPP set-up; I have remained as a regular user
> (no superuser privileges), surfing the web, and using Emacs and
> Gnumeric. (The sole exception is the initial call to gnome-ppp
> several days ago, which I did with sudo; gnome-ppp remained
> open even while I was not connected.)
I take it that you only started using gnome-ppp at the time of the
"initial call." Sigh. The trouble with frontends to pppd, and
ppp-gnome is a frontend to pppd, is that when they fail the user is
left clueless as to what went wrong.
> Now, when I try to connect, the gnome-ppp debug window shows:
> --NEW CONNECTION--
> ATZ
> OK
> ATZ
> OK
> ATDT271-828-1828
> CONNECT
Apparently the modem successfully connected to the ISP. That doesn't
mean the PPP link is up and working.
> which looks fine, until one tries to do anything that requires a
> working connection. For example, if I try pinging a numeric address,
> I get
> % ping -c 1 199.232.41.9
> PING ftp.gnu.org (199.232.41.9): 56 data bytes
> ping: sendto: Network is unreachable
> ping: wrote 199.232.41.9 64 chars, ret=-1
This means there is no route to the Internet.
> --- 199.232.41.9 ping statistics ---
> 1 packets transmitted, 0 packets received, 100% packet loss
> Then, 45-60 seconds after the gnome-ppp debug window reports CONNECT,
> an "Error" dialog window pops up with the message: "The pppd daemon
> died unexpectedly."
Wow! Isn't that informative!! Sorry, I'm biased against frontends.
> I get the same results with two different dial-up services, and
> whether I try connecting from home or from work (the computer is
> a laptop).
> When I try "ifconfig -a" the ppp0 section looks bad:
> ppp0 Link encap:Point-to-Point Protocol
> POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
It looks like no IP addresses for the PPP link were negotiated.
> Before (I just happen to have a record) it used to look like this:
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:216.126.160.103 P-t-P:64.24.244.195
> Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
> RX packets:8 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:301 (301.0 b) TX bytes:185 (185.0 b)
> (I never found out what the IPs 216.126.160.103 and 64.24.244.195
> referred to.)
That's a normal ifconfig output when a PPP link is up and working.
The first IP address is your IP address (local) for the connection
and the second IP address is the ISP connection host's IP address
(remote).
> Likewise, the output of route looks terrible: other than the headers
> line ("Destination Gateway..."), nothing shows. Before, it looked
> like this:
> Destination Gateway Genmask Flags Metric Ref Use Iface
> bos1-dial2.pops * 255.255.255.255 UH 0 0 0 ppp0
> default bos1-dial2.pops 0.0.0.0 UG 0 0 0 ppp0
This is normal routing for a PPP link. The FQDN of the ISP connection
host is bos1-dial2.pops .. the rest is chopped off by route for display
purposes (there's no way I know to get ifconfig to display the full name).
The first line is a host route to the ISP connection host. The second
line is the default route, the one to the Internet.
> One further difference is that, previously, "lsmod|grep ppp" showed
> ppp_deflate, along with other modules (ppp_generic, ppp_async,
> slhc), but now ppp_deflate is missing.
You don't need ppp_deflate anyway. Even if it was there before the
problem began it probably wasn't being used.
> I am totally in the dark as to why suddenly everything fell apart.
> These changes are completely out-of-the-blue and inexplicable to
> me. Any clues would be greatly appreciated.
Follow the recipe in my signature and then try to connect. Post an
exact copy of the log, including timestamps. That *may* provide a
reason as to why IP addresses aren't negotiated, although the fact
that the problem exists for two ISPs seems strange. Often a sudden
problem can mean that an ISP has changed something - but *two* ?
-- Clifford Kite Email: "echo
xvgr_yvahk-(E-Mail Removed)|rot13"
/* Recipe for a unified PPP debug log file: Add the line
" local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
to /etc/syslog.conf, and do " kill -HUP `pidof syslogd` "
so that syslogd rereads it. */
Similar Threads
Linear Mode
