Date: Mon, 8 Sep 1997 20:53:34 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: grog@lemis.com (Greg Lehey) Cc: doconnor@ist.flinders.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Divert sockets.. Message-ID: <199709090353.UAA26952@bubba.whistle.com> In-Reply-To: <19970909121148.26417@lemis.com> from Greg Lehey at "Sep 9, 97 12:11:48 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> IMHO, the proper way to do this is to let the PPP daemon handle it > >> by installing a route first (so you let the routing code determine > >> whether packets are supposed to go over the WAN link or not, as it > >> should) and then checking each outgoing packet for suitability as > >> "demand" (not all are, e.g., NTP packets). When "demand" is seen, > >> it should start dialing, etc. The same "demand" test can also apply > >> to idle timeout calculations. This is how mpd does it, anyway. > > > > Yeah, same with ijppp, but it means you can only use those packages to > > do a connection, ie its not very general... > > I don't understand. Which packets do you want to use? If they're not > destined for that interface, they shouldn't cause a dialup. > > > (So its too bad if you have dialon demand ISDN :) > > I don't understand this statement, either. I think what he's saying is that it would be nice to divorce the "dial-on-demand" functionality from the thing that is actually doing the dialing... you could do this with divert sockets, but it would require some sort of "api" to the PPP process not only to tell it to connect (eg, send SIGUSR1), but also to be able to determine whether the link is already up (to avoid a flood of such signals). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709090353.UAA26952>