Aw: Re: Re: Re: [PATCH] vnstat: Update to 1.18

[Bernhard Bitsch <Bernhard.Bitsch@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 5264 bytes --]

What do you mean with static configuration?
As far as I've seen in the sources, the functionality of vnstatd and 'vnstat -u' should be identical.

You're right about the bug in the device driver ( which causes an information leak ), but vnstatd can help as work-around.

-Bernhard

> Gesendet: Mittwoch, 28. März 2018 um 20:04 Uhr
> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
> Cc: "IPFire Development" <development(a)lists.ipfire.org>
> Betreff: Re: Aw: Re:  Re: [PATCH] vnstat: Update to 1.18
>
> The daemon has the disadvantage of static configuration of all interfaces.
> 
> This isn’t an information leak. It is a bug in the device driver of that NIC and therefore I don’t think that the solution is to play around with vnstat. The solution is to fix that driver.
> 
> -Michael
> 
> > On 28 Mar 2018, at 12:55, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wrote:
> > 
> > 
> > 
> >> Gesendet: Freitag, 23. März 2018 um 16:54 Uhr
> >> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
> >> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>, "IPFire Development" <development(a)lists.ipfire.org>
> >> Betreff: Re: Aw: Re: [PATCH] vnstat: Update to 1.18
> >> 
> >> On Fri, 2018-03-23 at 13:39 +0100, Bernhard Bitsch wrote:
> >>>> Gesendet: Mittwoch, 21. März 2018 um 20:30 Uhr
> >>>> Von: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
> >>>> An: "Matthias Fischer" <matthias.fischer(a)ipfire.org>
> >>>> Cc: "IPFire: Development-List" <development(a)lists.ipfire.org>
> >>>> Betreff: Aw: Re: [PATCH] vnstat: Update to 1.18
> >>>> 
> >>>> 
> >>>>> Gesendet: Mittwoch, 21. März 2018 um 18:38 Uhr
> >>>>> Von: "Matthias Fischer" <matthias.fischer(a)ipfire.org> 
> >>>>> An: "Michael Tremer" <michael.tremer(a)ipfire.org>, "IPFire: Development-
> >>>>> List" <development(a)lists.ipfire.org>
> >>>>> Betreff: Re: [PATCH] vnstat: Update to 1.18
> >>>>> 
> >>>>>> 
> >>>>>> P.S. I did not appreciate that comment of that forum user about this
> >>>>>> bug. Bugs
> >>>>>> happen. If he doesn't like it, he can take lots of €€€€ into his hand
> >>>>>> and pay
> >>>>>> other people to get their bugs.
> >>>>> 
> >>>>> Me too. But I tried to be patient, took a deep breath and tried to keep
> >>>>> calm and ~professional. Wasn't easy. Besides, I don't think this is
> >>>>> really a "bug". 'vnstat' can handle his speed and download rates with no
> >>>>> problems. It just happened that they were a bit too much for the
> >>>>> standard config - in *his* case.
> >>>>> 
> >>>>> Best,
> >>>>> Matthias
> >>>>> 
> >>>>> 
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> just my opinion ( I've investigated now a bit about this "problem" ;) )
> >>>> The "solution" isn't really that. The changed parameter is only used by
> >>>> vnstatd, which isn't used in IPFire. I can't imagine what did the remedy.
> >>>> We don't know exactly his configuration. Therefore I gave him some hints to
> >>>> help clarifying the case.
> >>>> If he doesn't answer, just forget his unqualified comment.
> >>>> 
> >>>> Best,
> >>>> Bernhard
> >>>> 
> >>> 
> >>> News about the vnstat problem.
> >>> Intensive PMs with Zonediver showed that the effect is caused by 32 bit byte
> >>> counters of the NIC. ( vnstat reads /proc/net/dev )
> >>> He changed the fcrontab period for makegraphs to 3 minutes now. Amount of
> >>> bytes received in this period is less than 2^32.
> >>> 
> >>> Remain two questions: 
> >>> - Is this a normal behaviour for the combination of i210-T1 NIC and associated
> >>> driver or is this specific to his system?
> >> 
> >> I cannot speak for that NIC because I do not use that anywhere. Surprised to
> >> hear this the first time since the i210 is also on the APU boards and it
> >> actually is a stripped down version of a bigger Intel NIC.
> >> 
> >>> - Can we use the vnstatd daemon? This would allow to increase the vnstat
> >>> update frequency independent from makegraphs.
> >> 
> >> I suppose we could. Arne has built this into the distribution and could probably
> >> comment more. If I remember correctly, the daemon wasn't available when we
> >> adopted vnstat.
> >> 
> > That's right.
> >> But even collecting once a minute wouldn't be enough because with max.
> >> theoretical throughput of a Gigabit NIC, 2^32 bytes are transferred in 32
> >> seconds. And if this is only a problem with that specific NIC, I actually
> >> wouldn't want to collect every 30 second on all systems. Wastes a lot of
> >> resources and costs a lot of write cycles on flash.
> >> 
> >>> I've found a thumb rule for the maximal update period for a given bandwidth.
> >>> I've documented this in the forum thread.
> >> 
> >>> 
> >>> Best,
> >>> Bernhard
> >>> 
> >> 
> >> -Michael
> >> 
> > 
> > The default value of vnstatd are 30 seconds for UpdateInterval (short enough for 2^32 bytes on 1 GBit/s ), writes to disk is ruled by parameter SaveInterval ( default 5 minutes, which is our period from cron ).
> > Thus vnstatd should give a better resolution ( for some systems without information leaks! ) with similiar load as the cron based solution implemented at the moment.
> > 
> > -Bernhard
> 
>