[lkml]   [1996]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectkerneld/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
    route add -net default dummy0


    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 (
    Linuxconf: The ultimate administration system for Linux.

     \ /
      Last update: 2005-03-22 13:37    [W:0.030 / U:18.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site