I have been experiencing a little problem these days. I am using a lot of my wifi without me knowing it. It is really annoying. Every time i have to pay 60$ because i don’t know how much i use. See now im asking myself, is there a program that i can download, or a program that i can do to see how much i use wifi ? Let’s say for example i use 5gb a day. But im not lonely in my house, i still have friends, familly that use it. In the end i will finish by refill again my wifi, and it’s becoming really expensive. So is there any ways someone can give me the name of an app so i can download it for free or a little program that counts every little bites that me and my familly and friends uses ? Please that will be really nice from you guys to help me with that issue.
2 Answers
You can install vnstat. I have used it and I see other people have already suggested that to you.
Installing it on your pc is pretty straight forward just use the usual sudo apt-get install vnstat
command on the terminal to install it.
Then you can follow this article: https://oastic.com/how-to-monitor-network-traffic-on-ubuntu-using-vnstat/
It is pretty easy. If you get stuck up, let me know.

- 358
-
Yes but my problem is that i want to see all the ip’s. I donlt want to monitor only my interface, i want every ip to be monitored separetly – Nov 25 '20 at 19:47
-
-
I mean how can i see hoe much my ip have used internet, how much the ip of my cell phone have used... In the link that i sent you there are 2 scripts writtend in C, but i don’t know how to set them up. Can you see a little bit please and then tell me what to do . – Nov 26 '20 at 05:54
Introduction: This answer is for an Ubuntu Server acting as a router, where all traffic between the WAN (Wide Area Network, A.K.A. internet) and the LAN (Local Area Network) passes though the server. It only differs in minor ways from a previous answer, that answer being for gathering some WAN side statistics, and this one being for gathering some client side statistics.
Caution: The methods used herein create very large files rather quickly and as a function of network load. CPU load can also be substantial at times. Proceed with all due diligence and plenty of disk space.
Method: Use tcpdump to capture all packet traffic, and use some post-processing to extract desired information.
sudo tcpdump -i enp2s0 -Z doug -w 'int-%F-%H-%M-%S.bin' -G 3600 -z ./packet_post_processor3
Where:
my internal LAN facing interface is enp2s0
;
The file names automatically include the date and time (requires an additional package, but I can not recall which);
I'm asking for file rotation once per hour;
I want the file ownership and such to be for doug
, (regular user me);
Each file be post processed by the packet_post_processor
script (3 is for this answer).
The post-processing script:
#!/bin/dash
#
# packet_post_processor3 Doug Smythies. 2020.11.26
# Look at client traffic with this version.
# See also:
# https://askubuntu.com/questions/1295243/over-wifi-consomation
#
# packet_post_processor2 Doug Smythies. 2017.09.08
# Edits as required for updated c prgram, and bad sort order.
# There may be little use in sort by packets count, but for now
# it remians.
#
# packet_post_processor2 Doug Smythies. 2017.09.01
# This script will be called from the always running tcpdump.
# It is called for every binary file rotation.
# The purpose is to make summary files of things that one
# may want to investigate in more detail later on.
#
# This version is for WinEunuuchs2Unix and
# https://askubuntu.com/questions/951783/how-to-find-out-who-is-taking-70-gb-of-data-from-me-each-month
#
#check that the call included the file name, and only the file name, to use.
if [ $# -ne 1 ]
then
echo "Usage - $0 file-name"
exit 1
fi
check that the file actually exists:
if [ ! -f $1 ]
then
echo "tcpdump binary file $1 does not exist, aborting..."
exit 1
fi
echo "data extraction 1: All the packets..."
Note: Using the -e option will ease subsequent bytes per unit time calculations
tcpdump -n -tttt -e -r $1 >all_e.txt
echo "data extraction 2: The client side outgoing normal packets..."
Note: We might want to check that something important doesn't get missed here.
Note: replace the fake IP address with your actual client side sub-net IP.
for smythies.com this is 192.168.111.0/24:
#ver 2
#grep ": XXX.XXX.XXX.XXX." all_e.txt | grep Flags >outgoing.txt
#ver 3
grep " > 192.168.111." all_e.txt | grep Flags >outgoing.txt
echo "data extraction 3: Make a histogram of the destination IP addresses by packets..."
Note: use field 13
cut -d" " -f13 outgoing.txt | sed 's/.[^.]*$//' | sort | uniq -c | sort -g >outhisto.txt
Phase 2: Maximum packet count might not mean maximum byte count, so figure out maximum byte count
echo "data extraction 4: Sort the outgoing file by destination IP address."
LC_ALL=C sort -k 13 <outgoing.txt >outgoing.srt
echo "data extraction 5: Now, calculate bytes per IP and bytes per IP/16 and make sorted historgrams"
Note: There might be some clever awk or whatever way to do this, but I have a c program.
./tcpdump_bytes outgoing.srt outb.txt out16.txt
sort --general-numeric-sort <outb.txt >$1.txt
sort --general-numeric-sort <out16.txt >$1.16.txt
Leave the intermediate files, just for now, while we debug.
However, and for the huge .bin file, only keep it if really needed. Uncomment to delete.
rm $1
packet_post_process. End.
The c program called from within the script:
/*****************************************************************************
*
* tcpdump_bytes.c 2017.09.08 Smythies
* By sorting the input file before running this program, it can do bytes
* per IP all on its own, and in one pass through the file. At this time,
* it is for outgoing only. A future revision will add command line
* options for incoming and such.
* Might as well group by 1st 2 IP address bytes at the same time,
* i.e. for some (not all) of those multiple IP situations.
*
* tcpdump_bytes.c 2017.09.01 Smythies
* Count the bytes for all the packets in the passed file.
* See also tcpdump_extract.c, from which this was taken.
* This program is very quite, just printing bytes, unless there
* is some error. The idea is that is part of something bigger and
* therefore extra verbosity would just get in the way.
*
* Note: The input tcpdump file needs to have been done
* with the -e option.
*
*****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 2000 /* maximum line length */
void main(int argc, char **argv){
char in_buffer[MAX_LENGTH];
char infile, outfile1, outfile2;
char index, index2;
FILE inf, out1, out2;
unsigned current_bytes, sip3, sip2, sip1, sip0, sport, dip3, dip2, dip1, dip0, dport;
unsigned dest_ip, dest_ip_16, dest_ip_old, dest_ip_16_old;
unsigned num_lines, num_ips, num_16s;
unsigned long long total_bytes, total_bytes_16;
switch(argc){
case 4:
infile = argv[1];
outfile1 = argv[2];
outfile2 = argv[3];
break;
default:
printf("tcpdump_bytes infile outfile1 outfile2\n");
printf(" parse outgoing bytes per IP out of a sorted tcpdump file where the -e option was used.\n");
printf(" infile is sorted tcpdump output file; oufile1 is bytes per IP; outfile 2 is bytes per IP/16.\n");
exit(-1);
} /* endcase */
if((inf = fopen(infile, "rt")) == NULL){
printf("Unable to open input file '%s'\n", infile);
exit(-1);
} /* endif /
if((out1 = fopen(outfile1, "wt")) == NULL){
printf("Error opening output file '%s'\n", outfile1);
exit(-1);
} / endif /
if((out2 = fopen(outfile2, "wt")) == NULL){
printf("Error opening output file '%s'\n", outfile2);
exit(-1);
} / endif */
total_bytes = 0;
total_bytes_16 = 0;
dest_ip_old = 0;
dest_ip_16_old = 0;
num_lines = 0;
num_ips = 0;
num_16s = 0;
while((fgets(in_buffer, MAX_LENGTH, inf)) != NULL){ /* do infile line at a time */
num_lines++;
if((index = strstr(in_buffer, "), length ")) != NULL){ /* find search string if it is there, then parse the data */
sscanf(index, "), length %u: %u.%u.%u.%u.%u > %u.%u.%u.%u.%u:",
&current_bytes,
&sip3, &sip2, &sip1, &sip0,
&sport,
&dip3, &dip2, &dip1, &dip0,
&dport);
} else {
printf("tcpdump_bytes: Got an odd line: %s", in_buffer);
} /* endif */
dest_ip_16 = (dip3 << 24) + (dip2 << 16);
dest_ip = dest_ip_16 + (dip1 << 8) + dip0;
// printf("debug: B: %u S: %u.%u.%u.%u.%u D: %u.%u.%u.%u.%u %u %u\n", current_bytes, sip3, sip2, sip1, sip0, sport, dip3, dip2, dip1, dip0, dport, dest_ip, dest_ip_16);
if(dest_ip != dest_ip_old){
if(total_bytes != 0){
fprintf(out1, "%llu %u.%u.%u.%u\n", total_bytes, (dest_ip_old >> 24) & 0xff, (dest_ip_old >> 16) & 0xff, (dest_ip_old >> 8) & 0xff, dest_ip_old & 0xff);
total_bytes = 0;
} /* endif */
dest_ip_old = dest_ip;
num_ips++;
} /* endif */
total_bytes = total_bytes + (unsigned long long) current_bytes;
if(dest_ip_16 != dest_ip_16_old){
if(total_bytes_16 != 0){
fprintf(out2, "%llu %u.%u.0.0/16\n", total_bytes_16, (dest_ip_16_old >> 24) & 0xff, (dest_ip_16_old >> 16) & 0xff);
total_bytes_16 = 0;
} /* endif */
dest_ip_16_old = dest_ip_16;
num_16s++;
} /* endif */
total_bytes_16 = total_bytes_16 + (unsigned long long) current_bytes;
} /* endwhile */
/* don't forget to output the last data /
if(total_bytes != 0){
fprintf(out1, "%llu %u.%u.%u.%u\n", total_bytes, dip3, dip2, dip1, dip0);
} else {
printf("tcpdump_bytes: Something is wrong. Last IP address has no bytes.\n");
} / endif */
if(total_bytes_16 != 0){
fprintf(out2, "%llu %u.%u.0.0/16\n", total_bytes_16, dip3, dip2);
} else {
printf("tcpdump_bytes: Something is wrong. Last IP/16 address has no bytes.\n");
} /* endif */
fclose(inf);
fclose(out1);
fclose(out2);
printf("tcpdump_bytes: Done. Processed %d lines and %d IP addresses and %d /16 addresses\n", num_lines, num_ips, num_16s);
} /* endprogram */
A quick summary of what the post-processing script is doing:
First, the binary tcpdump file is converted to per packet summaries text. Example (my LAN sub-net is 192.168.111.0/24 and the router is 192.168.111.1):
2020-11-26 12:16:40.077187 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 60: 192.168.111.123.36953 > 69.164.31.0.443: Flags [R], seq 4022180665, win 0, length 0
2020-11-26 12:16:40.077210 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 60: 192.168.111.123.36953 > 69.164.31.0.443: Flags [R], seq 4022180665, win 0, length 0
2020-11-26 12:16:40.077225 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 60: 192.168.111.123.36953 > 69.164.31.0.443: Flags [R], seq 4022180665, win 0, length 0
2020-11-26 12:16:40.077241 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 66: 192.168.111.123.39503 > 99.81.137.214.443: Flags [.], ack 909, win 998, options [nop,nop,TS val 117576 ecr 459725584], length 0
2020-11-26 12:16:40.077251 00:19:b9:0d:af:fa > 64:1c:ae:dc:c0:d3, ethertype IPv4 (0x0800), length 504: 192.168.111.1.53 > 192.168.111.123.49124: 20771 5/4/15 A 8.251.162.11, A 8.240.108.139, A 8.240.90.139, A 8.240.93.139, A 8.240.102.11 (462)
2020-11-26 12:16:40.077412 00:19:b9:0d:af:fa > 64:1c:ae:dc:c0:d3, ethertype IPv4 (0x0800), length 500: 192.168.111.1.53 > 192.168.111.123.49124: 8356 5/4/11 AAAA 2001:1900:2352:104f::1, AAAA 2001:1900:23b2:11::1, AAAA 2001:1900:2304:5f06::1, AAAA 2001:1900:23b2:1::1, AAAA 2001:1900:2304:7055::1 (458)
2020-11-26 12:16:40.235369 00:19:b9:0d:af:fa > 64:1c:ae:dc:c0:d3, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.123 tell 192.168.111.1, length 28
2020-11-26 12:16:40.237464 64:1c:ae:dc:c0:d3 > 01:00:5e:00:00:07, ethertype IPv4 (0x0800), length 246: 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2020-11-26 12:16:40.237479 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 74: 192.168.111.123.33547 > 8.251.162.11.443: Flags [S], seq 2516382973, win 29200, options [mss 1460,sackOK,TS val 117612 ecr 0,nop,wscale 7], length 0
2020-11-26 12:16:40.237508 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype ARP (0x0806), length 60: Reply 192.168.111.123 is-at 64:1c:ae:dc:c0:d3, length 46
2020-11-26 12:16:40.308884 00:19:b9:0d:af:fa > 64:1c:ae:dc:c0:d3, ethertype IPv4 (0x0800), length 74: 8.251.162.11.443 > 192.168.111.123.33547: Flags [S.], seq 829843053, ack 2516382974, win 65160, options [mss 1460,sackOK,TS val 1958034067 ecr 117612,nop,wscale 7], length 0
2020-11-26 12:16:40.311459 64:1c:ae:dc:c0:d3 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 66: 192.168.111.123.33547 > 8.251.162.11.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 117669 ecr 1958034067], length 0
2020-11-26 12:16:40.841355 00:19:b9:0d:af:fa > 00:21:9b:f9:21:26, ethertype IPv4 (0x0800), length 1514: 173.180.45.3.22 > 192.168.111.101.61404: Flags [.], seq 9584:11044, ack 161, win 7733, length 1460
2020-11-26 12:16:40.841375 00:19:b9:0d:af:fa > 00:21:9b:f9:21:26, ethertype IPv4 (0x0800), length 162: 173.180.45.3.22 > 192.168.111.101.61404: Flags [P.], seq 11044:11152, ack 161, win 7733, length 108
2020-11-26 12:16:40.842302 00:21:9b:f9:21:26 > 00:19:b9:0d:af:fa, ethertype IPv4 (0x0800), length 60: 192.168.111.101.61404 > 173.180.45.3.22: Flags [.], ack 11152, win 1026, length 0
It is on purpose that an ARP packet pair is included in the example, to show something that would be excluded from further processing.
There are other some other annoying packet types that will also be excluded from further processing. Notice two lengths shown on each line, the first one is bytes on the wire and the second one is payload length. We want bytes on the wire, and this is why we use the -e option with tcpdump.
Second, outgoing LAN packets can uniquely be identified by finding ": 192.168.111.", so extract all outgoing packets, not including ARP and ICMP, using grep.
Third, using space as a delimiter, field 13 is the destination IP address, so use a complicated bunch of piped commands to extract, count, and sort the destination IP address packets.
Forth, sort the outgoing packets by destination IP address.
Fifth, use the c program to calculate bytes per IP and bytes per IP/16 and sort the output into histograms.
Examples from a few hours:
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-10-16-32.bin.txt
16004 192.168.111.18
109288 192.168.111.1
247652 192.168.111.5
319432 192.168.111.19
11535118 192.168.111.101
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-10-16-32.bin.16.txt
12227494 192.168.0.0/16
Meaning that in the hour from 2020.11.26 10:16:32 to 11:16:32 there were 12,227,494 bytes sent to various clients on the LAN, with a detailed breakdown per client. Note that the 109,288 bytes to 192.168.111.1 are actually bytes from the LAN destined for the router itself. Observe the hour was, by far, dominated by client 192.168.111.101.
Example 2:
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-19-28-43.bin.txt
6605 192.168.111.1
121859 192.168.111.18
213614 192.168.111.20
257793 192.168.111.5
291138 192.168.111.19
2600309 192.168.111.123
7904391 192.168.111.101
2319210919 192.168.111.121
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-19-28-43.bin.16.txt
2330606628 192.168.0.0/16
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-20-28-43.bin.txt
4616 192.168.111.1
22196 192.168.111.20
75687 192.168.111.18
257152 192.168.111.5
346799 192.168.111.19
516269 192.168.111.123
8250344 192.168.111.101
2190976161 192.168.111.121
doug@DOUG-64:~/tcpdump/per-client-test$ cat int-2020-11-26-20-28-43.bin.16.txt
2200449224 192.168.0.0/16
doug@DOUG-64:~/tcpdump/per-client-test$ nslookup 192.168.111.121
Server: 127.0.0.1
Address: 127.0.0.1#53
121.111.168.192.in-addr.arpa name = lg55.smythies.com.
So, the 55 inch lg smart tv was using a ton of internet between 7:28 and 9:28 p.m. this day. i.e. a netflix movie. (2.3e9 and 2.2e9 bytes.)
Issues
. By default, apparmor will not allow the tcpdump post process command to execute. There is likely a better, more secure way, but I did this to be able to move on (set apparmor to complain mode):
doug@DOUG-64:~/tcpdump/per-client-test$ sudo grep tcpdump /sys/kernel/security/apparmor/profiles
/usr/sbin/tcpdump (enforce)
doug@DOUG-64:~/tcpdump/per-client-test$ sudo aa-complain /usr/sbin/tcpdump
Setting /usr/sbin/tcpdump to complain mode.
doug@DOUG-64:~/tcpdump/per-client-test$ sudo grep tcpdump /sys/kernel/security/apparmor/profiles
/usr/sbin/tcpdump (complain)
EDIT: I am finding this client summarizing tool to be extremely useful.

- 15,448
- 5
- 44
- 61
cc tcpdump_bytes.c -o tcpdump_bytes
. I'll have some test from my computer tomorrow. – Doug Smythies Nov 26 '20 at 08:30