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.
Have a look at the rpm containing example diald configurations for 'expensive'
metered connections. It's on contrib.redhat.com, I found it on my local mirror
as:
ftp://sunsite.doc.ic.ac.uk/Mirrors/contrib.redhat.com/noarch/noarch/diald-config-metered-0.2-2.noarch.rpm
> 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.
Set the option "debug 31" in your diald options file (I believe it could go in
your diald.conf or diald.defs but, pace SuSE Linux 5.3, I keep my diald options
of that nature in a saparate file via diald's "-file" option.
My options file looks like this:
device /dev/modem
-m ppp
debug 31
speed 115200
two-way
local my.static.ip.address
remote isps.static.ip.address
reroute
defaultroute
disconnect-timeout 60
redial-timeout 0
dial-fail-limit 5
fifo /var/run/diald.ctl
The debug 31 option will generate messages like this in the system messages log
file, as directed by /etc/syslog.conf:
filter accepted rule 9 proto 6 len 295 seq f4e10d7d ack bbd0a25b flags PUSH ACK
packet 195.11.50.200,8080 => 193.237.131.114,2742
filter ignored rule 5 proto 6 len 40 seq f4e10e7c ack bbd0a25b flags FIN ACK
packet 195.11.50.200,8080 => 193.237.131.114,2742
As you can see it's not too informative if you are using an external http proxy
so disable such proxying while you are investigating.
The rule numbers quoted are allocated sequentially to your filter rules in the
order they appear in your diald configuration files, i.e. the first filter rule
to appear is rule no. 1. The 'proto' protocol number is the protocol number of
the service as allocated in /etc/protocols. The number separated by a comma from
the IP address is the port number of the service used, as allocated in
/etc/services.
I haven't yet found a way to identify which process is responsible for each
packet. If anyone knows how to find the PID of the process sending or receiving
a given packet (and presumably this involves finding out which socket it is
going to or coming from, and separately identifying the process which is using
that socket) ... PLEASE let me know.
--
[EMAIL PROTECTED] Ralph Clark, Virgo Solutions Ltd (UK)
__ _
/ / (_)__ __ ____ __ * Powerful * Flexible * Compatible * Reliable *
/ /__/ / _ \/ // /\ \/ / *Well Supported * Thousands of New Users Every Day*
/____/_/_//_/\_,_/ /_/\_\ The Cost Effective Choice - Linux Means Business!
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
