How to implement pppIp MIB on Linux - PPP

This is a discussion on How to implement pppIp MIB on Linux - PPP ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: How to implement pppIp MIB on Linux

  1. How to implement pppIp MIB on Linux

    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


  2. Re: How to implement pppIp MIB on Linux

    "Chris Nelson" writes:
    > 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 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

  3. Re: How to implement pppIp MIB on Linux

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > 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.

    > (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.


  4. Re: How to implement pppIp MIB on Linux

    "Chris Nelson" writes:
    > > 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. ;-}

    > > (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.

    > 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.

    > 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.

    > 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


    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.

    > }
    >
    > 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.

    > 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 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

  5. Re: How to implement pppIp MIB on Linux

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > > 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.

    > ...
    > 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.

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

    > 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.

    > > 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.

    > > ... Is there a standard API to find the name of the underlying
    > > serial device given a ppp interface name?

    >
    > No.


    :-(

    > > 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

    >
    > 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.

    > ...
    > > 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.


  6. Re: How to implement pppIp MIB on Linux

    "Chris Nelson" writes:
    > > 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.

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

    > > > 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 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

+ Reply to Thread