apps for monitoring Dial up PPP quality - PPP

This is a discussion on apps for monitoring Dial up PPP quality - PPP ; Hi, Does anyone of you guys know if there is an app which would report ppp quality of service I am looking for unix based solution. thanks a lot, Hubert....

+ Reply to Thread
Results 1 to 6 of 6

Thread: apps for monitoring Dial up PPP quality

  1. apps for monitoring Dial up PPP quality

    Hi,

    Does anyone of you guys know if there is an app which would report ppp
    quality of service
    I am looking for unix based solution.

    thanks a lot,

    Hubert.



  2. Re: apps for monitoring Dial up PPP quality

    An excellent question. Does pppd support RFC1333
    (http://www.faqs.org/rfcs/rfc1333.html)? It doesn't appear so... we're
    trying to figure out an (efficient) way to monitor the quality of ppp
    conenctions on our server as well.

    Any suggestions out there?
    (Too bad this group and linux-ppp mailing list are so inactive).


  3. Re: apps for monitoring Dial up PPP quality

    In article , Hubert K wrote:

    >Does anyone of you guys know if there is an app which would report ppp
    >quality of service


    [compton ~]$ whatis pppstats
    pppstats (8) - print PPP statistics
    [compton ~]$

    Is that what you have in mind?

    >I am looking for unix based solution.


    Unix is a trademark that covers IBM's AIX to Sun's Solaris, but not Linux
    or the free BSDs. Care to be a little more specific? The 'pppstats'
    program is a part of ANU pppd, which currently runs on Linux and Solaris.
    Older versions were available for other O/S.

    Old guy

  4. Re: apps for monitoring Dial up PPP quality

    "Ray Van Dolson" writes:
    > An excellent question. Does pppd support RFC1333
    > (http://www.faqs.org/rfcs/rfc1333.html)? It doesn't appear so...


    No, pppd doesn't support RFC 1333 (which is obsolete) or RFC 1989 --
    Link Quality Monitoring.

    I think there are several reasons for this.

    - Nobody who cares about it has volunteered to do the work to
    implement and thoroughly test the results.

    - A fairly large number of PPP links are done over physical layers
    that either have "zero errors" (such as a V.42 error controlled
    modem connection) or have their own physical error-reporting
    mechanisms (FDL on T1, BIP-8 on SONET). (Note that internally
    modems can report error information, but that PPP simply has no
    knowledge of this and LQM doesn't address it.)

    - For the remainder of links (mostly tunnels of various sorts,
    including PPPoE), it's somewhat unclear what the benefit would be,
    or what the best way to report the problems would be, or perhaps
    how best to *use* the reports.

    > we're
    > trying to figure out an (efficient) way to monitor the quality of ppp
    > conenctions on our server as well.


    It would be helpful to know what sort of PPP connections these are and
    what you expect to be able to do with the information gathered.

    > Any suggestions out there?
    > (Too bad this group and linux-ppp mailing list are so inactive).


    Folks tend not to answer when they don't have answers. Consider it
    being polite. ;-}

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: apps for monitoring Dial up PPP quality

    Well, our ppp tunnels are being established over wireless links and I'm
    trying to figure out a good way to track the quality of customer's
    tunnels. Essentially I just want to track the quality of the
    underlying wireless layer, not so much the tunnel--but figured that LQM
    (if it was implemented) might give an accurate picture of this without
    having to write some additional code.

    If pppd tracked when it needed to retransmit some data, et al, the
    thinking was this could be noted somewhere and compared against other
    customers and trigger some sort of alert when performance became too
    poor.

    Other options I've considered are trying to finangle some way into the
    network drivers and figure out how to track when a TCP retransmit
    occurs which could potentially mean the physical links is having
    issues...

    And a really brute force approach way would be to write a daemon that
    just sends a few pings to the end of the tunnel (or the private IP they
    actually connect with) and record the traffic loss. With hundreds of
    users connected to each device however this would obviously need to be
    done in a distributed way, but maybe is the most practical solution at
    this point.

    LQM in pppd seemed to be a possible solution but since it's not
    implemented and probably won't be (I certainly do not have the
    expertise to do it) we'll continue digging for another solution.
    Thanks for the response.


  6. Re: apps for monitoring Dial up PPP quality

    "Ray Van Dolson" writes:
    > Well, our ppp tunnels are being established over wireless links and I'm
    > trying to figure out a good way to track the quality of customer's
    > tunnels. Essentially I just want to track the quality of the
    > underlying wireless layer, not so much the tunnel--but figured that LQM
    > (if it was implemented) might give an accurate picture of this without
    > having to write some additional code.


    I'd suggest that getting statistics out of the wireless layer itself
    would be the best solution. The interface that most wireless systems
    offer to the link layer is actually a fairly high-level interface.
    Within the wireless system itself, packets are usually chopped into
    small segments that get transmitted with some kind of error correcting
    code and then reassembled at the other end. Those codes and
    marshalling processes generate a great deal of usable information
    about the link -- well before there's anything visibly wrong at the
    PPP level.

    Below that, the radio and modulator usually has a number of useful
    statistics about signal strength, symbol error rates, and such. This
    is also very useful.

    If the devices you're using don't expose these statistics, I'd suggest
    talking to the manufacturer. They should expose them.

    > If pppd tracked when it needed to retransmit some data, et al, the
    > thinking was this could be noted somewhere and compared against other
    > customers and trigger some sort of alert when performance became too
    > poor.


    pppd doesn't retransmit user data. Ever. I would imagine that the
    sorts of counters you're looking for are available in 'netstat -s'.

    > Other options I've considered are trying to finangle some way into the
    > network drivers and figure out how to track when a TCP retransmit
    > occurs which could potentially mean the physical links is having
    > issues...


    It would indeed be a bit tough to do that. Why not just look at TCP's
    counters?

    > And a really brute force approach way would be to write a daemon that
    > just sends a few pings to the end of the tunnel (or the private IP they
    > actually connect with) and record the traffic loss. With hundreds of
    > users connected to each device however this would obviously need to be
    > done in a distributed way, but maybe is the most practical solution at
    > this point.


    You could do effectively the same thing with LCP Echo-Request in the
    current pppd, and it'd have the added benefit of not involving any
    network layer issues.

    > LQM in pppd seemed to be a possible solution but since it's not
    > implemented and probably won't be (I certainly do not have the
    > expertise to do it) we'll continue digging for another solution.


    Note that even if you had it in pppd, you'd need it in *both* ends of
    the connection to make any difference. If those remote clients are
    Windoze machines, you'd still be out of luck.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

+ Reply to Thread