Greetings,
I just recently upgraded from diald 0.16.5 to 0.99.1 (I upgraded the entire
system from Debian slink to Debian potato, and Linux 2.0 to Linux 2.2), and
encountered a few problems. I know, it's quite a leap, and it probably
accounts for most of the problems I encountered.
The list below is rather disparate, and I apologize if it sounds overly
critical, the upgrade hasn't gone terribly well. I use diald rather
heavily, and would be sorely inconvenienced if it wasn't there.
Anyways, the first problem I'm seeing is an error in my syslog: "SIOCADDRT:
File exists". I assume this is because of Linux 2.2's annoying habit of
adding a route for you when you bring up an interface. This is more of an
annoyance complaint than a bug report; I ended up writing a wrapper script
around route that filtered out errors I didn't want to see (btw, thanks for
that path-route option, it would've been difficult to do without it).
The second problem is also an error I'm seeing in my syslog: "SIOCSIFMETRIC:
Operation not supported". This may or may not be simply an annoyance. I
notice that diald attempts to setup a metric for each interface and route,
but I'm not sure if they have to match up to make any difference to routing
daemons. It appears that, at some point, Linux went from not using the
metric setting on an interface (2.0.36's net/core/dev.c sets the metric for
the interface, but there's a comment above saying it's unused), to actively
disallowing it (2.2.14's net/core/dev.c returns -EOPNOTSUPP).
The third problem is more of a documentation suggestion. In README.masq you
suggest having the addroute script setup your masquerading rules. With
Linux 2.0's ipfwadm or Linux 2.2's ipchains you can specify an interface
that a packet has to be destined for in your forward rule:
ipfwadm -F -a masq -S 192.168.1.0/24 -W ppp0
ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j MASQ
It seems to me that, by specifying the interface, the issue about a
masqueraded packet going over the ethertap interface (or slip, as the case
may be) no longer exists. If the forwarding policy is to deny, one of the
following would be required as well:
ipfwadm -F -a accept -S 192.168.1.0/24 -W tap0
ipchains -A forward -s 192.168.1.0/24 -i ppp0
I'm not sure how exactly to verify this, but it would appear to work.
The fourth problem is a an actual bug report. It seems the timeout settings
in my filter are being ignored. After setting the debug option to
FILTER_MATCH I verified that the rule that matched, and brought up the
connection, had a timeout value of 60 seconds, but the connection goes down
after only 30. Am I doing something wrong?
The fifth (oh yea, there's a fifth) is a problem I was having with Linux
2.0.36. After first starting diald, it would bring up the connection
normally when there was traffic. However, after dropping the connection and
sitting idle for a while, I would send traffic again, but it wouldn't bring
up the connection. I would see the following in my syslog:
bind snoopfd: Bad file descriptor
After upgrading to Linux 2.2, the problem disappeared. It may be that the
(precompiled) diald that comes with Debian potato was somehow tied to Linux
2.2, or it may be an actual bug.
Whew. Sorry for the long and rambling report.
I'd be willing to play with my configuration and setup for debugging if
necessary. I still have my 2.0.36 kernel around and bootable, as well.
Michael Fowler
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
