- Main thread to capture the processes (listing /proc/*)
- Another thread using libcap intercepts all the TCP/UDP ipv4/v6
packets and takes care of stamping information
- Another thread takes care of resolving IPs (v4/v6) to network
names
To see all options just run it with --help option; following a simple
screenshot.
As you can see, the U.I. is organized as follows:
- in the 1st row you have the version of the program, the interval
since last redrawn window, number of packets not attributed, number of
received packets not matched (assigned to pid -1), number of sent packets not
matched (assigned to pid -1)
and then the totals
- in the 3rd row you have the header
- in following rows you have the processes and the bandwidth
they're actually using; in the subrow sections you have the hostnames
which are communicating and how much bandwidth is being used (between
square brackets you have the TCP/UDP percentage split of such bandwidth
- i.e. how much data is sent/received via TCP and how much via UDP)
Hopefully this is quite simple to understand!
Features
- Multi threaded
- Relies on libcap to generate network statistics, ncurses for display
- Written in C++11
- Low memory cpu/usage
- Easily exendible source code
Download it (v 0.3)!
Sources
Ubuntu 12.04 amd64
nettop
To compile the sources install
libcap-dev,
libncurses5-dev.
nettop is released under the Gpl V3; if you have any issue with this
software, please do report them to me.
(old sources/packages)
Known issues
F.A.Q.
- Why do I get the error
"Exception: (null): You don't have permission to capture on that device
(socket: Operation not permitted)" when I try to start nettop up?
nettop relies on libcap and captures all the packets incoming or outgoing on all the network devices. As you can imagine you have to be root (i.e. "sudo nettop") to exectue it successfully.
- I don't trust running this as root. What can I do?
This program is released under the open source licence GPLv3. Review the sources, compile and then run it! :-)
- Why do I have many incoming/outgoing packets not matched?
The reasons could be that when the "process screenshot" (i.e. every 3
seconds) was taken, the process which would have received not matched
packets was not "in the picture" :-), hence could not perform the
mapping. Another reason could be that the processes sending/receiving
data open and close sockets dynamically so fast that, again, those
don't result attributed in the process screenshot.
Or, as it should be in majority of cases, it really the kernel doing some network activity (i.e. when you invoke the getnameinfo function).
Contacts
In case you want to tell me anything feel free to contct
me at ema at fastwebnet dot it .