PPP dial on demand stopped

Hello,

I've been happily running PPP with dial-on-demand for a couple of
years. When I enter a TCP/IP request like host or ping it would dial
up if it wasn't already connected. Then one sunny afternoon it just
stopped trying. No system changes, no error messages, no nothin'. It
just stopped dialing out.

I turned on PPP's debug to syslog, but no help there. I'm running Red
Hat 9.0. Any clues?

Alan

Alan Baker <(E-Mail Removed)> wrote:
> Hello,

> I've been happily running PPP with dial-on-demand for a couple of
> years. When I enter a TCP/IP request like host or ping it would dial
> up if it wasn't already connected. Then one sunny afternoon it just
> stopped trying. No system changes, no error messages, no nothin'. It
> just stopped dialing out.

> I turned on PPP's debug to syslog, but no help there. I'm running Red
> Hat 9.0. Any clues?

Modem died?

I don't have any clues since you didn't provide any, and my psychic
powers have never been very good. Nothing changed but it doesn't work
doesn't work for me. Is the PPP demand interface still around?
ifconfig -a

-- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* "PPPoE has many advantages for DSL service providers, and
practically none for DSL consumers."
- David F. Skoll */

Clifford,

Thanks for your reply. Of course _something_ changed, but I am at a
loss to identify what that something is. That's why I need really
your help.

> Modem died?

Good question. I'm 3000 miles from the modem but statserial seems to
be able to talk to it. See "statserial /dev/ttyS1" below.

> Is the PPP demand interface still around?
> ifconfig -a

Yes, it's still around. See "ifconfig -a", "netstat -nr" and "pstree"
below.
In case it's helpful I have attached "/etc/ppp/options" and syslog
snippets as well.

Can you prescribe a method for troubleshooting this and finding that
_something_?

advTHANKSance
Alan

statserial /dev/ttyS1...

Signal Pin Pin Direction Status Full
Name (25) (9) (computer) Name
----- --- --- --------- ------ -----
FG 1 - - - Frame Ground
TxD 2 3 out - Transmit Data
RxD 3 2 in - Receive Data
RTS 4 7 out 1 Request To Send
CTS 5 8 in 0 Clear To Send
DSR 6 6 in 1 Data Set Ready
GND 7 5 - - Signal Ground
DCD 8 1 in 1 Data Carrier Detect
DTR 20 4 out 1 Data Terminal Ready
RI 22 9 in 0 Ring Indicator


ifconfig -a...

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:70 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6146 (6.0 Kb) TX bytes:6146 (6.0 Kb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.64.64.64 P-t-P:10.112.112.112
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:1068 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:0 (0.0 b) TX bytes:55 (55.0 b)


netstat -nr...

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
10.112.112.112 0.0.0.0 255.255.255.255 UH 0 0
0 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
0 lo
0.0.0.0 10.112.112.112 0.0.0.0 UG 0 0
0 ppp0



pstree...

init--bdflush
|-crond
|-gpm
|-kapmd
|-keventd
|-4*[kjournald]
|-klogd
|-kscand/DMA
|-kscand/HighMem
|-kscand/Normal
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-login---bash(baker)---pstree
|-mdrecoveryd
|-mgetty
|-6*[mingetty]
|-ppp-watch---ppp-watch---pppd
|-sendmail
|-sendmail(smmsp)
|-sshd
|-syslogd
|-xfs(xfs)


/etc/ppp/options...

# Use modem control lines
modem
# Use hardware flow control
crtscts
# Lock the serial port for exclusive use
lock
# Don't detach from controlling tty
-detach
# Best for firewalls unless peer requests smaller packets
mtu 1500
# Override default kdebug 7
kdebug 1
# Override default retransmission timeout of 3 seconds
ipcp-restart 1
# Faster compression than 'deflate'
bsdcomp 15,15
# No special hex control characters
asyncmap 0
# Use peer as default gateway
defaultroute
# pppd should disconnect if the link is idle for n seconds.
idle 900
# Disable the IPXCP and IPX protocols.
noipx
# Enable debugging
debug

syslog messages at boot time...

Sep 25 03:29:33 sjpcdialup kernel: Serial driver version 5.05c
(2001-07-08) with
MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Sep 25 03:29:33 sjpcdialup kernel: ttyS1 at 0x02f8 (irq = 3) is a
ST16650V2
Sep 25 03:29:33 sjpcdialup kernel: ttyS2 at 0x03e8 (irq = 4) is a
ST16650V2
Sep 25 03:29:33 sjpcdialup kernel: ttyS3 at 0x02e8 (irq = 3) is a
ST16650V2
<snip>
Sep 25 03:29:44 sjpcdialup ifup-ppp: pppd started for ppp0 on
/dev/ttyS1 at 57600
Sep 25 03:29:44 sjpcdialup kernel: CSLIP: code copyright 1989 Regents
of the University of California
Sep 25 03:29:44 sjpcdialup kernel: PPP generic driver version 2.4.2
Sep 25 03:29:44 sjpcdialup pppd[1153]: pppd 2.4.1 started by root, uid
0
Sep 25 03:29:44 sjpcdialup pppd[1153]: Using interface ppp0
Sep 25 03:29:44 sjpcdialup pppd[1153]: local IP address 10.64.64.64
Sep 25 03:29:44 sjpcdialup pppd[1153]: remote IP address
10.112.112.112


syslog messages for successful dial-on-demand invocation...

Sep 20 14:51:59 sjpcdialup pppd[1151]: Starting link
Sep 20 14:52:25 sjpcdialup pppd[1151]: Serial connection established.
Sep 20 14:52:25 sjpcdialup pppd[1151]: Connect: ppp0 <--> /dev/ttyS1
Sep 20 14:52:26 sjpcdialup pppd[1151]: Local IP address changed to
209.68.147.86
Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session opened for user
root by (uid=0)
Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session closed for user
root


syslog messages when dial-on-demand wakes up correctly but connect
script fails...

Sep 24 14:20:14 sjpcdialup starttzo: Calling TZO.Signon...
Sep 24 14:20:15 sjpcdialup pppd[1161]: Starting link
Sep 24 14:21:01 sjpcdialup pppd[1161]: Connect script failed


syslog messages when dial-on-demand does not wake up...

<null>

Alan Baker <(E-Mail Removed)> wrote:
> Good question. I'm 3000 miles from the modem but statserial seems to
> be able to talk to it. See "statserial /dev/ttyS1" below.

Setserial does not talk to modems. It talks to the serial port driver
in the kernel.

> statserial /dev/ttyS1...

> Signal Pin Pin Direction Status Full
> Name (25) (9) (computer) Name
> ----- --- --- --------- ------ -----
> FG 1 - - - Frame Ground
> TxD 2 3 out - Transmit Data
> RxD 3 2 in - Receive Data
> RTS 4 7 out 1 Request To Send
> CTS 5 8 in 0 Clear To Send
> DSR 6 6 in 1 Data Set Ready
> GND 7 5 - - Signal Ground
> DCD 8 1 in 1 Data Carrier Detect
> DTR 20 4 out 1 Data Terminal Ready
> RI 22 9 in 0 Ring Indicator

Whatever. Irrelvant if there is a real modem attached to the port! Talk
to it yourself, through minicom.


> ppp0 Link encap:Point-to-Point Protocol
> inet addr:10.64.64.64 P-t-P:10.112.112.112 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1 errors:0 dropped:1068 overruns:0 carrier:0

Not receiving anyting, ever. Talk to your modem.

> collisions:0 txqueuelen:3
> RX bytes:0 (0.0 b) TX bytes:55 (55.0 b)


> |-6*[mingetty]
> |-ppp-watch---ppp-watch---pppd
> |-sendmail

> Sep 25 03:29:33 sjpcdialup kernel: Serial driver version 5.05c
> (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
> Sep 25 03:29:33 sjpcdialup kernel: ttyS1 at 0x02f8 (irq = 3) is a ST16650V2
> Sep 25 03:29:33 sjpcdialup kernel: ttyS2 at 0x03e8 (irq = 4) is a ST16650V2
> Sep 25 03:29:33 sjpcdialup kernel: ttyS3 at 0x02e8 (irq = 3) is a ST16650V2

How come no ttyS0?

> <snip>
> Sep 25 03:29:44 sjpcdialup ifup-ppp: pppd started for ppp0 on /dev/ttyS1 at 57600
> Sep 25 03:29:44 sjpcdialup kernel: CSLIP: code copyright 1989 Regents of the University of California
> Sep 25 03:29:44 sjpcdialup kernel: PPP generic driver version 2.4.2
> Sep 25 03:29:44 sjpcdialup pppd[1153]: pppd 2.4.1 started by root, uid
> 0
> Sep 25 03:29:44 sjpcdialup pppd[1153]: Using interface ppp0
> Sep 25 03:29:44 sjpcdialup pppd[1153]: local IP address 10.64.64.64
> Sep 25 03:29:44 sjpcdialup pppd[1153]: remote IP address 10.112.112.112

Either you told it or it found that out.


> syslog messages for successful dial-on-demand invocation...

> Sep 20 14:51:59 sjpcdialup pppd[1151]: Starting link
> Sep 20 14:52:25 sjpcdialup pppd[1151]: Serial connection established.
> Sep 20 14:52:25 sjpcdialup pppd[1151]: Connect: ppp0 <--> /dev/ttyS1
> Sep 20 14:52:26 sjpcdialup pppd[1151]: Local IP address changed to 209.68.147.86
> Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session opened for user root by (uid=0)
> Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session closed for user root



> syslog messages when dial-on-demand wakes up correctly but connect script fails...

> Sep 24 14:20:14 sjpcdialup starttzo: Calling TZO.Signon...
> Sep 24 14:20:15 sjpcdialup pppd[1161]: Starting link
> Sep 24 14:21:01 sjpcdialup pppd[1161]: Connect script failed

Well, problem with the response.

> syslog messages when dial-on-demand does not wake up...

> <null>

No attempt. Anyway, I saw no real solid evidence that the modem is
working ..

Peter

Alan Baker <(E-Mail Removed)> wrote:
> Clifford,

> Thanks for your reply. Of course _something_ changed, but I am at a
> loss to identify what that something is. That's why I need really
> your help.

>> Modem died?

> Good question. I'm 3000 miles from the modem but statserial seems to

Ouch! That's a distinct disadvantage.

> be able to talk to it. See "statserial /dev/ttyS1" below.

Actually statserial is a new one on me although a google search shows
it's been around at least since 1994. Probably distribution dependent.

>> Is the PPP demand interface still around?
>> ifconfig -a

> Yes, it's still around. See "ifconfig -a", "netstat -nr" and "pstree"
> below.
> In case it's helpful I have attached "/etc/ppp/options" and syslog
> snippets as well.

They are helpful.

> Can you prescribe a method for troubleshooting this and finding that
> _something_?

If you can, try dialing out with minicom on the same modem and see
if a dialout actually occurs. It looks like a hardware problem -
more below.

> advTHANKSance
> Alan

> statserial /dev/ttyS1...

.... I'm not familiar enough with statserial to know whether it's output
could reveal anything ...

> ifconfig -a...
....

> ppp0 Link encap:Point-to-Point Protocol
> inet addr:10.64.64.64 P-t-P:10.112.112.112
> Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1 errors:0 dropped:1068 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:0 (0.0 b) TX bytes:55 (55.0 b)

That looks normal, except the 55 TX bytes and no RX bytes.

> netstat -nr...

> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window
> irtt Iface
> 10.112.112.112 0.0.0.0 255.255.255.255 UH 0 0
> 0 ppp0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
> 0 lo
> 0.0.0.0 10.112.112.112 0.0.0.0 UG 0 0
> 0 ppp0

Routing also normal for pppd in demand mode.

> pstree...
....

> |-mgetty
> |-6*[mingetty]
> |-ppp-watch---ppp-watch---pppd

"ppp-watch" must be another distribution dependent program. But pppd
is running. Can I assume that mgetty does not have a lock on ttyS1?
Probably so, I think pppd would have failed if that were true.

> |-sendmail
> |-sendmail(smmsp)
> |-sshd
> |-syslogd
> |-xfs(xfs)


> /etc/ppp/options...

The options looked okay except that notably missing is the "demand"
option, which must be elsewhere.

> syslog messages at boot time...

> Sep 25 03:29:33 sjpcdialup kernel: Serial driver version 5.05c
> (2001-07-08) with
> MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
> Sep 25 03:29:33 sjpcdialup kernel: ttyS1 at 0x02f8 (irq = 3) is a
> ST16650V2
> Sep 25 03:29:33 sjpcdialup kernel: ttyS2 at 0x03e8 (irq = 4) is a
> ST16650V2
> Sep 25 03:29:33 sjpcdialup kernel: ttyS3 at 0x02e8 (irq = 3) is a
> ST16650V2

Looks fairly normal, although I'm not familiar with a 16650 UART.
The ttySx device files do usually start at ttyS0 (irq=4). Still,
that's not likely an issue since the logs showed that ttyS1 is used.
....

> syslog messages when dial-on-demand wakes up correctly but connect
> script fails...

> Sep 24 14:20:14 sjpcdialup starttzo: Calling TZO.Signon...
> Sep 24 14:20:15 sjpcdialup pppd[1161]: Starting link
> Sep 24 14:21:01 sjpcdialup pppd[1161]: Connect script failed

I believe this means that the problem almost certainly lies either
with the connect script - which is not likely to have been changed
or damaged, or the serial device, or the modem.

If chat is being used in the connect script then you could add the
chat -v option and there should be at least some chat log messages.
Which log depends on syslogd configuration. However, I don't know
how informative they are when broken hardware is causing the failure.

You might also try setserial, but I can only show what it's output
should resemble with a working serial device:

setserial -a /dev/ttyS1
/dev/ttyS1, Line 1, UART: 16550A, Port: 0x02f8, IRQ: 3
Baud_base: 115200, close_delay: 500, divisor: 0
closing_wait: 30000
Flags: spd_normal skip_test

The UART will, of course, be different for you, and probably some of
the other items as well.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Speak softly and carry a sucker rod (See man syslogd, footnote to
recommendation 4 under SECURITY THREATS). */

(E-Mail Removed) (Alan Baker) writes:



]ifconfig -a...

]lo Link encap:Local Loopback
] inet addr:127.0.0.1 Mask:255.0.0.0
] UP LOOPBACK RUNNING MTU:16436 Metric:1
] RX packets:70 errors:0 dropped:0 overruns:0 frame:0
] TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
] collisions:0 txqueuelen:0
] RX bytes:6146 (6.0 Kb) TX bytes:6146 (6.0 Kb)
]
]ppp0 Link encap:Point-to-Point Protocol
] inet addr:10.64.64.64 P-t-P:10.112.112.112
]Mask:255.255.255.255
] UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
] RX packets:0 errors:0 dropped:0 overruns:0 frame:0
] TX packets:1 errors:0 dropped:1068 overruns:0 carrier:0
] collisions:0 txqueuelen:3
] RX bytes:0 (0.0 b) TX bytes:55 (55.0 b)


]netstat -nr...

]Kernel IP routing table
]Destination Gateway Genmask Flags MSS Window
]irtt Iface
]10.112.112.112 0.0.0.0 255.255.255.255 UH 0 0
]0 ppp0
]127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
]0 lo
]0.0.0.0 10.112.112.112 0.0.0.0 UG 0 0
]0 ppp0



]/etc/ppp/options...

]# Use modem control lines
]modem
]# Use hardware flow control
]crtscts
]# Lock the serial port for exclusive use
]lock
]# Don't detach from controlling tty
]-detach

Why nodetach?

]# Best for firewalls unless peer requests smaller packets
]mtu 1500

Always best to leave mtu at default unless there are good reasons not to.

]# Override default kdebug 7
]kdebug 1

Does not really exist anymore.


]# Override default retransmission timeout of 3 seconds
]ipcp-restart 1
]# Faster compression than 'deflate'
]bsdcomp 15,15

What is your system you connect to? Unless it is a linux system, this is
userless. And even if it is a linux system, the modem does compression
anyway.


]# No special hex control characters
]asyncmap 0

It is is a Windows peer then a better choise is asyncmap a0000

]# Use peer as default gateway
]defaultroute
]# pppd should disconnect if the link is idle for n seconds.
]idle 900

Do you want this?
I thought you wanted it to remain connected?



]# Disable the IPXCP and IPX protocols.
]noipx
]# Enable debugging
]debug

And you need to have a line like
local2.*;daemon.* /var/log/ppplog
in /etc/syslog.conf


]syslog messages at boot time...

]Sep 25 03:29:33 sjpcdialup kernel: Serial driver version 5.05c
](2001-07-08) with
] MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
]Sep 25 03:29:33 sjpcdialup kernel: ttyS1 at 0x02f8 (irq = 3) is a
]ST16650V2
]Sep 25 03:29:33 sjpcdialup kernel: ttyS2 at 0x03e8 (irq = 4) is a
]ST16650V2
]Sep 25 03:29:33 sjpcdialup kernel: ttyS3 at 0x02e8 (irq = 3) is a
]ST16650V2
]<snip>
]Sep 25 03:29:44 sjpcdialup ifup-ppp: pppd started for ppp0 on
]/dev/ttyS1 at 57600
]Sep 25 03:29:44 sjpcdialup kernel: CSLIP: code copyright 1989 Regents
]of the University of California
]Sep 25 03:29:44 sjpcdialup kernel: PPP generic driver version 2.4.2
]Sep 25 03:29:44 sjpcdialup pppd[1153]: pppd 2.4.1 started by root, uid
]0
]Sep 25 03:29:44 sjpcdialup pppd[1153]: Using interface ppp0
]Sep 25 03:29:44 sjpcdialup pppd[1153]: local IP address 10.64.64.64
]Sep 25 03:29:44 sjpcdialup pppd[1153]: remote IP address
]10.112.112.112


You forgot to add that line to /etc/syslog.conf and as a result you get
no debug messages. Do the above so you can see what is happening.




]syslog messages for successful dial-on-demand invocation...

]Sep 20 14:51:59 sjpcdialup pppd[1151]: Starting link
]Sep 20 14:52:25 sjpcdialup pppd[1151]: Serial connection established.
]Sep 20 14:52:25 sjpcdialup pppd[1151]: Connect: ppp0 <--> /dev/ttyS1
]Sep 20 14:52:26 sjpcdialup pppd[1151]: Local IP address changed to
]209.68.147.86
]Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session opened for user
]root by (uid=0)
]Sep 20 14:52:27 sjpcdialup su(pam_unix)[7220]: session closed for user
]root


]syslog messages when dial-on-demand wakes up correctly but connect
]script fails...

]Sep 24 14:20:14 sjpcdialup starttzo: Calling TZO.Signon...
]Sep 24 14:20:15 sjpcdialup pppd[1161]: Starting link
]Sep 24 14:21:01 sjpcdialup pppd[1161]: Connect script failed

no information here because you did not tell syslog where to put the
debugging messages.


]
]
]syslog messages when dial-on-demand does not wake up...

]<null>

Clifford, Bill, and Peter,

Thanks for your thoughtful suggestions. Once I get things working I
will incorporate your recommendations into /etc/ppp/options.

The server reboots daily so I put a host command into the rc.local
file to trigger a dial-out at boot time. It does attempt to dial out
but dies with a connect script failure (which is consistent with a
hardware problem). However, subsequent network commands (such as
host) do NOT trigger an attempt to dialout, or at least nothing shows
in the log.

Why would it respond to the first host command, but not to subsequent
ones?

>>> Modem died?
>> Good question. I'm 3000 miles from the modem but statserial seems
to
> Ouch! That's a distinct disadvantage.

I have a colleague lined up to go check out the hardware today. Maybe
an earthquake knocked a cable loose. 8*)

> If you can, try dialing out with minicom on the same modem and see
> if a dialout actually occurs. It looks like a hardware problem -

I dialed into the server and tried minicom. Unfortunately the
terminal program I used has a very similar key mapping (e.g. Alt-D
for dial) so it intercepts the Alt-D instead of passing it through to
minicom. Next I'll try dialing in via ppp1 and the SSH via PuTTY -
hope the key mapping is different!

> And you need to have a line like
> local2.*;daemon.* /var/log/ppplog
> in /etc/syslog.conf

OK - added it and added debug to /etc/ppp/options. Now ppp1 (that's
another story) puts debug output in syslog but ppp0 remains silent.

> If chat is being used in the connect script then you could add the
> chat -v option and there should be at least some chat log messages.
> Which log depends on syslogd configuration. However, I don't know
> how informative they are when broken hardware is causing the failure.

I added -v to the chat but it didn't put anything additional in
syslog.

Alan

Alan Baker <(E-Mail Removed)> wrote:
> The server reboots daily so I put a host command into the rc.local
> file to trigger a dial-out at boot time. It does attempt to dial out
> but dies with a connect script failure (which is consistent with a
> hardware problem). However, subsequent network commands (such as
> host) do NOT trigger an attempt to dialout, or at least nothing shows
> in the log.

> Why would it respond to the first host command, but not to subsequent
> ones?

Because your kernel is toast. Only the first error counts.

Peter

Alan Baker <(E-Mail Removed)> wrote:
> Clifford, Bill, and Peter,

> Thanks for your thoughtful suggestions. Once I get things working I
> will incorporate your recommendations into /etc/ppp/options.

While the debug option is helpful in solving many PPP problems it's
probably not something you would want permanently. As Bill Unruh said,
in essence, kdebug is almost always more trouble that it's worth now,
and a CCP algorithm implemented in pppd is not likely to be recognized
by a non-*nix host (and would provide an increase in data rate only in
special situations where the CCP algorithm used provided significantly
better compression than the modem).

> The server reboots daily so I put a host command into the rc.local
> file to trigger a dial-out at boot time. It does attempt to dial out
> but dies with a connect script failure (which is consistent with a
> hardware problem). However, subsequent network commands (such as
> host) do NOT trigger an attempt to dialout, or at least nothing shows
> in the log.

> Why would it respond to the first host command, but not to subsequent
> ones?

A default route through second interface that was created at boot time
but after the dialout was triggered would do that. The route output you
posted only showed ppp0 but you now speak of a ppp1. Make sure there
are not two default routes; the last created should be the active one.

FYI. At one time I had demand PPP set up and then tried making a
manual connection. There was some problem with that that caused the
manual link to not be viable even though the manual PPP default route
should have been the last one created - thus the "should be" rather that
"is" above. I was able to devise a workaround but couldn't think of
a satisfactory reason for the problem.

>>>> Modem died?
>>> Good question. I'm 3000 miles from the modem but statserial seems
> to
>> Ouch! That's a distinct disadvantage.

> I have a colleague lined up to go check out the hardware today. Maybe
> an earthquake knocked a cable loose. 8*)

;-)

>> If you can, try dialing out with minicom on the same modem and see
>> if a dialout actually occurs. It looks like a hardware problem -

> I dialed into the server and tried minicom. Unfortunately the
> terminal program I used has a very similar key mapping (e.g. Alt-D
> for dial) so it intercepts the Alt-D instead of passing it through to
> minicom. Next I'll try dialing in via ppp1 and the SSH via PuTTY -
> hope the key mapping is different!

How about using "control-a z" to get the main menu and then just
pressing d to bring up the dialing menu?

I take it that ppp1 is for a pppd launched by mgetty on dial-in.

>> And you need to have a line like
>> local2.*;daemon.* /var/log/ppplog
>> in /etc/syslog.conf

> OK - added it and added debug to /etc/ppp/options. Now ppp1 (that's
> another story) puts debug output in syslog but ppp0 remains silent.

It will remain silent as long as the chat script fails.

>> If chat is being used in the connect script then you could add the
>> chat -v option and there should be at least some chat log messages.
>> Which log depends on syslogd configuration. However, I don't know
>> how informative they are when broken hardware is causing the failure.

> I added -v to the chat but it didn't put anything additional in
> syslog.

Even for the dial-out on boot-up? Of course syslogd would have to
be started before the dial-out occurred.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Clifford,

Thanks for your help. I was able to SSH into my server using putty
then use minicom. And the modem did not reply. So I got a colleague
to recycle the power on the modem and voila - everything worked again!
Duh. My lesson here is to get someone onsite quickly to look for the
obvious. 8-)

Bill,

This particular ppp connects to a Sun host, but I have others that
connect to Windows hosts. Please tell me more about the benefits of
asyncmap a0000.

When I set up this server about 5 years ago I was told to use mtu 1500
for dialup lines unless there was a reason not to. Why is default
better?

Alan

>]# No special hex control characters
>]asyncmap 0

> It is is a Windows peer then a better choise is asyncmap a0000

>]# Best for firewalls unless peer requests smaller packets
>]mtu 1500

> Always best to leave mtu at default unless there are good reasons not to.