Date: Sat, 7 Mar 1998 01:23:31 -0700 (MST) From: allen campbell <allenc@verinet.com> To: rneswold@mcs.net Cc: hackers@FreeBSD.ORG Subject: Re: Detecting state of PPP Message-ID: <199803070823.BAA20947@const.>
next in thread | raw e-mail | index | archive | help
> #!/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803070823.BAA20947>