Per Ralph Clark, I'm now running "/usr/sbin/diald debug 31 -daemon", and
getting lots of info. I noticed that while I am generating no activity
via Netscape (see original note, below), diald sends a packet every 10
seconds or so:
diald[730]: filter accepted rule 41 proto 88 len 60 packet
207.66.20.23,0 => 224.0.0.10,0
Rule 41 is "accept any 30 any".
207.66.20.23 is my ISPs router.
224.0.0.10 is IGRP-ROUTERS.MCAST.NET, which has something to do with
multicasts, I believe.
Although "88" doesn't appear in "/etc/protocols",
[root]# cat /etc/services |grep 88
kerberos 88/udp kdc # Kerberos authentication - udp
kerberos 88/tcp kdc # Kerberos authentication -
tcp
I'm not knowingly doing any Kerberos authentication.
Per Bob Chiodini, I added "impulse 240,30" at the end of the
"/usr/lib/diald/standard.filter". I was overjoyed when this seemed to
fix my redialling problem! At that juncture I foolishly decided to
remove other lines I had added to that file during the long while I've
been trying to fix my problem. I then noticed that I had unfixed my
problem, and have been unable to refix it (although I believe I've
restored the file to the state it was in just after adding "impulse
240,30").
Here's my "/usr/lib/diald/standard.filter":
# begin diald rules
#
# rules 1 thru 5
keepup tcp 120 tcp.ack,tcp.source=tcp.www
keepup tcp 120 tcp.ack,tcp.dest=tcp.www
keepup tcp 60 tcp.ack,tcp.source=tcp.ftp-data
keepup tcp 60 tcp.ack,tcp.dest=tcp.ftp-data
keepup tcp 60 tcp.ack,tcp.source=tcp.ftp
# rules 6 thru 10
keepup tcp 60 tcp.ack,tcp.dest=tcp.ftp
keepup tcp 20 tcp.ack
ignore tcp tcp.ack
accept tcp 15 tcp.syn
accept tcp 30 tcp.dest=tcp.domain
# rules 11 thru 15
accept tcp 30 tcp.source=tcp.domain
accept tcp 5 ip.tot_len=40,tcp.syn
ignore tcp ip.tot_len=40,tcp.live
accept tcp 120 tcp.dest=tcp.www
accept tcp 120 tcp.source=tcp.www
# rules 16 thru 20
keepup tcp 5 !tcp.live
ignore tcp !tcp.live
accept tcp 60 tcp.dest=tcp.ftp
accept tcp 60 tcp.source=tcp.ftp
accept tcp 60 tcp.dest=tcp.ftp-data
# rules 21 thru 25
accept tcp 60 tcp.source=tcp.ftp-data
keepup tcp 60 any
ignore udp udp.dest=udp.who
ignore udp udp.source=udp.who
ignore udp udp.dest=udp.route
# rules 26 thru 30
accept tcp 60 tcp.source=tcp.ftp-data
ignore udp udp.source=udp.route
ignore udp udp.dest=udp.ntp
ignore udp udp.source=udp.ntp
ignore udp udp.dest=udp.timed
# rules 31 thru 35
ignore udp udp.source=udp.timed
ignore udp udp.dest=udp.domain,udp.source=udp.domain
accept udp 30 udp.dest=udp.domain
accept udp 30 udp.source=udp.domain
ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
# rules 36 thru 40
accept udp 30 udp.dest=udp.netbios-ns
accept udp 30 udp.source=udp.netbios-ns
ignore udp tcp.dest=udp.route
ignore udp tcp.source=udp.route
accept udp 30 any
# rule 41
accept any 30 any
#
# check for idle link after 4 minutes; monitor 30 seconds
impulse 240,30
# end diald rules
Any more ideas? Perhaps you could post your file "standard.filter". By
the way, my diald is 0.16.5, kernel 2.0.34.
Thanks for your help! - Mark
Mark Johnson wrote:
> Diald seems to want to keep connected at all times.
>
> When the connection has been inactive for about 25 minutes, it appears
> that my ISP drops the connection. Immediately, diald redials the ISP.
> For example, here's a typical sequence
> 1. Kill and restart diald ("/usr/sbin/diald debug 0x009c -daemon") on
> my linux gateway/BIND nameserver/firewall; diald does not connect.
> 2. Run Netscape 4.5 from a connected NT box, and diald connects.
> 3. Close Netscape.
> 4. After a while, I get logged messages like:
> May 27 11:52:50 linuxbox diald[4158]: Link died on remote end.
> May 27 11:52:54 linuxbox diald[4158]: Running connect (pid=4687).
>
> I'd like to get diald configured so that when my ISP drops the
> connection, diald doesn't bring it up again until needed. Better yet,
> I'd like to hangup from my end if there has been no significant
> activity for, say, 10 minutes.
>
> In order to understand what's happening, I'd like to examine diald's
> activities in detail. However, I've been unable to figure out how to
> run diald so that I can see the packets its receiving, the rules it
> applies to the packets, and what "connection identities" are in the
> "connection set" at the time of the redial.
>
> Please help! TIA
>
> - To unsubscribe from this list: send the line "unsubscribe
> linux-diald" in the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]