Questions[tcpdump](ubuntu)

tl;dr The bandwidth usage recorded by nload (home page) is higher than what's provided by tcpdump (home page).

There seems to be a difference in bandwidth usage when I run tcpdump -e -w - | pv -a > /dev/null as opposed to running nload.

For example, I saw a bandwidth usage of 150kbps using nload but only 30kbps using tcpdump. To rule out pv, I've done the following:

# open a tmux session where tcpdump dumps all traffic into a file for 60 seconds
$ tmux new-session -d -s tcpdump_60secs 'tcpdump -e -w tempfile' && sleep 60 && tmux kill-server

$ wc -c tempfile
# divide by 60, resulting in bytes per second

Any pointers to how nload gets its bandwidth statistics will be appreciated.

Replicated on a clean Ubuntu 18.04 install, on a LXC proxmox container, tested with nload build using commit 8f92dc0.

As of having recently installed a new internet provider (century link) and new C3000Z router, my Ubuntu 16.04.6 machine occasionally stops being able to contact the internet. No other devices on my network have this problem (including a 18.04 machine, an android phone, iPhone, Windows machine, and Echo), which is why I think something's up with my computer.

To go into more detail, what happens is that about 4 or 5 times daily, all of a sudden, new requests stop working, including:

• ping yahoo.com
• nslookup msn.com
• Navigating to google.com in a browser
• Navigating to my router's admin console, 192.168.0.1 in a browser (no DNS lookup here!)

However! When this happens while I'm on a Zoom video call (outages happen also when I'm not on a call), that Zoom call will always keep working seamlessly even though no other new connections can be made. I feel like perhaps Slack has continued working once or twice too, but my memory is flaky. So perhaps the problem is only in creating new connections, although probably not in DNS lookup.

Re-connecting to the same wifi network always solves the problem ... for a while.

During the pseudo-outage, the computer thinks it's still connected to the wifi network. A tcpdump suggests that lots of packets are being dropped:

$ sudo tcpdump -vv -i wlp58s0 -W 1200
tcpdump: listening on wlp58s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:14:15.785694 IP (tos 0x0, ttl 45, id 25896, offset 0, flags [DF], proto UDP (17), length 1094)
   44.233.230.198.8801 > 192.168.0.4.48514: [udp sum ok] UDP, length 1066
^C

1 packet captured
13079 packets received by filter
13072 packets dropped by kernel

and if I let it run while I disconnect/reconnect the network:

$ sudo tcpdump -vv -i wlp58s0 -W 1200
tcpdump: listening on wlp58s0, link-type EN10MB (Ethernet), capture size 262144 bytes

-- this is where it freezes, until I reconnect to the network, at which point it dumps the following --

21:04:31.168038 IP (tos 0x0, ttl 64, id 45078, offset 0, flags [DF], proto UDP (17), length 75)
    192.168.0.4.50205 > 9.9.9.9.domain: [bad udp cksum 0xd306 -> 0x1d68!] 19586+ A? addons-pa.clients6.google.com. (47)
21:04:31.170575 IP (tos 0x0, ttl 64, id 12823, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.0.4.52565 > 192.168.0.1.domain: [bad udp cksum 0x8195 -> 0xc70b!] 53364+ PTR? 9.9.9.9.in-addr.arpa. (38)
21:04:31.350540 IP (tos 0x0, ttl 64, id 12868, offset 0, flags [DF], proto UDP (17), length 70)
    192.168.0.4.37370 > 192.168.0.1.domain: [bad udp cksum 0x8199 -> 0xf08f!] 28407+ PTR? 4.0.168.192.in-addr.arpa. (42)
21:04:31.353225 IP (tos 0x0, ttl 64, id 45094, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.0.4.52599 > 9.9.9.9.domain: [bad udp cksum 0xd2fd -> 0x2cf1!] 47256+ A? play.google.com.Home. (38)
21:04:31.386854 IP (tos 0x0, ttl 64, id 32603, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.4.34720 > 216.58.194.174.https: Flags [.], cksum 0x5bbc (incorrect -> 0x7522), seq 2562207201, ack 1450936360, win 1444, options [nop,nop,TS val 3592576 ecr 807890922], length 0
21:04:32.226837 IP (tos 0x0, ttl 64, id 45132, offset 0, flags [DF], proto UDP (17), length 79)
    192.168.0.4.41087 > 9.9.9.9.domain: [bad udp cksum 0xd30a -> 0x4649!] 39943+ A? 17.client-channel.google.com.Home. (51)
21:04:32.229292 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.4 tell 192.168.0.12, length 46
21:04:59.938894 EAPOL key (3) v2, len 117
21:04:59.940299 EAPOL key (3) v1, len 117
21:04:59.945046 EAPOL key (3) v2, len 175
21:04:59.945118 EAPOL key (3) v1, len 95
21:04:59.962715 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff90:cdb3 to_ex { }]
21:04:59.975011 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 9c:b6:d0:e1:c3:53 (oui Unknown), length 300, xid 0xd280b925, Flags [none] (0x0000)

and if I'd exited from tcpdump before reconnecting it summarizes:

Other things I've tried, but they didn't fix a thing:

• Disable IPv6 (set to Ignore in Network Connections dialog)
• Switch IPv4 settings to Automatic (DHCP) addresses only from Automatic (DHCP)
• Explicitly set a DNS server in Network connections (typically my machine uses the router as DNS)
• Explicitly set a static DNS on the router itself, instead of Century link's dynamic one.
• Disable dnsmasq:

$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1    # This is my router
nameserver 9.9.9.9
search Home

I don't know much about networking, and definitely have hit the limits of what I can google. Where should I be looking next?

I am looking for a reliable solution to do package capture for test automation.

Right now, tcpdump has been used with the following command.

sudo tcpdump -i ens160  -w filename.pcap -G 60 -W 1 

I stop tcpdump with:

kill -s SIGINT <pid>

1 out of 20 time tcpdump fails to exit properly, and the pcap file will be damaged.

Is there any way to make sure tcpdump will exit properly?

Here with another question :) Not sure if it is a dumb one .. I was experimenting with the tcpdump command and want to know how to analyse the logs once captured For example: 06:47:41.060885 IP > ip-.us-west-2.compute.internal.ssh: Flags [.], ack 144, win 256, length 0 06:47:41.779943 IP ip-6.us-west-2.compute.internal.ssh > : Flags [P.], seq 144:208, ack 1, win 284, length 64

What do the fields indicate and how do you confirm there is an issue with the traffic? Thankyou

In Ubuntu 12.04 I can use the tcpdump command to see network packets in real time. A typical invocation could look like this: tcpdump -pni eth0

In Ubuntu 14.04 the exact same command no longer displays packets in real time. When I run the command nothing happens for the first second. After a second it prints out all the packets transferred during the last second and then stops again.

Having packets in the packet capture show up out of order compared to other output I am looking at makes it harder to debug networking problems.

Is there any way I can get tcpdump to behave like it used to and display the packets as soon as they are transferred instead of waiting up to a second each time?

No, I cannot use WireShark as I have to debug machines that are on the Internet, not on the same LAN.