The weird errors I reported I was getting in the log files form diald-0.99 don't matter, it seems: they are an indication the system is actually doing the "right thing". Here is the explanation from the diald maintainer (BTW, I've had no other detectable problems with diald-0.99 so far under the 2.2 kernels so this amounts to a clean bill of health for diald-0.99 as far as I can see). Mike Jagdis wrote:

On Tue, 25 May 1999, Ralph Clark wrote:

...

running '/etc/suseppp/scripts/generic.connect' connector: shell-init: could not get current directory: getcwd: cannot access parent directories: No such file or directory

When shells start (bash in particular) they like to get the name of your current working directory up front. In this case you (or rather your connect script and therefore diald) do not seem to have one. My guess is that you started diald by hand and then deleted the directory you were in at the time (which would have been diald's current working directory). It's not fatal but _is_ annoying :-).

...

running '/sbin/ifconfig tap0 193.237.131.114 pointopoint 158.152.1.222 broadcast 0.0.0.0 netmask 255.255.255.255 metric 0 mtu 1500 up' start tap0: SIOCSIFMETRIC: Operation not supported SIGCHLD[55]: pid 6267 system, status 256

2.2.x kernels do not support metric on interfaces. I am told this is as intended as there is "no use" for it. Combined with route auto-creation it means that if you want a non-default metric for your demand links you either need to run a heavyweight routing daemon such as gated or hope that the window between diald configuring the interface and deleting the unintended low-metric routes that are auto-created is "sufficiently small" for your purposes.

Add and delete route messages are due to diald trying to be robust about what routes exist. Some kernels auto-create routes, some don't. Sometimes remote hang ups cause a daemon (such as pppd) to take interfaces and routes down, sometimes they don't. These messages aren't normally a problem. They just indicate that what diald wanted to happen has already happened due to some external influence.

...

running '/sbin/ifconfig ppp0 0.0.0.0' ppp: ppp0 not active stop ppp0: SIOCSIFFLAGS: Device not configured

Now that one is an "unbug". We shouldn't be even trying to ifconfig transient interfaces like ppp and slip at this stage. If this had succeeded it would have left ppp0 lying around up but with no useful address or routes. Even so the kernel would have seen it was up and not reused it next time you wanted a ppp interface, leading to an interface leak with each connection. This is an "unbug" because the ifconfig failed. The bug does actually occur though and if your ppp<n> numbers are climbing you can just ifconfig ppp<n> down a few of them. (I've been up past 75 before now)

This bug should be gone when 0.99.1 is released :-).

Mike

-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: jaggy@purplet.demon.co.uk | | 280, Silverdale Road, Earley, | Voice: +44 118 926 6996 | | Reading RG6 7NU ENGLAND | Work: +44 118 989 0403 | `----------------------------------------------------------------------'

-- rclark@virgosolutions.demon.co.uk 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 get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e Check out the SuSE-FAQ at <A HREF="http://www.suse.com/Support/Doku/FAQ/"><A HREF="http://www.suse.com/Support/Doku/FAQ/</A">http://www.suse.com/Support/Doku/FAQ/</A</A>> and the archive at <A HREF="http://www.suse.com/Mailinglists/suse-linux-e/index.html"><A HREF="http://www.suse.com/Mailinglists/suse-linux-e/index.html</A">http://www.suse.com/Mailinglists/suse-linux-e/index.html</A</A>>