Is it possible to monitor network stats on a per-port granularity?

[amity88]

I have a freebsd box (rpi4) with a single network interface and a couple of services listening on different ports. While I can get the network stats for the whole interface, is there a way to get it per listening port?

Any guidance on this would help! So far, with my half knowledge, I only have two ideas:

1. Add a second NIC (usb-ethernet ) and have the two services listen on different NICs. (might work but seems like overkill, there's gotta be a better way)
2. Make some kind of virtual NIC to implement 1

 

[Erichans]

Try sockstat(1), for example: sockstat -P tcp -p 443 or sockstat -l | grep ':80'

15 Useful ‘Sockstat Command Examples’ to Find Open Ports in FreeBSD may prove useful too.

 

[sko]

If you just want to know what is listening where; use sockstat(1) as Erichans already suggested.
If you only want some live stats, you can use something like e.g. net-mgmt/iftop or just plain tcpdump(1) with appropriate filters (e.g. port) and pipe that to wireshark. (depending on how busy the host/service is, this can be like drinking from a firehose!)
For historic data of all sorts, you can enable netflow and use net-mgmt/nfsen, which is probably overkill in a home network...

1. Add a second NIC (usb-ethernet ) and have the two services listen on different NICs. (might work but seems like overkill, there's gotta be a better way)

USB NICs are crap. Don't expect any decent and stable performance. Add a proper NIC or (if bandwidth isn't a concern) just use VLANs on the same interface.

 

[amity88]

Thanks!
socket stat isn't as useful in my case because I wanted to get the bytes sent/ received stat rather than just checking if the port is actually open. I'll explore tcpdump, nfsen and see how it goes.

sko, how'd I enable netflow?

 

[sko]

sko, how'd I enable netflow?

#kldload netgraph

There's an (old but still) good overview on how netflow/netgraph is working in this article in the howto section: https://forums.freebsd.org/threads/...c-with-netflow-nfdump-nfsen-on-freebsd.49724/
True, this is rather old, but most things are still relevant/true - with the exception that it is no longer necessary to rebuild a custom kernel.

I'm currently only using netflow/nfsen on OpenBSD hosts; but AFAIR there are no special steps involved on FreeBSD.
The only (major) difference that comes to mind is, that OpenBSD uses a pflow pseudo-interface and the statement 'pflow' in pf.conf for data export, whereas FreeBSD IIRC just dumps everything from the configured interface(s). Both variants work, although I find the OpenBSD way more elegant, because only states created by PF rules with the statement 'pflow' are automagically exported, so instead of dumping everyting you can have a very fine-grained selection of flows.
If you want to get a nicely (and entertainingly) written overview of the OpenBSD way, there is this appropriately named blog post by Peter N.M. Hansteen: https://bsdly.blogspot.com/2014/02/yes-you-too-can-be-evil-network.html

Please read the articles and especially the man pages mentioned in the howto article. Many steps described aren't necessary any more. Also there are some implications when running pflow (e.g. memory usage) you should be aware of. Especially on very weak routers you can drastically hurt throughput performance if you try to gather too much information.

socket stat isn't as useful in my case because I wanted to get the bytes sent/ received stat rather than just checking if the port is actually open. I'll explore tcpdump, nfsen and see how it goes.

if you just want a live view, sysutils/pftop is exactly what you are looking for.

 

[im]

You can use 'ipfw count' firewall rule for accounting specified type of traffic.
If you want to graph that values - you can use mrtg() with a simple custom script.

Another Idea is to use VLANs, but it will require a network switch with VLAN 802.1q support. Cheapest one may cost ~$20.
With VLAN you will have a possibility to create on RPI a lot of VLAN tagged virtual interfaces inside the single physical ethernet link.
After that you can split your services 'per VLAN' and use usual per-port accounting, even via SNMP on RPI or SNMP on Switch.