Subject: Interfacing dial-on-demand to the kernel
To: None <current-users@NetBSD.ORG>
From: Martin Husemann <firstname.lastname@example.org>
Date: 03/15/1995 08:32:14
How would you interface a dial-on-demand daemon to the kernel?
I'll need such a daemon to manage ISDN connections, but I think a global
approach which covers PPP and CSLIP connections as well would be
the way to go.
The only system I've used with dial-on-demand is SCO Unix, and I consider
that totaly broken (it uses the UUCP subsystem to manage the dialing and
some [still mysterious to me] way connects the uucp system name to the
I thought of a pseudo-network-interface (demand0 ?) to which all routes
are directed. This interface would comunicate with a user-land daemon
which looks up the destination address, assigns a free device to dial
(out of the propper class of device of course) and spawns a process
to do the dialing (device dependend, you don't use AT commands on an
ISDN interface). If the dial succeeds the route is changed from the
pseudo interface to the now functional real interface. The dial process
watches the connection and reverts the route when the connection goes
down (actualy it may be involved in adaptive timeout and actively dropping
There are a lot of open questions, e.g. should the packet queued for
the pseudo-interface be retransmitted over the actual interface when
that comes available? (No for tcp, yes for udp?) How should long
dial times be managed (ISDN doesn't have them, but my modem at home
still has to use ATDP...).
Maybe there is a far better, cleaner, straightforward way to do this -
or even anyone already working on it?
5:58 am: dawn strikes Oerlinghausen