Post by Chris NelsonPost by James CarlsonAt least for that part, what's wrong with SIOCGIFFLAGS?
Aside from the fact that I can find no documentation of it, nothing. I
considered ioctl() but it's not something I've used often enough to be
comfortable. And I'd been led to believe that /proc was emerging as
the preferred way to get that sort of information on Linux. Maybe I
was misled.
SIOCGIFFLAGS is widely portable, and has been a part of all BSD-like
TCP/IP implementations for at least 20 years. But perhaps that
doesn't matter.
If the question is really about Linux architectural direction, then I
don't think I'm qualified to answer, nor is this really the right
place to address the question. You should look around at Linux-
related resources (kernel.org mailing lists and the like) to find
better answers.
I'd imagine that using any of the /proc bits would essentially make
the program non-portable. That might be a consideration, but if
you're not concerned about it, then neither am I. ;-}
Post by Chris NelsonPost by James Carlson(Or are you looking to determine the mapping from link name to
authenticated peer name, or some other value?)
I want enough information to implement at least pppIp, probably pppLcp.
The former requires information about admin status (is the link
enabled or disabled), operational status (is the link up or down),
Operational status is easy; SIOCGIFFLAGS gives you that.
Admin status is shakier. Some assert that IFF_UP (from those flags)
gives you admin status, while IFF_RUNNING gives you operational
status. Perhaps. Others look to configuration files to glean admin
intent.
There is, as far as I know, no "standard" that maps OS implementation
bits into MIBs.
Post by Chris Nelsondata
compression (in each direction), and "MaxSlot" ("The Max-Slot-Id
parameter that the remote node has advertised and that is in use on the
link. If vj-tcp header compression is not in use on the link then the
value of this object shall be 0. " -- RFC 1473) The latter needs
information about asyncmap, protocol compression (not clear how that's
different from what's in pppIP), and more.
Those bits are known in a couple of places: the pppd daemon itself,
and the kernel modules. The kernel modules can be coaxed into
revealing their secrets -- see the ``pppstats'' program for an
example. Pppd itself has no run-time administrative interface.
Post by Chris NelsonFor my purposes -- whether this is in a standard MIB or I have to put
it in a private one -- I'd like to be able to say, "ppp0 is on ttyS01"
via SNMP. Is there a standard API to find the name of the underlying
serial device given a ppp interface name?
No.
Post by Chris NelsonFor that matter, I can do
char ifc[5];
size_t i;
for (i=0; i < 10; ++i) {
sprintf(ifc, "ppp%d", i);
// Do something here to see if ifc exists, get its values
That looks like a mistake on multiple fronts.
If you're looking for IP interfaces, the standard way to get these (on
Linux, *BSD, and other systems) is with SIOCGIFCONF. It returns a
list of IP interfaces by name.
Post by Chris Nelson}
but it'd be nice if there was an API I could call to find the existing
ppp interfaces (or existing interfaces, I could test for matching
"ppp*").
See above.
Post by Chris NelsonSorry if these are stupid questions, I usually work at a higher,
mostly-platform-independent level. I've written an IGMP router and
implemented RSTP but that's just C, not OS details.
An IGMP implementation that never needs to know about physical
interfaces ... ?
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677