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.

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.

ntop is NOT working on latest 2.4.4-RELEASE-p2
and running ntoppng 0.8.13_3

ntop started fine but cant access on https://<router-ip>:3000