Messages in this thread |  | | Date | Tue, 2 Jul 1996 00:25:48 -0400 (EDT) | From | Jacques Gelinas <> | Subject | kerneld/request-route: An idea |
| |
On Mon, 1 Jul 1996, Chris Faylor wrote:
> 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-...
|  |