If network performance on your laptop is slow and unstable, it might be because power management of your wifi adapter and of Linux are not playing together.
One of the things you will notice are flapping ping rates:
$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=23.3 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=44.7 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1161 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=35.2 ms ... ^C --- 192.168.0.1 ping statistics --- 30 packets transmitted, 20 received, 33% packet loss, time 30000.14s rtt min/avg/max/mdev = 23.3/537.9/2119.2/2005.3 ms
As you can see the 3rd ping has a high round trip time of over one second. You might also notice high packet loss rates.
If this is the case and your hardware seems to be ok, you can try to switch off Network Manager's automatic power management in
wifi.powersave = 2
Restart NetworkManager (sudo systemctl restart NetworkManager) or reboot your Laptop.
If you are not using NetworkManager, you can try to switch off power management directly:
sudo iwconfig wlp2s0 txpower fixed
Afterwards check that power management is really disabled:
sudo iwconfig wlp2s0
... Power Management:off ...
Probably one of the world's most famous public VPN providers is leaking your traffic. The weirdest thing about it is, nobody noticed the traffic before.
Lessons learned: Always check no matter how good the reputation might be.
Update (2019-10) Nobody is perfect. Half a year later, there seems to be another problem with our famous VPN service. Not so much information about it out there, so here is a link in case you want to check yourself.
Lessons learned: Double check for safety's sake.
Update (2019-10) Oh noooo, now our famous VPN provider got hacked really bad. Private keys for OpenVPN have been revealed, but they already expired in 2018. Nevertheless, it could be that those keys were hacked in 2018 when they were still valid. All I can say: "Told ya!"
Lessons learned: Triple check for safety's sake.
List of network ports that the DNS nameserver ISC BIND v9.10 listens to by default:
Port Number UDP / TCP Description
53 UDP standard port to respond to name queries
53 TCP used for master/slave zone transfers or if query answers don't fit in UDP packet
953 TCP communicate with rndc client utility
2200 TCP statistics channel (built-in webserver to display statistics page)
This is the iSCSI connection state if the underlying network interface changes from "UP BROADCAST RUNNING MULTICAST" to "UP BROADCAST MULTICAST".
Log entries showing that the network interface has no longer the state "RUNNING":
Jul 3 14:17:31 host kernel: [974138.571169] bnx2 0000:08:05.0 eth2: NIC Copper Link is Down
Jul 3 23:05:05 host kernel: [1005760.957474] sd 10:0:0:0: rejecting I/O to offline device
... previous message repeats many times ...
Checking iSCSI connection state:
# iscsiadm -m session -P1
iSCSI Connection State: TRANSPORT WAIT
iSCSI Session State: FREE
Internal iscsid Session State: REOPEN
Log entry once the network interface state is back to "RUNNING":
Jul 4 06:56:31 host kernel: [1034019.191222] bnx2 0000:08:05.0 eth2: NIC Copper Link is Up, 1000 Mbps full duplex
Checking iSCSI connection state again:
# iscsiadm -m session -P1
iSCSI Connection State: LOGGED IN
iSCSI Session State: LOGGED_IN
Internal iscsid Session State: NO CHANGE
The output of "iscsiadm -m session -P1" can be used for monitoring the iSCSI connection e.g. in a simple Nagios or Icinga Perl script.
KRDC RDP connection to Windows Server stays blank. You only see an empty screen and no login.
KRDC Host Configuration -> Extra Options --no-nla