PPPD demand disconnect
Jason
I already setup the auto pppd dial on demand.
The internet connection can fire up on demand, but the connection don't
stop on without traffic.
Anybody know how to set auto disconnect?
Thank You very much.
inetport.com
> I already setup the auto pppd dial on demand.
> The internet connection can fire up on demand, but the connection don't
> stop on without traffic.
> Anybody know how to set auto disconnect?
idle <time>, see man pppd.
--
Clifford Kite <kite@inet% port.com> Not a guru. (tm)
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */
Les Hazelton
>
> Jason (jaso...@ctimail.com) wrote:
>
> > I already setup the auto pppd dial on demand.
> > The internet connection can fire up on demand, but the connection don't
> > stop on without traffic.
> > Anybody know how to set auto disconnect?
>
> idle <time>, see man pppd.
>
I am having the same problem. Demand causes the connection but
no-traffic time outs will not close it. I have the idle time set for
600 (10 minutes I think) in the options file.
I think the problem is caused by the tcp_keepalive code in the kernel.
Thing is, I can't locate any way to shut it off short of a kernel
recompile and I don't want to completely remove the function. Just in
case I need it back again.
Does anyone know if stuffing a new value into
/proc/sys/net/ipv4/tcp_keepalive??? will turn this off?
Les
inetport.com
> I am having the same problem. Demand causes the connection but
> no-traffic time outs will not close it. I have the idle time set for
> 600 (10 minutes I think) in the options file.
> I think the problem is caused by the tcp_keepalive code in the kernel.
> Thing is, I can't locate any way to shut it off short of a kernel
> recompile and I don't want to completely remove the function. Just in
> case I need it back again.
I don't *think* that's your problem. I have a similar problem with one
of my ISPs, and the ISP seems to be at fault with what appears to me to
be funky behavior after fetching mail from their mailserver, or trying
to fetch it. Doing "tcpdump -i ppp0" shows that there are requests
coming from the ISP from a reserved network address after the fetch:
10:35:23.180136 xxx.xx.177.23.1036 > xxx.xx.126.1.imap2: P 69:83(14)
ack 437 win 15360 (DF)
10:35:23.320136 xxx.xx.126.1.imap2 > xxx.xx.177.23.1036: P 437:532(95)
ack 83 win 8192 (DF)
10:35:23.320136 xxx.xx.177.23.1036 > xxx.xx.126.1.imap2: F 83:83(0)
ack 532 win 15360 (DF)
10:35:23.330136 xxx.xx.126.1.imap2 > xxx.xx.177.23.1036: F 532:532(0)
ack 83 win 8192 (DF)
10:35:23.330136 xxx.xx.177.23.1036 > xxx.xx.126.1.imap2: . ack 533
win 15360 (DF)
10:35:23.450136 xxx.xx.126.1.imap2 > xxx.xx.177.23.1036: F 532:532(0)
ack 84 win 8192 (DF)
10:35:25.460136 192.168.4.3.imap2 > xxx.xx.177.23.1036:
F 3208948448:3208948448(0) ack 3195073599 win 8192 (DF)
10:35:25.460136 xxx.xx.177.23.1036 > 192.168.4.3.imap2:
R 3195073599:3195073599(0) win 0
10:35:30.460136 192.168.4.3.imap2 > xxx.xx.177.23.1036: F 0:0(0)
ack 1 win 8192 (DF)
10:35:30.460136 xxx.xx.177.23.1036 > 192.168.4.3.imap2:
R 3195073599:3195073599(0) win 0
and more of mostly the same. It finally ends and 5 minutes later my
"idle 300" ends the session. If anyone reading this knows what's
happening here I'd appreciate a post explaining it.
> Does anyone know if stuffing a new value into
> /proc/sys/net/ipv4/tcp_keepalive??? will turn this off?
I see
/proc/sys/net/ipv4/tcp_keepalive_probes
/proc/sys/net/ipv4/tcp_keepalive_time
with a 2.2.13 kernel, but no other tcp_keepalive.
The default tcp_keepalive_time interval is 2 hours and, if my *guess*
as to what this means is correct, it would not defeat a 10 minute idle
time out.
--
Clifford Kite <kite@inet% port.com> Not a guru. (tm)
/* The signal-to-noise ratio is too low in many [news] groups to make
* them good candidates for archiving.
* --- Mike Moraes, Answers to FAQs about Usenet */
Les Hazelton
>
> The default tcp_keepalive_time interval is 2 hours and, if my *guess*
> as to what this means is correct, it would not defeat a 10 minute idle
> time out.
>
Right you are. I just went back and looked at the value of
tcp_keepalive_time and it is set to 7200 (2 hours). I should have paid a
bit more attention to the value before I jumped to the wrong conclusion.
That can't be the problem. The down side is, now I need to find a
different cause :-(
Les
Stefan Boresch
Trying ppp on demand (with pppd or diald) a while ago, I even
posted the problem here, ... I never solved it and gave up on
ppp on demand.
Maybe my findings help, or by now someone has a clever idea:
Same problem, ppp on demand started fine, but never terminated.
After a while, I found my(!) culprit. It was not a mail program/connection, but
Netscape (4.0.7): Say you browsed a site, then let the display sit
idle, so pppd (diald) terminated after the timeout. (Worked always great
the first time). Now you decided that you wanted to follow that link
after all, you click, the modem dials -- after a while, you got the
page. Only this time, the connection would never terminate. Using
tcpdump, I saw that there suddenly was some traffic going on between
my ISP and Netscape, with one side (that part I could never quite figure
out) still believing that it was still at the original IP address, which
of course was (usually) different after the redial. Note, this did
not affect browsing at all, just some garbage traffic occured which
kept the connection up forever...
BTW, this could be reproduced with the most simple pages -- and there
was no such problem when using kfm to view them...
For the time being I gave up on ppp on demand, so I
can't help the original poster, but maybe someone has ideas
that could help all of us. (I am happy to do some further debugging
if someone tells me what to do...)
Stefan Boresch
--
Institute for Theoretical Chemistry phone: -43-1-427752715
University of Vienna FAX: -43-1-427752790
Waehringerstr. 17 -43-1-4028525
A-1090 Vienna, Austria
Jason
My setting is
/etc/ppp/options
modem
demand
idel 600
lock
crtscts
asyncmap 0
defaultroute
connect "/usr/sbin/chat -v -f /etc/ppp/ctiscript"
/dev/ttyS1
0.0.0.0:0.0.0.0
noipdefault
ipcp-accept-remote
ipcp-accept-local
Bill Unruh
>Les Hazelton (sea...@attglobal.net) wrote:
>> I am having the same problem. Demand causes the connection but
>> no-traffic time outs will not close it. I have the idle time set for
>> 600 (10 minutes I think) in the options file.
Some ISPs keep sending LCP EchoReq packets every few seconds to see if
you are still alive. Do not know if pppd ignores such in its idle timer
Also some web pages seem to keep going back for more, and keep any link
open. So on my system sometimes idle timeour works, and sometimes it
does not. Fortunately in NAmerica we are not charged for connect time.
Try doing a tcpdump on your connection and leave it idle and see what
comes down the line. Also put the debug option into pppd and see if
there are extra packets coming in that way.
Les Hazelton
time-out disconnect. With my idle time set for 10 minutes, the line
would drop for lack of activity at about 10 minutes. Then it would
reconnect in about 5 minutes, stay up for 10 and start the cycle over
again.
When I rechecked what processes I had running I saw two suspects. Xntpd
and named. I removed any references to external time servers in the
/etc/ntpd.conf file and restarted xntpd. That had no effect on the
problem.
I also re-scanned the messages in /var/log/messages and found some
obscure named messages about the default time to live values for the
local intranet domain. I also found an obvious error in the setup for
the local lan component of the name server. I eliminated all complaints
from named with a series of edit and restart attempts. Once the named
warning messages were eliminated, the time-out/reconnect cycle was also
eliminated.
Now the link times out for lack of activity and stays down until I do
something like click a web page link etc..
Les