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: [EMAIL PROTECTED] |
| 280, Silverdale Road, Earley, | Voice: +44 118 926 6996 |
| Reading RG6 7NU ENGLAND | Work: +44 118 989 0403 |
`----------------------------------------------------------------------'
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
