Re: More diald problems.
On Sun, 12 Jan 1997 15:29:48 PST Kevin Traas ([EMAIL PROTECTED])
wrote:
As requested, I've included my configuration files throughout the message
below. I hope this helps in figuring out what my problem is. (I've
stripped out my username passwords from the files)
I think I can understand the problem:
Jan 9 09:58:50 sally diald[3243]: Connect script timed out. Killing
script.
You connect script never terminates and diald thinks it has hung
(default timeout: 60 secs).
[diald.options: ]
defaultroute
connect /etc/ppp/scripts/ppp-up
And here's my script to crank up the connection: /etc/ppp/scripts/ppp-up
[snipped]
exec /usr/sbin/pppd debug /dev/ttyS0 38400 \
$LOCAL_IP:$REMOTE_IP \
connect $DIALER_SCRIPT
Here it is !!!
Diald starts pppd itself, you don't have to start it in your dial script. The
dial script is just for dialing, not starting ppp.
So what happens is that pppd is started while diald thinks you're connecting...
It cannot install the defaultroute too...
Here are my scripts:
=== Diald.options:
mode ppp
accounting-log /var/log/diald.log
mtu 1500
local 207.104.147.8
remote 207.104.147.7
netmask 255.255.255.0
dynamic
two-way
reroute
defaultroute
connect /etc/ppp/connect
lock
speed 115200
modem
crtscts
connect-timeout 90
redial-timeout 10
kill-timeout 30
redial-backoff-start 2
redial-backoff-limit 600
dial-fail-limit 0
up
===/etc/ppp/connect:
#!/bin/sh
# Copyright (c) 1996, Eric Schenk.
#
# This script is intended to give an example of a connection script that
# uses the message facility of diald to communicate progress through
# the dialing process to a diald monitoring program such as dctrl or diald-top.
# It also reports progress to the system logs. This can be useful if you
# are seeing failed attempts to connect and you want to know when and why
# they are failing.
#
# This script requires the use of chat-1.9 or greater for full
# functionality. It should work with older versions of chat,
# but it will not be able to report the reason for a connection failure.
# Configuration parameters
# The initialization string for your modem
MODEM_INIT=+++ATZ
# The phone number to dial
PHONE_NUMBERS=1
PHONE_NUMBER1=MYNUMBER
# The chat sequence to recognize that the remote system
# is asking for your user name.
USER_CHAT_SEQ=ogin:
# The string to send in response to the request for your user name.
USER_NAME=MYNAME
# The chat sequence to recongnize that the remote system
# is asking for your password.
PASSWD_CHAT_SEQ=assword:
# The string to send in response to the request for your password.
PASSWORD=MYPASSWORD
# The prompt the remote system will give once you are logged in
# If you do not define this then the script will assume that
# there is no command to be issued to start up the remote protocol.
PROMPT1='bash$ '
# The command to issue to start up the remote protocol
PROTOCOL_START=MYCOMMANDTOSTARTPPP
# The string to wait for to see that the protocol on the remote
# end started OK. If this is empty then no check will be performed.
START_ACK=
# Pass a message on to diald and the system logs.
function message () {
[ $FIFO ] echo message $* $FIFO
logger -p local2.info -t connect $*
}
# Initialize the modem. Usually this just resets it.
message Initializing Modem
chat TIMEOUT 5 $MODEM_INIT TIMEOUT 45 OK
if [ $? != 0 ]; then
message Failed to initialize modem
exit 1
fi
# Dial the remote system.
i=1
connected=0
while [ $i -le $PHONE_NUMBERS ]
do
message Dialing system $i
eval phone=\$PHONE_NUMBER$i
chat \
TIMEOUT 45 \
ABORT NO CARRIER \
ABORT BUSY \
ABORT NO DIALTONE \
ABORT ERROR \
ATDT$phone \
CONNECT
case $? in
0) message Connected; connected=1;break;;
1) message Chat Error; exit 1;;
2) message Chat Script Error; exit 1;;
3) message Chat Timeout; exit 1;;
4) message No Carrier; exit 1;;
5) message Busy;;
6) message No DialTone; exit 1;;
7) message Modem Error; exit 1;;
*) message Unkown Error;exit 2;;
esac
let i=i+1
done
if [ $connected -eq 0 ]
then
message All phone lines busy
exit 1
fi
# We're connected try to log in.
message Loggin in
chat \
TIMEOUT 5 \
$USER_CHAT_SEQ \\q$USER_NAME \
TIMEOUT 45 \
$PASSWD_CHAT_SEQ $PASSWORD
if [ $? != 0 ]; then
message Failed to log in
exit 1
fi
# We logged in, try to start up the protocol (provided that the
# user has specified how to do this)
eval PROMPT=\$PROMPT$i
if [ $PROMPT ]; then
message Starting Comm Protocol
chat TIMEOUT 90 $PROMPT $PROTOCOL_START GOPPP
if [ $? != 0 ]; then
message Prompt not received
exit 1
fi
fi
if [ $START_ACK ]; then
chat TIMEOUT 15 $START_ACK
if [ $? != 0 ]; then
message Failed to start Protocol
exit 1
fi
fi
# Success!
message Protocol started
=== End.
As you
Re: More diald problems.
From: Philippe Troin [EMAIL PROTECTED] To: Kevin Traas [EMAIL PROTECTED] Cc: debian-user@lists.debian.org Subject: Re: More diald problems. Date: Sunday, January 12, 1997 3:49 PM Here it is !!! Diald starts pppd itself, you don't have to start it in your dial script. The dial script is just for dialing, not starting ppp. So what happens is that pppd is started while diald thinks you're connecting... It cannot install the defaultroute too... Wow! That explains things! Thanks *so* much for your help! And an answer in only 14 minutes too! How can you beat that? Now that I know my problem, I'll probably find something obvious somewhere in the docs Here are my scripts: Thanks! I'll go over them tomorrow (when I get back to work) and implement the appropriate changes and give it a try then. (I particularly like the option for multiple phone numbers) I'll let you know how things go. Thanks again for all your help, Kevin Traas Systems Analyst Edmondson Roper Chilliwack, BC, Canada http://users.uniserve.com/~erca System Administrator ValleyNet (a CN operated by the Fraser Valley Community Information Society) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Sun, 12 Jan 1997 16:09:00 PST Kevin Traas ([EMAIL PROTECTED]) wrote: So what happens is that pppd is started while diald thinks you're connecting... It cannot install the defaultroute too... Wow! That explains things! Thanks *so* much for your help! And an answer in only 14 minutes too! How can you beat that? You just got lucky I was logged at that time :-) Here are my scripts: Thanks! I'll go over them tomorrow (when I get back to work) and implement the appropriate changes and give it a try then. (I particularly like the option for multiple phone numbers) Yep. I picked this script in the ppp (or was it diald ?) examples directory and added the capability for multiple phone numbers to be tried in a row. Now I'm not using it anymore, but I kept it. I'll let you know how things go. Yes please. Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
This IMHO is not correct. From the diald-man-page: PPPD OPTIONS When diald is being used in PPP mode extra options can be passed on to pppd by specifying them after a -- on the command line. This should not normally be necessary as default options can be placed into the /etc/ppp/options file. But, if you need to run multiple instances of pppd with different options then you will have to make use of this ability. Note that some pppd options should not be specified, not even in the /etc/ppp/options file, because they will interfere with the proper operation of diald. In particular you should not specify the tty device, the baud rate, nor any of the options crtscts, xonxoff, -crtscts, defaultroute, lock, netmask, -detach, modem, local, mtu and proxyarp. Use the equivalent diald options to control these pppd settings. This to my mind clearly states that the defaultroute option has to go in the *diald* options file *not* in the one for ppp. Regards, Andree -- | Institute of Geophysics phone: +49 40 4123 4389 ANDREE LEIDENFROST | University of Hamburg fax: +49 40 4123 5441 Geophysicist | Bundesstrasse 55 e-mail: [EMAIL PROTECTED] | D-20146 Hamburgwww: www.app-geoph.dkrz.de -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
Hi, I saw your message on the debian mailing list, where you described your problem with getting up diald. Now, what is happening is your 'ppp-up' script. Diald is informing you in the log, that it doesn't get a return code from this script. It never returns to diald, so diald thinks that no connection has been made, and thus terminates the line. Now, you might ask how come the connection works and the answer to that is that that part is taken care off by pppd, which you execute on your own in your 'ppp-up'. You should remove the line in your 'ppp-up' script where you start the execution of 'pppd'... that should do the trick. If that doesn't work, you should change the 'ppp-up' script... or actually bypass it. Which means you can clean up your 'ppp-dialer' script, so that it contains only these parts for chat (i.e. not the 'chat -v' etc.): ABORT BUSY ABORT NO CARRIER . . . OK ATwDT... ^- if you are using your home line, this will wait for a carrier .before dialing. That means your wife doesn't have to hear .the loud sqeak on the line, if the computer decides to dial .while she's on the phone. asswd: boo After this, you change the connect line in the diald.options file to be something like: connect chat -f file-containing-above-chat-code You see, diald will start the 'pppd' itself after the connection has been made... and set the netmask, the fake local and remote ip addresses and all the rest... all the connect script has to do, is open the line to the remote computer. Hope this helps... -- Ørn Einar Hansen [EMAIL PROTECTED] [EMAIL PROTECTED] fax; +46 035 217194 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
From: Orn E. Hansen [EMAIL PROTECTED] To: Kevin Traas [EMAIL PROTECTED] Cc: Philippe Troin [EMAIL PROTECTED]; debian-user@lists.debian.org Subject: Re: More diald problems. Date: Monday, January 13, 1997 5:11 AM I saw your message on the debian mailing list, where you described your problem with getting up diald. snip You should remove the line in your 'ppp-up' script where you start the execution of 'pppd'... that should do the trick. snip You see, diald will start the 'pppd' itself after the connection has been made... and set the netmask, the fake local and remote ip addresses and all the rest... all the connect script has to do, is open the line to the remote computer. Hope this helps... Thanks for the info! This is exactly the information that Philippe provided me. He saw the same problems with my configuration. I went with his suggestions and things are working much better now. Thanks for your help, Kevin Traas Systems Analyst Edmondson Roper Chartered Accountants http://users.uniserve.com/~erca Chilliwack, B.C. Pager: (604) 918-2054 Office: (604) 792-1915 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Sat, 11 Jan 1997 [EMAIL PROTECTED] wrote: On Sat, 11 Jan 1997, David Engel wrote: I have a nagging problem with 'defaultroute' that maybe you can help me with. Everytime diald drops the link due to inactivity, it deletes the default route. After that, diald won't bring the link back up for non-loopback addresses because there aren't any routes. I have to manually force the link back up. Any ideas? It's a bug in diald that has been fixed with the newest release of diald. However, the newest release hasn't been debianized yet by the maintainer (I don't think). I am going to do it myself if a new diald.deb doesn't show up in unstable soon. If you want a copy, email me. I didn't know there was a new version. Thanks. Diald now restores the routes and interfaces to the state they were before the link was brought up. However, diald still won't bring the link back up automatically after it has taken it down. The dummy SLIP interface acts likes it is passing packets (the TX counter increments), but diald never seems to notice and reactivate the real SLIP interface. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Sat, 11 Jan 1997, David Engel wrote: I didn't know there was a new version. Thanks. Diald now restores the routes and interfaces to the state they were before the link was brought up. However, diald still won't bring the link back up automatically after it has taken it down. The dummy SLIP interface acts likes it is passing packets (the TX counter increments), but diald never seems to notice and reactivate the real SLIP interface. I just installed it, and it's working for me... Erv ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \ - [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] http://www.linux.org \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems. (fwd)
On Sat, 11 Jan 1997, David Engel wrote: I didn't know there was a new version. Thanks. Diald now restores the routes and interfaces to the state they were before the link was brought up. However, diald still won't bring the link back up automatically after it has taken it down. The dummy SLIP interface acts likes it is passing packets (the TX counter increments), but diald never seems to notice and reactivate the real SLIP interface. I just installed it, and it's working for me... Erv I take it back. It's not working. Erv ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \ - [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] http://www.linux.org \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems. (fwd)
On 12 Jan 1997, James LewisMoss wrote: Go to the diald web site and get the patch. It has a bug that once it takes ot down once it won't bring it back up. The patch fixes it. (Is running fine on my machine) The new diald site is unreachable right now. Would you mind mailing the patch. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
Thanks very much for you help, Philippe. As requested, I've included my configuration files throughout the message below. I hope this helps in figuring out what my problem is. (I've stripped out my username passwords from the files) TIA, Kevin However, NO MATTER WHAT I DO across the connection, diald kills it after only about 30 seconds of uptime. In other words, even if I start a telnet or ftp session, I hardly manage to get connected to the remote site and diald drops the connection and my session hangs. Of course, with these connection-oriented utilities, I've got to start over again when I get reconnected. However, if I run a connection-less utility like ping, it'll ping merrily along for 30 seconds until diald kills the connection and then wait until diald again re-establishes it again. Do you know why diald terminates the connection ? If you've got `debug 31', diald should output a shitload of messages (in /var/log/messages). Would you give us an excerpt ? Here you go. This is just a piece of it. The only thing I can see why the connection is terminated is at line 9:58:50 below. But it doesn't explain why This section is from running /etc/init.d/diald start: Jan 9 09:56:58 sally diald[3243]: Using fifo /var/lib/diald/diald.fifo Jan 9 09:56:58 sally diald[3243]: Starting diald version 0.14 Jan 9 09:56:59 sally diald[3243]: Proxy device established on interface sl0 Jan 9 09:57:07 sally diald[3243]: Setting pointopoint route for sl0 Jan 9 09:57:07 sally diald[3243]: Establishing routes for sl0 Jan 9 09:57:07 sally diald[3243]: Cannot determine ethernet address for proxy ARP Jan 9 09:57:07 sally diald[3243]: Changed snoop device to sl0 Jan 9 09:57:07 sally diald[3243]: Diald initial setup completed. Note 3 lines up the message I get if I try to enable proxyarp? I've no idea why this happens Below is a diald session started when I ran ping www.microsoft.com. The first line is a call to my nameserver to resolve the IP address for Microsoft. Jan 9 09:57:18 sally diald[3243]: filter accepted rule 24 proto 17 len 68 packet 127.0.0.2,1140 = 204.244.210.2,53 Jan 9 09:57:19 sally diald[3243]: Running connect (pid = 3431). Jan 9 09:57:20 sally pppd[3431]: pppd 2.2.0 started by root, uid 0 Jan 9 09:57:20 sally chat[3433]: timeout set to 3 seconds Jan 9 09:57:20 sally chat[3433]: abort on (\nBUSY\r) Jan 9 09:57:20 sally chat[3433]: abort on (\nNO ANSWER\r) Jan 9 09:57:20 sally chat[3433]: abort on (\nRINGING\r\n\r\nRINGING\r) Jan 9 09:57:20 sally chat[3433]: send (rAT^M) Jan 9 09:57:20 sally chat[3433]: expect (OK) Jan 9 09:57:20 sally chat[3433]: rAT^M^M Jan 9 09:57:20 sally chat[3433]: OK -- got it Jan 9 09:57:20 sally chat[3433]: send (ATH0^M) Jan 9 09:57:21 sally chat[3433]: timeout set to 30 seconds Jan 9 09:57:21 sally chat[3433]: expect (OK) Jan 9 09:57:21 sally chat[3433]: ^M Jan 9 09:57:21 sally chat[3433]: ATH0^M^M Jan 9 09:57:21 sally chat[3433]: OK -- got it Jan 9 09:57:21 sally chat[3433]: send (ATDT795-2970^M) Jan 9 09:57:21 sally chat[3433]: expect (CONNECT) Jan 9 09:57:21 sally chat[3433]: ^M Jan 9 09:57:23 sally diald[3243]: filter accepted rule 24 proto 17 len 68 packet 127.0.0.2,1141 = 204.244.210.2,53 Jan 9 09:57:38 sally chat[3433]: ATDT795-2970^M^M Jan 9 09:57:38 sally chat[3433]: CONNECT -- got it Jan 9 09:57:38 sally chat[3433]: send (^M) Jan 9 09:57:38 sally chat[3433]: expect (ogin:) Jan 9 09:57:38 sally chat[3433]: 28800/ARQ/V34/LAPM/V42BIS^M Jan 9 09:57:48 sally chat[3433]: Uniserve PRI access server (Chilliwack)^M Jan 9 09:57:48 sally chat[3433]: ^M Jan 9 09:57:48 sally chat[3433]: ^M Jan 9 09:57:48 sally chat[3433]: Login: -- got it Jan 9 09:57:48 sally chat[3433]: send (MYUSERNAME^M) Jan 9 09:57:48 sally chat[3433]: expect (ssword:) Jan 9 09:57:49 sally chat[3433]: MYUSERNAME^M Jan 9 09:57:49 sally chat[3433]: Password: -- got it Jan 9 09:57:49 sally chat[3433]: send (MYPASSWORD^M) Jan 9 09:57:49 sally pppd[3431]: Serial connection established. Jan 9 09:57:50 sally pppd[3431]: Using interface ppp0 Jan 9 09:57:50 sally pppd[3431]: Connect: ppp0 -- /dev/ttyS0 Jan 9 09:57:51 sally diald[3243]: filter accepted rule 24 proto 17 len 63 packet 127.0.0.2,1142 = 204.244.210.2,53 Jan 9 09:57:53 sally pppd[3431]: local IP address 204.244.143.139 Jan 9 09:57:53 sally pppd[3431]: remote IP address 204.244.143.6 At this point, my ping is merely going along sending pings and receiving responses from www.microsoft.com. Then, 57 seconds later (I originally estimated this to be 30 seconds), I get the following. One thing I find interesting about it is that no filter accepted rules appear at this time - only after the connection is terminated. Then, I get more accepted packets and the connection is re-established Jan 9 09:58:50 sally diald[3243]: Connect script timed out. Killing script. Jan 9 09:58:50 sally diald[3243]: Sending SIGINT to (dis)connect
Re: More diald problems.
Kevin Traas [EMAIL PROTECTED] writes: 2. From the docs, I thought diald would establish the default route to the gateway automatically. Am I wrong in my assumption? If so, is what I did to fix the problem the right way to go about it? The right way is to add `defaultroute' to /etc/ppp/options. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Fri, 10 Jan 1997 09:31:43 PST Kevin Traas ([EMAIL PROTECTED]) wrote: 1. Why does diald drop my connection 30 seconds after establishing it, even though there are packets being sent across that would normally keep it alive. (Note - I can do anything across the connection once established, but no matter what (ftp, telnet, etc.) diald still kills the connection.) This is normal. Diald is an intelligent connection handler. It can enable different timeouts depending on the various kinds of packets which go through the link. I guess the ICMP ECHO packets are not maintaining the link. The default is 10minutes for standard TCP packets. Try a telnet, and the link should stay up for 10 minutes. If you want to modify the different timeouts, I'd suggest to read the manpage carefully (thing you're likely not to have done :-). 2. From the docs, I thought diald would establish the default route to the gateway automatically. Am I wrong in my assumption? If so, is what I did to fix the problem the right way to go about it? Do you have a `defaultroute' command in your diald.options file ? Are the addresses of both sides of the link correct in this file too (`local' and `remote') ? Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
Thanks a lot for your reply. Here's some answers to your questions: From: Philippe Troin [EMAIL PROTECTED] To: Kevin Traas [EMAIL PROTECTED] Cc: debian-user@lists.debian.org Subject: Re: More diald problems. Date: Friday, January 10, 1997 3:04 PM On Fri, 10 Jan 1997 09:31:43 PST Kevin Traas ([EMAIL PROTECTED]) wrote: 1. Why does diald drop my connection 30 seconds after establishing it, even though there are packets being sent across that would normally keep it alive. (Note - I can do anything across the connection once established, but no matter what (ftp, telnet, etc.) diald still kills the connection.) This is normal. Diald is an intelligent connection handler. It can enable different timeouts depending on the various kinds of packets which go through the link. I guess the ICMP ECHO packets are not maintaining the link. The default is 10minutes for standard TCP packets. Try a telnet, and the link should stay up for 10 minutes. If you want to modify the different timeouts, I'd suggest to read the manpage carefully (thing you're likely not to have done :-). Uh, yes, I've gone over all the docs, examples, man pages, HOWTOs, minis, etc. that I could find on this - no luck so far, so I'm coming to the debian-user list as a last resort. *NOT* because I'm too lazy to RTFM! grin Anyways, what I was trying to get across is that the connection process works perfectly after I added the route command to setup the default route via /etc/ppp/ip-up. However, NO MATTER WHAT I DO across the connection, diald kills it after only about 30 seconds of uptime. In other words, even if I start a telnet or ftp session, I hardly manage to get connected to the remote site and diald drops the connection and my session hangs. Of course, with these connection-oriented utilities, I've got to start over again when I get reconnected. However, if I run a connection-less utility like ping, it'll ping merrily along for 30 seconds until diald kills the connection and then wait until diald again re-establishes it again. So, right now, I'm in this see-saw situation where even though there are packets that should be resetting the timeouts and stopping diald from dropping the connection, it's not happening. So, diald kills the connection, then realizes there's traffic to send, reconnects, drops, reconnects, drops, reconnects, drops, etc. etc. etc. etc. etc. Get the idea? Oh, and to restate. I haven't changed (or really even looked at) the diald.conf file where timeouts and filtering information is kept. That's all exactly as it came in the 0.14-8 distribution. 2. From the docs, I thought diald would establish the default route to the gateway automatically. Am I wrong in my assumption? If so, is what I did to fix the problem the right way to go about it? Do you have a `defaultroute' command in your diald.options file ? Are the addresses of both sides of the link correct in this file too (`local' and `remote') ? Yep! Even though it's there, it doesn't seem to establish the default route to the ISP's interface. As for the addresses, I've got the following lines in my diald.options file: local 127.0.0.2 remote 127.0.0.3 dynamic This is straight from the man pages and mini-HOWTO. The sl0 interface gets these addresses and then the ppp0 interface gets the real addresses from pppd once the connection is established - from the dynamic option. (I also read somewhere that those addresses *must* be different from the actual ones otherwise the routing changes won't work and everything'll get screwed up I don't have that reference right in front of me right now, but I could find it again, I think.) Do you have any suggestions as to what's wrong here? TIA for your reply, Kevin Traas Systems Analyst Edmondson Roper Chartered Accountants http://users.uniserve.com/~erca Chilliwack, B.C. Pager: (604) 918-2054 Office: (604) 792-1915 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Fri, 10 Jan 1997 17:49:26 PST Kevin Traas ([EMAIL PROTECTED]) wrote: Philippe Troin [EMAIL PROTECTED] wrote: On Fri, 10 Jan 1997 09:31:43 PST Kevin Traas ([EMAIL PROTECTED]) wrote: Anyways, what I was trying to get across is that the connection process works perfectly after I added the route command to setup the default route via /etc/ppp/ip-up. However, NO MATTER WHAT I DO across the connection, diald kills it after only about 30 seconds of uptime. In other words, even if I start a telnet or ftp session, I hardly manage to get connected to the remote site and diald drops the connection and my session hangs. Of course, with these connection-oriented utilities, I've got to start over again when I get reconnected. However, if I run a connection-less utility like ping, it'll ping merrily along for 30 seconds until diald kills the connection and then wait until diald again re-establishes it again. Do you know why diald terminates the connection ? If you've got `debug 31', diald should output a shitload of messages (in /var/log/messages). Would you give us an excerpt ? Basically, every packet that goes through the link causes a message, satsting what rule was applied and the timeout before the closing. BTW, are you able to get anything done during the 30 seconds delay ?I mean, if you telnet somewhere, do you get the login prompt ? Oh, and to restate. I haven't changed (or really even looked at) the diald.conf file where timeouts and filtering information is kept. That's all exactly as it came in the 0.14-8 distribution. I don't know if the stock diald.conf is correct, I've rolled my own one using an old one from an old diald version. I'm thinking of something: try to a `up' keyword to diald.options (meaning to keep the connection running all the time) to see if the problem comes from diald filtering or from something else... Do you have a `defaultroute' command in your diald.options file ? Are the addresses of both sides of the link correct in this file too (`local' and `remote') ? Yep! Even though it's there, it doesn't seem to establish the default route to the ISP's interface. As for the addresses, I've got the following lines in my diald.options file: [snip] Could you send your diald.options file ? That would be easier. Include diald.defs and diald.conf if you've changed them too... And maybe a trimmed (without comments) ppp.options. This will make things easier... Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On 10 Jan 1997, Guy Maor wrote: Kevin Traas [EMAIL PROTECTED] writes: 2. From the docs, I thought diald would establish the default route to the gateway automatically. Am I wrong in my assumption? If so, is what I did to fix the problem the right way to go about it? The right way is to add `defaultroute' to /etc/ppp/options. I have a nagging problem with 'defaultroute' that maybe you can help me with. Everytime diald drops the link due to inactivity, it deletes the default route. After that, diald won't bring the link back up for non-loopback addresses because there aren't any routes. I have to manually force the link back up. Any ideas? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: More diald problems.
On Sat, 11 Jan 1997, David Engel wrote: I have a nagging problem with 'defaultroute' that maybe you can help me with. Everytime diald drops the link due to inactivity, it deletes the default route. After that, diald won't bring the link back up for non-loopback addresses because there aren't any routes. I have to manually force the link back up. Any ideas? It's a bug in diald that has been fixed with the newest release of diald. However, the newest release hasn't been debianized yet by the maintainer (I don't think). I am going to do it myself if a new diald.deb doesn't show up in unstable soon. If you want a copy, email me. Erv ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \ - [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] http://www.linux.org \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
More diald problems.
Just to continue with the problems I'm having with Diald - I'd appreciate any suggestions/comments about what I've provided below. TIA. Note: I have debug 31 enabled for diald. When I try to ping a remote site, diald cranks up the connection to my ISP; however, the ping never received a response. Monitoring /var/log/messages shows diald accepting the ping packets. After about 30 seconds, diald drops the connection. After troubleshooting this, I figured out why the ping wouldn't work once the connection came up. There was no route to the default gateway (my ISP's interface). So, I added route add default gw $5 to /etc/ppp/ip-up and now the ping works fine. However, diald still drops the connection after 30 seconds even though it's still accepting packets coming from the ping command. So, after a default timeout, diald again re-establishes the connection to my ISP and ping starts receiving responses for another 30 seconds until diald drops the connection again. This will continue in an endless cycle. I've left /etc/diald/diald.conf alone so it's configured exactly as it came in the .deb distribution. In the diald man page, under addroute, something was mentioned about how newer kernels will have problems if routes aren't configured properly for the sl0 and ppp0 interfaces before and after the connections are established. Could this be my problem? I've gone over my routing tables and things look okay. I've included them below FYI. Before diald initiates the connection to my ISP, route -n provides: Destination Gateway MaskFlags Metric Interface 127.0.0.3 0.0.0.0 255.255.255.255 UH 2000sl0 x.y.z.128 0.0.0.0 255.255.255.224 U 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 l0 0.0.0.0 127.0.0.3 0.0.0.0 UG 2000sl0 From the docs, everything appears to be configured properly. Note, a dest of 0.0.0.0 equals default. Also, note that x.y.z.128 defines my network segment which is a subnet of a class C address. Thus the .128 net address and the .224 subnet mask. After diald initiates the connection to the ISP, route -n provides: Destination Gateway MaskFlags Metric Interface 127.0.0.3 0.0.0.0 255.255.255.255 UH 2000sl0 a.b.c.d 0.0.0.0 255.255.255.255 UH 2000ppp0 x.y.z.128 0.0.0.0 255.255.255.224 U 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 l0 0.0.0.0 127.0.0.3 0.0.0.0 UG 2000sl0 Note, this is the broken routing table as there is no default gateway to my ISP's interface. So, I've had to manually establish one using /etc/ppp/ip-up (as described above). Once I've done this, routing works fine and the table is as follows: Destination Gateway MaskFlags Metric Interface 127.0.0.3 0.0.0.0 255.255.255.255 UH 2000sl0 a.b.c.d 0.0.0.0 255.255.255.255 UH 2000ppp0 x.y.z.128 0.0.0.0 255.255.255.224 U 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 l0 0.0.0.0 a.b.c.d 0.0.0.0 UG 0 ppp0 0.0.0.0 127.0.0.3 0.0.0.0 UG 2000sl0 So, finally, my questions are: 1. Why does diald drop my connection 30 seconds after establishing it, even though there are packets being sent across that would normally keep it alive. (Note - I can do anything across the connection once established, but no matter what (ftp, telnet, etc.) diald still kills the connection.) 2. From the docs, I thought diald would establish the default route to the gateway automatically. Am I wrong in my assumption? If so, is what I did to fix the problem the right way to go about it? TIA for your help, Kevin Traas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
