New Traffic Totals package available for testing

jdillard

Yea, I think that was an artifact of using the Status > Monitoring as a starting point. I'll try and get some of these fixes in tomorrow.

MikeV7896

Just wondering about why PHP is listed as a dependency for the package. Isn't PHP part of the whole pfSense ecosystem anyway? Or is that for future planning if it goes away? Does this potentially cause problems if PHP is upgraded by pfSense core, but the package isn't updated to reflect the new version of PHP, when someone goes to install the package?

athurdent

@jdillard:

It uses a cron job not vnstatd, I thought it would be more reliable.

Why is the vnstatd daemon unreliable on FreeBSD? Had it running for years on a Linux box with no problems at all.

MikeV7896

@athurdent:

@jdillard:

It uses a cron job not vnstatd, I thought it would be more reliable.

Why is the vnstatd daemon unreliable on FreeBSD? Had it running for years on a Linux box with no problems at all.

He didn't say that it was unreliable on FreeBSD… just that he thought it would be more reliable as a cron job. Using the cron job, it's only running every 5 minutes rather than a constantly running process that could be stopped at any time leaving holes in the data.

I see pluses and minuses to both ways... I personally have no preference. I just want it to work and accurately track my usage. It doesn't need to be minute-by-minute... updating every 5 minutes is fine by me. Most of what I care about (and probably most people) is monthly usage more than anything.

robi

Hmmm…

Is this topic about the new graphing system on 2.3 which replaced RRD? Or is it an addition to that? Or is it just a similar graphing to what's already built-in?
Why as a separate package?

athurdent

@virgiliomi:

He didn't say that it was unreliable on FreeBSD… just that he thought it would be more reliable as a cron job. Using the cron job, it's only running every 5 minutes rather than a constantly running process that could be stopped at any time leaving holes in the data.

Cron jobs are run by a daemon that could also be stopped at any time ;) So the question remains, why not use the vnstat daemon? Don't get me wrong, I just want to understand it, don't want to offend anyone :)

jdillard

@virgiliomi:

Just wondering about why PHP is listed as a dependency for the package. Isn't PHP part of the whole pfSense ecosystem anyway? Or is that for future planning if it goes away? Does this potentially cause problems if PHP is upgraded by pfSense core, but the package isn't updated to reflect the new version of PHP, when someone goes to install the package?

I had a line in the Makefile that didn't need to be there. I'll be taking it out and it should remove the PHP dependancy.

jdillard

@athurdent:

@jdillard:

It uses a cron job not vnstatd, I thought it would be more reliable.

Why is the vnstatd daemon unreliable on FreeBSD? Had it running for years on a Linux box with no problems at all.

It's not unreliable on FreeBSD, just harder to tie into all the necessary GUI bits last time I looked. Maybe I was looking at it wrong.

jdillard

@robi:

Hmmm…

Is this topic about the new graphing system on 2.3 which replaced RRD? Or is it an addition to that? Or is it just a similar graphing to what's already built-in?
Why as a separate package?

TL;DR: RRDTool graphing dependancies got too large so we cut them out. Part of that was the function that provided the period totals. Period totals using RRD data aren't that accurate to begin with since they get averaged out over time. vnStat handles the collection of historical traffic totals better and is more accurate, hence the addition. Also, not everyone cares about traffic totals so no need to bundle it in core and having it as a package allows it to be revved separate from core.

robi

@jdillard:

Period totals using RRD data aren't that accurate to begin with since they get averaged out over time. vnStat handles the collection of historical traffic totals better and is more accurate, hence the addition. Also, not everyone cares about traffic totals so no need to bundle it in core and having it as a package allows it to be revved separate from core.

In that case, replacing Period totals with vnStat in the future would make many people happy.

grandrivers

under interfaces 2 of my 4 interfaces dont show but if i click the blank area datas there

timotl

I don't see anything in the interface selection.
I can click through the blank space and it does follow
I'm using VLANS on a single LAGG of two physical interfaces.
The totals do show up for my physical and ovpn interfaces, but none of those are assigned labels.

jdillard

Ok I'll have to look into the code that generates the interface names, I have a feeling it is making the option element, but not populating it with content. Grandrivers, do you happen to know what makes those 2 interfaces that aren't showing up different from the others (based on type, etc)?

grandrivers

one is a pppoe WAN the other is a non assigned opt interface but had not noticed the neither of my HE ipv6 tunnels show up at all might be nice to have those as well

MikeV7896

I wonder if there's limits to what vnstat can track usage for… because interfaces that seem to be showing up are physical interfaces, while non-physical ones - VLANs, tunnels, etc. - don't seem to be showing up.

Also, the interfaces selected show their pfSense names (WAN, LAN, GUEST), but in the graph and table they're identified as the actual physical interface (igb0, igb1, igb2). I also have a blank entry, which is my unassigned igb3 interface. This is part of what leads me to the above suggestion that vnstat may only be able to track physical interfaces.

jdillard

Just bumped the version to 0.2. It should include misc fixes as well as fixes for:

#6) The correct units and axis label. Although, I have to figure out how to make a custom axis format as it uses binary prefixes and not the SI prefixes.

#7) PHP shouldn't be listed as a dependency anymore. This may take some more kicking to get to work.

#8) Don't allow TOP 10 when multiple interfaces are selected.

jdillard

@virgiliomi:

I wonder if there's limits to what vnstat can track usage for… because interfaces that seem to be showing up are physical interfaces, while non-physical ones - VLANs, tunnels, etc. - don't seem to be showing up.

Also, the interfaces selected show their pfSense names (WAN, LAN, GUEST), but in the graph and table they're identified as the actual physical interface (igb0, igb1, igb2). I also have a blank entry, which is my unassigned igb3 interface. This is part of what leads me to the above suggestion that vnstat may only be able to track physical interfaces.

It could also have to do with the get_interface_list() function I am using. I might need to use a different function or a combination of them, I am in the process of testing get_configured_interface_with_descr().

Edit: Bad news bears, this is what the vnStat man page says:

Virtual and aliased interfaces cannot be monitored because the kernel doesn't provide traffic information for that type of interfaces. Such interfaces are usually named eth0:0, eth0:1, eth0:2 etc. where eth0 is the actual interface being aliased.

jdillard

For those that have blank interface issues can you view the page source (or inspect the element if you know how) and grab the HTML for the select element with id="interfaces".

It should look something like:

 <select class="form-control" id="interfaces" name="interfaces" multiple=""><option value="em0" selected="">wan</option></select>

Dazog

As requested:

grandrivers