Discussion:
How to implement pppIp MIB on Linux
(too old to reply)
Chris Nelson
2006-05-01 19:57:37 UTC
Permalink
I'm uncertain how to implement the pppIp MIB on Linux. I've got some
of it filled in from my configuration but how do I determine if the
link is up? I guess I can see if /dev/sys/net/ipv4/conf/ppp0 is empty
or if there's a ppp0: line in /proc/net/dev but both of those seem a
little kludgy. Or is there an implementation I just have to build.
Any pointers appreciated.

Chris
James Carlson
2006-05-01 20:14:47 UTC
Permalink
Post by Chris Nelson
I'm uncertain how to implement the pppIp MIB on Linux. I've got some
of it filled in from my configuration but how do I determine if the
link is up? I guess I can see if /dev/sys/net/ipv4/conf/ppp0 is empty
or if there's a ppp0: line in /proc/net/dev but both of those seem a
little kludgy. Or is there an implementation I just have to build.
Any pointers appreciated.
At least for that part, what's wrong with SIOCGIFFLAGS?

(Or are you looking to determine the mapping from link name to
authenticated peer name, or some other value?)
--
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
Chris Nelson
2006-05-02 12:06:06 UTC
Permalink
Post by James Carlson
Post by Chris Nelson
I'm uncertain how to implement the pppIp MIB on Linux. I've got some
of it filled in from my configuration but how do I determine if the
link is up? I guess I can see if /dev/sys/net/ipv4/conf/ppp0 is empty
or if there's a ppp0: line in /proc/net/dev but both of those seem a
little kludgy. Or is there an implementation I just have to build.
Any pointers appreciated.
At 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.
Post 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), data
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.

For 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? For that matter, I can do
something like:

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
}

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*").

Sorry 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.
James Carlson
2006-05-02 12:51:29 UTC
Permalink
Post by Chris Nelson
Post by James Carlson
At 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 Nelson
Post 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 Nelson
data
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 Nelson
For 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 Nelson
For 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 Nelson
Sorry 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
Chris Nelson
2006-05-02 13:36:43 UTC
Permalink
Post by James Carlson
Post by Chris Nelson
Post by James Carlson
At 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.
I always prefer portable over non- if I have a choice.
Post by James Carlson
...
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. ;-}
If I can get the data in a portable way, I'd prefer that.
Post by James Carlson
...
Post by Chris Nelson
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.
Some OSs implementations or some network programmers? If the former, I
can to write a portable MIB implementation that has some #ifdef code to
handle the difference (though I only care about Linux right now).
Post by James Carlson
There is, as far as I know, no "standard" that maps OS implementation
bits into MIBs.
I'm not sure what you mean by that.
Post by James Carlson
Post by Chris Nelson
data
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.
OK. I'll look at pppstats. Thanks.
Post by James Carlson
Post by Chris Nelson
... Is there a standard API to find the name of the underlying
serial device given a ppp interface name?
No.
:-(
Post by James Carlson
Post by Chris Nelson
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.
OK. Thanks again.
Post by James Carlson
...
Post by Chris Nelson
Sorry 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 ... ?
It's in an embedded system that controls a switch chip. I get all my
data via eth0 or eth1 with some extra data tacked on that tells me what
switch chip port it arrived on.
James Carlson
2006-05-02 14:36:01 UTC
Permalink
Post by Chris Nelson
Post by James Carlson
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.
Some OSs implementations or some network programmers?
Both, really.
Post by Chris Nelson
If the former, I
can to write a portable MIB implementation that has some #ifdef code to
handle the difference (though I only care about Linux right now).
Post by James Carlson
There is, as far as I know, no "standard" that maps OS implementation
bits into MIBs.
I'm not sure what you mean by that.
Just what I said: there is no standard (no written document, no agreed
on formula) that governs how any SNMP agent implementation uses or
could use artifacts of operating system implementation (such as SIOC*
flags or /proc entries) to produce the behaviors required by the SNMP
MIBs (including, for example, ifOperStatus).

It's something you have to resolve for yourself as part of designing
an SNMP agent.
Post by Chris Nelson
Post by James Carlson
Post by Chris Nelson
Sorry 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 ... ?
It's in an embedded system that controls a switch chip. I get all my
data via eth0 or eth1 with some extra data tacked on that tells me what
switch chip port it arrived on.
Oh.
--
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
Loading...