resetting pppd-connection data - PPP

This is a discussion on resetting pppd-connection data - PPP ; Hi NG, i' ve a problem with the connection data from pppd. I want to get some value about time and transfered data. My log looks like this: Sep 13 09:26:36 firewall pppd[460]: Sent 380510 bytes, received 1877684 bytes. Sep ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: resetting pppd-connection data

  1. resetting pppd-connection data

    Hi NG,

    i' ve a problem with the connection data from pppd. I want to get
    some value about time and transfered data. My log looks like this:

    Sep 13 09:26:36 firewall pppd[460]: Sent 380510 bytes, received
    1877684 bytes.
    Sep 13 11:17:31 firewall pppd[460]: Sent 389611 bytes, received
    1906828 bytes.
    Sep 13 15:17:28 firewall pppd[460]: Sent 402866 bytes, received
    1998618 bytes.
    Sep 13 16:08:00 firewall pppd[460]: Sent 411407 bytes, received
    2028206 bytes.
    Sep 13 19:17:16 firewall pppd[460]: Sent 424289 bytes, received
    2119789 bytes.
    Sep 13 21:50:35 firewall pppd[460]: Sent 802021 bytes, received
    3270842 bytes.
    Sep 14 13:39:28 firewall pppd[460]: Sent 550756 bytes, received
    9177986 bytes.
    Sep 15 09:32:19 firewall pppd[460]: Sent 318719 bytes, received
    4245222 bytes.
    Sep 15 09:38:23 firewall pppd[460]: Sent 352899 bytes, received
    4539876 bytes.
    Sep 15 11:54:16 firewall pppd[1386]: Sent 20246 bytes, received
    205221 bytes.
    Sep 15 11:58:15 firewall pppd[1386]: Sent 31521 bytes, received
    227419 bytes.

    I think that the counter only resets after reboot or restart the
    daemon. So if i add the values, the result must be wrong.

    Can i configure something with pppd, to reset the counter when
    connection is finished/down?

    Thanks

    Edgar


  2. Re: resetting pppd-connection data

    Edgar Giese wrote:

    > i' ve a problem with the connection data from pppd. I want to get
    > some value about time and transfered data. My log looks like this:


    The totals are cumulative between instances of pppd and, as far as
    I know, there is no pppd option to get around it for PPP connections
    made in pppd demand mode. (It must be demand since otherwise there
    would be no problem, even pppd got the same pid for 2 consecutive days
    and part of the third - you probably terminated pppd manually on the
    third day and then restarted it.)

    [some of log elided]

    > Sep 13 21:50:35 firewall pppd[460]: Sent 802021 bytes, received
    > 3270842 bytes.
    > Sep 14 13:39:28 firewall pppd[460]: Sent 550756 bytes, received
    > 9177986 bytes.
    > Sep 15 09:32:19 firewall pppd[460]: Sent 318719 bytes, received
    > 4245222 bytes.
    > Sep 15 09:38:23 firewall pppd[460]: Sent 352899 bytes, received
    > 4539876 bytes.
    > Sep 15 11:54:16 firewall pppd[1386]: Sent 20246 bytes, received
    > 205221 bytes.
    > Sep 15 11:58:15 firewall pppd[1386]: Sent 31521 bytes, received
    > 227419 bytes.


    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Editing with vi is a lot better than using a huge swiss army knife.
    Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
    ~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */

  3. Re: resetting pppd-connection data

    Clifford Kite writes:
    > Edgar Giese wrote:
    >
    > > i' ve a problem with the connection data from pppd. I want to get
    > > some value about time and transfered data. My log looks like this:

    >
    > The totals are cumulative between instances of pppd and, as far as
    > I know, there is no pppd option to get around it for PPP connections
    > made in pppd demand mode.


    Indeed. They come from the kernel itself.

    > (It must be demand since otherwise there
    > would be no problem, even pppd got the same pid for 2 consecutive days
    > and part of the third - you probably terminated pppd manually on the
    > third day and then restarted it.)


    If that's the problem, then it's something that could (and should) be
    fixed in pppd. pppd should take a tare of these statistics, since it
    knows exactly what the kernel is doing.

    --
    James Carlson, Solaris Networking
    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

  4. Re: resetting pppd-connection data

    James Carlson wrote:
    > Clifford Kite writes:
    >> Edgar Giese wrote:
    >>
    >> > i' ve a problem with the connection data from pppd. I want to get
    >> > some value about time and transfered data. My log looks like this:

    >>
    >> The totals are cumulative between instances of pppd and, as far as
    >> I know, there is no pppd option to get around it for PPP connections
    >> made in pppd demand mode.


    > Indeed. They come from the kernel itself.


    >> (It must be demand since otherwise there
    >> would be no problem, even pppd got the same pid for 2 consecutive days
    >> and part of the third - you probably terminated pppd manually on the
    >> third day and then restarted it.)


    Why in the world did I put my thoughts down in such a broken fashion?
    What I meant was that it seemed clear that demand was used since pppd
    had the same pid for the first two days, and the count rose throughout
    each of those days but dropped when the day changed, behavior which
    implied you shutdown one day and rebooted the next.

    On the 3rd day pppd again began with the same pid but you must have
    terminated pppd manually and restarted it since during that day the
    pid changed to a larger number and the count dropped when it did.

    > If that's the problem, then it's something that could (and should) be
    > fixed in pppd. pppd should take a tare of these statistics, since it
    > knows exactly what the kernel is doing.


    Hmmm.. This is the first time I've seen or heard the word "tare."
    It must be one of those words that is applied in contexts not easily
    deduced from the (Merriam-Webster on-line) dictionary definitions.
    However, hopefully, it seems fairly obvious what it means here.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* "PPPoE has many advantages for DSL service providers, and
    practically none for DSL consumers."
    - David F. Skoll */

  5. Re: resetting pppd-connection data



    Clifford Kite schrieb:
    > Edgar Giese wrote:
    >
    >
    >>i' ve a problem with the connection data from pppd. I want to get
    >>some value about time and transfered data. My log looks like this:

    >
    >
    > The totals are cumulative between instances of pppd and, as far as
    > I know, there is no pppd option to get around it for PPP connections
    > made in pppd demand mode. (It must be demand since otherwise there
    > would be no problem, even pppd got the same pid for 2 consecutive days
    > and part of the third - you probably terminated pppd manually on the
    > third day and then restarted it.)


    Right! I should told you. :-(

    But, why the connection-time is reseted and not the transferred
    data. I found some perlscript that build some statistiks but it
    failed because of this "bug".

    I want dial on demand, because its easier for the users and
    windows-clients to dial into internet. It' s the firewall and i
    don't want any accounts for the users on it.

    Edgar


  6. Re: resetting pppd-connection data



    James Carlson schrieb:
    > Clifford Kite writes:
    >
    >>Edgar Giese wrote:
    >>
    >>
    >>>i' ve a problem with the connection data from pppd. I want to get
    >>>some value about time and transfered data. My log looks like this:

    >>
    >>The totals are cumulative between instances of pppd and, as far as
    >>I know, there is no pppd option to get around it for PPP connections
    >>made in pppd demand mode.

    >
    >
    > Indeed. They come from the kernel itself.
    >
    >
    >> (It must be demand since otherwise there
    >>would be no problem, even pppd got the same pid for 2 consecutive days
    >>and part of the third - you probably terminated pppd manually on the
    >>third day and then restarted it.)

    >
    >
    > If that's the problem, then it's something that could (and should) be
    > fixed in pppd. pppd should take a tare of these statistics, since it
    > knows exactly what the kernel is doing.
    >


    I think so too. Could it be that nobody use it in this way? So
    nobody care about it?

    Edgar


  7. Re: resetting pppd-connection data

    Edgar Giese wrote:

    > But, why the connection-time is reseted and not the transferred
    > data. I found some perlscript that build some statistiks but it
    > failed because of this "bug".


    I think the pppd that does the PPP negotiation forks a second pppd to do
    the data transfer, but when that one terminates then the original gets the
    numbers of data bytes transfered and adds those to it's current counts.

    That's just a guess, I'm not really a C programmer and delving into the
    pppd code to find out was actually does happen would be painful for me.
    Perhaps James Carlson will cast some light on this for both of us.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  8. Re: resetting pppd-connection data

    Clifford Kite writes:
    > Edgar Giese wrote:
    >
    > > But, why the connection-time is reseted and not the transferred
    > > data. I found some perlscript that build some statistiks but it
    > > failed because of this "bug".

    >
    > I think the pppd that does the PPP negotiation forks a second pppd to do
    > the data transfer, but when that one terminates then the original gets the
    > numbers of data bytes transfered and adds those to it's current counts.


    Huh?

    No; demand mode doesn't involve forking in that way. The counts are
    done in the kernel -- when you establish a "ppp0" interface in the
    kernel for use by IP, that interface keeps track of packets and bytes
    sent and received. For demand mode, what happens is that the IP
    interface remains in place all of the time, but the low-level serial
    channel is connected and disconnected as needed.

    (More precisely: the kernel's "ppp0" interface tells pppd that packets
    are being sent but there's no output serial port. pppd opens a serial
    port, runs "connect" [chat] as needed, then tells the kernel that the
    existing IP interface should use this serial channel. On tear-down,
    just the serial port is closed and the "ppp0" interface remains.)

    The user-level pppd doesn't handle any part of the data path, and it
    doesn't fork to handle data transfer. (It does fork at times, but
    only to do an immediate 'exec' of one of those external scripts, such
    as /etc/ppp/ip-up. And it can get itself wedged into the data path at
    times, but that's only for the 'charshunt' hackery and not for normal
    use. And, yes, I realize that some PPPoE implementations rely on that
    mechanism, which implies multiple trips in and out of the kernel for
    every packet.)

    Either pppd needs to keep track of the last number reported, or the
    kernel should reset the counts when the serial port goes away. Either
    would work fine.

    > Perhaps James Carlson will cast some light on this for both of us.


    ;-}

    --
    James Carlson, Solaris Networking
    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

  9. Re: resetting pppd-connection data

    Clifford Kite writes:
    > Hmmm.. This is the first time I've seen or heard the word "tare."
    > It must be one of those words that is applied in contexts not easily
    > deduced from the (Merriam-Webster on-line) dictionary definitions.
    > However, hopefully, it seems fairly obvious what it means here.


    I probably should have said "delta," but I have scales on the brain.

    A "tare" is a measurement you make where you remove some bias from the
    result. For example: place an empty bowl on a scale and adjust the
    scale to read "zero." Fill the bowl, and the reading on the scale
    will be the weight of the contents alone. The act of setting the
    scale to read "zero" when there's something on it is called "taking a
    tare."

    --
    James Carlson, Solaris Networking
    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