Re: More diald problems.
Thanks a lot for your reply. Here's some answers to your questions:
> From: Philippe Troin <phil@fifi.org>
> To: Kevin Traas <ktraas@uniserve.com>
> 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" (ktraas@uniserve.com)
> 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
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: