From owner-freebsd-questions Fri Nov 8 07:41:39 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA15068 for questions-outgoing; Fri, 8 Nov 1996 07:41:39 -0800 (PST) Received: from post-ofc04.srv.cis.pitt.edu (root@post-ofc04.srv.cis.pitt.edu [136.142.185.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA15063 for ; Fri, 8 Nov 1996 07:41:35 -0800 (PST) Received: from unset.rmt.net.pitt.edu (ehdup-c1-9.rmt.net.pitt.edu [136.142.20.139]) by post-ofc04.srv.cis.pitt.edu with SMTP (8.8.2/cispo-2.0.1.7) ID ; Fri, 8 Nov 1996 10:33:11 -0500 (EST) Message-ID: <32835425.167EB0E7@pitt.edu> Date: Fri, 08 Nov 1996 10:39:17 -0500 From: John Duncan Organization: Gaussian Diffusion X-Mailer: Mozilla 3.0 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Suggestion for iijppp's demand dial. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk IIJPPP is neato, I thought, except it ended up being not worth using because of its clumsy interface and the fact that it would only demand-dial if you had a preset default route. I don't have one. Perhaps there could be an additional lkm-style network driver that would use about 2k at the most called 'iijdd0' which would be the demand-dial line that programs could use, and when something came through iijdd0, it would route it to whatever ended up being the default route through which iijppp would normally send the data after dialing. I think that would be much easier to set up, in the long run, so we wouldn't have to play around with those annoying network numbers. My problem here is that at Pitt, we have machines named ehdup-#.ts.net and each of those routers has 16 hardwired lines, ehdup-#-x.rmt.net and those hardwired lines all have unique addresses, registered with the nameserver. Chances of getting the same router twice are like 1 in 30. So what I was thinking was that localhost could be connected to imaginary as the default route, and when a packet came down the imaginary route, 10.17.32.1 or whatever you please, it would wait until iijppp dialed and connected tun0, and then it would route the packet through the point on tun0 once that route was established. Furthermore, we would be able to run Kerberos, timed, and other network-based things over tun0 without requiring a dedicated line. Hmm... the possibilities are endless. -jd