> What would it take to convince you that it was working? I've been using
> this for about three weeks now with no problems. I've also forwarded
> a variant of the patch to three other people who have not reported problems.
>
> I'd prefer not to have to set up and learn another package if there is
> already functionality in the kernel which handles this transparently.
> Also, the modules package suggests that you can install a dummy request-route
> when installing the rest of the package. Apparently my kernel has been
> invoking this dummy request-route for some time before I finally got around
> to making it do the right thing. When should any problem manifest itself?
>
> On the other hand, if it is not going to be supported and you don't want
> people to test it, shouldn't it be removed completely?
I had a talk a weak ago with Bjorn (the author of the modules package).
Many threads have involved kerneld lately. While, what kerneld does is
pretty simple and useful (Loading modules on demand), the position of
Linus was that kerneld services should not expand in some form of
"default behavior when the kernel don't know what to do".
The strategy should be: The kernel knows what to do, but need help
from a user level module or kerneld itself. The kernel is always in
position to say that it does not want to do something.
The /sbin/request-route as it is currently defined falls in the first
category. Whenever the kernel does not know how to route something, it
calls kerneld which calls request-route. This has several drawbacks.
-Unless you have a default route, you can't limit (unless you use the
firewalling capabilities of linux) triggers to /sbin/request-route.
-If you already have a default route to a net and want to use on demand
ppp to some other private net, /sbin/request-route will nevel be called
because the default route satisfy the kernel.
-You have no control. Any "unroutable packet" will do the trigger.
What has been suggested is to move the kerneld/request-route trigger into
a device. Whenever this device receives a packet, it can trigger kerneld.
The nice things is that you can setup different routes to this device
which will then trigger request-route. So you have full control of which
route do start /sbin/request-route. diald use a similar scheme.
There is still advantages to the kerneld/request-route.
-It is simpler (it represent 10-15 lines of kernel code).
-It can potentially work with any protocol, not only IP.
I have suggest to "throw" this functionnality into the the loopback
device or the dummy device. Your setup would look like
ifconfig dummy0 192.168.1.1
route add -net default dummy0
or
route add -net private-net dummy0
route add -net other-private-net dummy0
route add -net default dummy0
As you see, even if you have on demand dialing to your ISP, you can still
"on demand connect" to your office with the same setup. (You can do this
also with diald I think).
Anyway, this has not been implemented yet. Comments are welcome.
--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Linuxconf: The ultimate administration system for Linux.
sunsite.unc.edu:/pub/Linux/system/Admin/linuxconf-...