From owner-freebsd-hackers Sat Mar 7 00:23:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10229 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 00:23:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from const. (tulip14.verinet.com [199.45.181.206]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA10224 for ; Sat, 7 Mar 1998 00:23:30 -0800 (PST) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id BAA20947; Sat, 7 Mar 1998 01:23:31 -0700 (MST) (envelope-from allenc) Date: Sat, 7 Mar 1998 01:23:31 -0700 (MST) From: allen campbell Message-Id: <199803070823.BAA20947@const.> To: rneswold@mcs.net Subject: Re: Detecting state of PPP Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > #!/bin/sh > ifconfig -l -u | grep -q tun0; This tells you something is happening on a tun interface. It doesn't tell you what is happening. My pseudo code tests for a specific 'section' from ppp.conf. This is important when several different ppp sections exist. I currently have four sections configured for various ppp hosts. Two of those sections are for different ppp hosts at the same institution (a private institution using RFC-1918 addresses.) Due to circumstances beyond my control, certain operations can be performed via one host and not the other. Being able to easily determine which of the two ppp hosts is in use might be useful. As another example, I regularly use two different ISPs. I maintain a mailbox with the primary ISP, and the secondary ISP provides no SMTP service. As is usual, the primary ISP will not forward mail from remote hosts. Attempts to send mail via SMTP while connected to the secondary ISP will be rejected. Again, it would be useful to be able to determine which dial-up host is in use, and quietly queue mail as needed. I realize there are many ways to overcome these issues. One might consider parsing netstat(1) output for patterns that would indicate which ppp host had assigned an interface address. This works as long as a) any one ppp host always assigns from the same range and b) no two ppp hosts assign from ranges which overlap (RFC-1918 again.) Or perhaps a reverse name lookup on the interface address, provided a) a name server is available and b) the peer host name doesn't suddenly change. Perhaps sendmail (and friends) many could be butchered to queue rather than bounce when a 'we do not forward' error occurs. Etcetera, etcetera. The fundamental problem here isn't a lack of special utilities for ppp, but rather the assumption that interfaces are static. None of the canonical daemons have the ability to vary their behavior based on the status of a particular interface (discounting the ability to log a failure,) even if you could identify the current ppp host. ('Never' is a vague word, however, and I don't presume to know the implementation details of all daemons.) You will understand that I mean this generally; dynamic network connections have not been considered in the design of most systems (DNS being an excellent example.) Solving this problem involves being able to query the status of abstract network interfaces and modifying behavior based on the results. Fortunately, most of the operations one might wish to perform via a ppp link are deterministic; you establish a connection, perform some operation and disconnect. You always know which host your dealing with while the link is up. This should sound familiar to current and (thankfully?) former UUCP administrators. :) Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message