lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] PPPoS: nb->tot_len in pppos_output_last() is always 0


From: Sylvain Rochet
Subject: Re: [lwip-devel] PPPoS: nb->tot_len in pppos_output_last() is always 0
Date: Thu, 29 Jun 2017 11:49:28 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

Hi Axel,

On Thu, Jun 22, 2017 at 08:17:32PM +0800, Axel Lin wrote:
> 2017-06-22 1:47 GMT+08:00 Sylvain Rochet <address@hidden>:
> > On Mon, Jun 19, 2017 at 06:05:06PM +0800, Axel Lin wrote:
> >> In pppos_output_last(),
> >> The nb->tot_len is always 0:
> >> MIB2_STATS_NETIF_ADD(ppp->netif, ifoutoctets, nb->tot_len);
> >>
> >> pppos_output_append() increases nb->len but does not update nb->tot_len.
> >> Is this a bug?
> >
> > It obviously is. I wonder if I broke SNMP counters or if it never worked
> > at all but I'm too lazy to find out now :-)
> >
> > PPPoS uses pbuf in its own way and nb->tot_len wasn't necessary. Since
> > we are recycling the same pbuf we could use nb->tot_len to keep track of
> > the total amount of tx bytes.
> >
> > By the way, since we are counting bytes past HDLC decoding in
> > ppp_input() for ifinoctets I suggest we do the same for the sake of
> > consistency for ifoutoctets by only counting actual payload (bytes -fcs
> > -escaping -flag).
> 
> Maybe the most simply way to do is assigning nb->tot_len to actual
> payload length after pbuf_alloc.
> I sent below patch for review:
> https://savannah.nongnu.org/patch/index.php?9385

I agree, this is the most appealing solution. Applied, thanks ! :)

Sylvain

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]