I found ntopng.inc inside /usr/local/pkg and attempted to append --enable-flow-activity to the end of the of line 167 but before the &. Like so...

/usr/local/bin/ntopng -d /var/db/ntopng -G /var/run/ntopng.pid -s -e {$http_args} {$disable_alerts} {$dump_ flows} {$ifaces} {$dns_mode} {$aggregations} {$local_networks} --enable-flow-activity &

Stopped and restarted ntopng and still no luck.

@RedBeardCowboy Thanks for taking the time to answer your own question. This is exactly what I was looking for today!

That is my wish also. Any way to achieve that?

@Derelict, ah. okay then.
Thank you.

@frankvh said in Determining what my new LG Smart TV is up to:

Thanks for the replies. I've been doing packet captures & examining them in wireshark. It's rather fascinating. First of all, I'm wrong about the TV - I've managed to have a network problem with the TV unplugged from the network. Can't blame the TV! But I've seen other things. For example, my Yamaha audio-visual receiver gets on the network every few seconds and asks, "Who has 192.168.1.255?" No idea why it's asking that, over and over again - predictably it doesn't get any reply. That's a bit strange. It's all good fun.

x.x.x.255 is a broadcast, meaning it is telling everyone that it is there, so nothing very strange.

I think I figured out WHY it's happening... but I'm not a developer, so not really in a position to fix it.

The issue is likely related to the change between regular time and summer time. The weird thing is that everything is correct during summer time, and off during regular time.

Here in the US, summer time ends in November (an extra hour in the month, which causes two November entries to appear, creating a one month offset in how the data is displayed) and starts in March (one less hour in the month, which causes March to not appear, removing the offset).

I'm not sure if the package is using time based on GMT or local time... or maybe the pieces doing the logging are using one time and the web interface is using another, causing the issue... if someone could look at it, that would be great. This was a package originally created by a member of the pfSense team.

Edit to add: Created a bug report, #9537: https://redmine.pfsense.org/issues/9537

No, IT display on this is happening using ntopng CE v3.6 here.

Sorry for my bad English

Yes, Telegraf can do this. It can use the same data as gathered by dpinger and displayed in the graph in your first post.

First you need a script, that will gather this data from dpinger and output it in a format that Telegraf will be able to digest. I made a python script some time ago. You can find it here: https://gist.github.com/fastjack/a0feb792a9655da7aa3e2a7a1d9f812f. Copy that script to /usr/local/bin and make it executable.

Second you need to tell Telegraf to call that script. For this you'll need to add this to your telegraf.conf:

[[inputs.exec]] commands = ["/usr/local/bin/gateways.py"] timeout = "5s" data_format = "influx"

Finally restart Telegraf so it will pick up the changed config.

Please note that any changes you make in the pfSense web UI in Services > Telegraf will recreate the telegraf.conf from scratch and clobber your modifications.

Complete rebuild from scratch fixed it for me.

@Grimson said in ntopng more than 3 months out of date -- GeoIP / AS features broken, simple update all that's needed:

You paid for hardware that is tested and guaranteed to work with current and future pfSense versions, during it's lifetime. The software itself is free.

If we're going to be pedantic, hardware support for the device itself also would not be complimentary for any period after purchase.

Any pull request against the code would be simply doing that. But I can't make that happen -- only the pfSense package maintainers can.

Everyone can make pull requests: https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html

But not everyone can merge that pull request and build a new package. I don't see how submitting a PR for something as simple as pulling in the latest version of a third party tool would be any different than filing the ticket in Redmine (which is what Netgate support instructed me was the proper thing to do).

Anyway -- I find the debate with you pointless. My only hopes were to make others aware of what was going on with ntopng, and perhaps catch the eye of a package maintainer -- since Redmine doesn't seem to do the trick and Netgate support says they can't help.

When I put Bypass Proxy for these Source IPs. I can make it work on the computer. I do not know how to solve it.