What is wlp0s20f3?
A new naming scheme has been introduced, to solve problems that arose from the old (eth0, wlan0) naming standards. Could not set interface wlp0s20f3 flags (UP): Operation not permitted nl80211: Could not set interface 'wlp0s20f3' UP nl80211: deinit. ip link: wlp0s20f3:
Communication on the internet is done over TCP/IP which is short for Transmission Control Protocol / Internet Protocol. The IP portion is the internet address or domain name telling the application what computer or server to connect to. The TCP portion handles the actual connecting and error control.
In order, the layers in the TCP/IP network model include:
Knowing where to start troubleshooting network issues can differ based on the scenario. For example, if the user can ssh to a remote server, but that server can't connect to a MySQL database, the problem is unlikely to be the physical or data link layers on the local server.
In most cases it's a good idea to start at the top most layer (the application layer), and then troubleshoot each other layer until we have narrowed down the issue.
This article is organized into sections each focusing on one of these layers except for the Application layer because that could mean having to debug source code.
The transport layer consists of the TCP and UDP protocols, with TCP being a connection-oriented protocol and UDP being connectionless. What that means is with TCP you get error correction but with UDP you basically just hope your data arrrived ok.
Applications listen on sockets, which are made up of an IP address and a port number. Network traffic heading to an IP address on a specific port will be directed to the application that is listening by the Linux kernel.
The first thing that you may want to do is see what ports are listening on the localhost. This output can be useful if you can't connect to a particular service on the computer, such as a web or ssh server. Another common issue occurs when a daemon or service won't start because of something else already listening on that port.
The ss command is great for doing these kind of operations.
The ss command is a powerful tool, and a review of its man page (man ss) can help you locate flags and options to find whatever you're looking for.
Let's break down some of these options:
SS Command:
Output:
Looking at the output, we can see several listening services. The sshd application is listening on port 22 on all IP addresses, as the text 0.0.0.0:22 shows.
Here's another scenario, if the application isn't listening for some reason, and we need to use the previous troubleshooting steps (again using ss) on the remote host; that is if we have access. Another possibility is a host or firewall that is filtering network traffic. We may need to work with the networking team to verify Layer 4 connectivity across the path.
For UDP we will want to use the netcat tool. This tool gives a simple way to check a remote UDP port.
NOTE: the netcat utility can be used for many other things, including testing TCP connectivity. Note that netcat may not be installed on your system, and it's often considered a security risk to leave lying around. You may want to consider uninstalling it when you're done troubleshooting.
Netcat Command:
Output:
The examples above discussed common, simple utilities. However, a much more powerful tool is nmap. It's capable of doing:
There are more advanced programs such as tcpdump and wireshark as well.
Layer 3 involves working with IP addresses. IP addresses are like the street address of the computer on a TCP/IP network. Instead of specifying an address, DNS servers are used so it will say "Dave's house" instead of the actual street address.
On the internet it works like this:
Users can go to "https://google.com" instead of "https://###.###.##.##:####"
In this 3rd layer, one of the first steps to troubleshooting is checking a computer's IP address, which can be done with the command ip address, again making use of the -br flag to simplify the output:
IP Command:
Output:
The enp57s0f1 (ethernet) interface has an IPv4 address of 10.0.0.88. If we didn't have an IP address (or if we had an invalid, self-assigned IP address), then we'd want to troubleshoot that issue.
The lack of an IP address can be caused by a local misconfiguration, such as an incorrect network interface config file, or it can be caused by problems with the DHCP server. The wlp0s20f3 interface (Wi-Fi) has a different IP address on the local network.
The most common tool used to troubleshoot Layer 3 is the ping utility. Ping sends an ICMP Echo Request packet to a remote host, and it expects an ICMP Echo Reply in return. ICMP stands for Internet Control Message Protocol and only lives in Layer 3. If you're having connectivity issues to a remote computer, ping is a common utility to begin troubleshooting. Executing a simple ping from the command line sends ICMP echoes to the remote host indefinitely; press CTRL + C to end the ping or pass the -c # flag, like so:
Ping Command:
Output:
Notice that each ping includes the amount of time it took to receive a response back.
The next tool in the Layer 3 troubleshooting tool belt is the mtr command. This command doesn't come preinstalled with Ubuntu or Pop so we'll need to install it with the command sudo apt install mtr-tiny.
Mtr is short for "My Traceroute" and by default will show an autoupdated output. To quit mtr simply press the 'q' key.
Mtr takes advantage of the Time to Live (TTL) field in IP packets to determine the path that traffic takes to its destination. Mtr will send out one packet at a time, beginning with a TTL of one. Since the packet expires in transit, the upstream router sends back an ICMP Time-to-Live Exceeded packet. Mtr then increments the TTL to determine the next hop. Unlike the original traceroute command, mtr is more user interactive. To make mtr act more like traceroute we can use the -r option.
The resulting output is a list of intermediate routers that a packet traversed on its way to the destination:
MTR Command:
Output:
Another common issue could be a lack of a gateway for a particular route or a lack of a default route. When an IP packet is sent to a different network, it must be sent to a gateway for further processing. The gateway should know how to route the packet to its final destination. The list of gateways for different routes is stored in a routing table, which can be inspected and manipulated using ip route commands. Routers are the most common gateway devices.
We can print the routing table using the ip route show command:
IP Route Show Command:
Output:
On this system there is both WiFi (wlp0s20f3) and Ethernet (enp57s0f1) network interfaces. The metric number tells the system which interface to use first; the lower number will be used first then the next lower etc.
Simple networks often just have a default gateway configured, represented by the "default" entry at the top of the table. A missing or incorrect default gateway is a common issue.
If the network is more complex then it will require different routes for different networks. Check the route for a specific prefix with the ip route show command:
IP Route (with IP Address) Command:
Output:
In the example above, we are sending all traffic destined to the 10.0.0.0/24 network to a different gateway (10.0.0.88).
A telltale sign of DNS trouble is the ability to connect to a remote host by IP address but not its hostname. Performing a quick host on the hostname can tell quite a bit (host is part of the bind9-host package on Ubuntu / Pop!_OS Linux based systems):
Host Command:
Output:
The output above shows the resulting IPv4 addresses as well as IPv6.
The data link layer is responsible for local network connectivity; the communication of frames between hosts on the same Layer 2 (commonly called a local area network, or LAN). The most relevant Layer 2 protocol for most sysadmins is the Address Resolution Protocol (ARP), which maps Layer 3 IP addresses to Layer 2 Ethernet MAC addresses. When a host tries to contact another host on its local network (such as the default gateway, e.g. the router), it will more than likely have the other host's IP address, but it doesn't know the other host's MAC address. ARP resolves this issue and figures out the MAC address for us.
A common problem could be an ARP entry that won't populate, particularly for your host's default gateway. If your localhost can't successfully resolve its gateway's Layer 2 MAC address, then it won't be able to send any traffic to remote networks. This problem might be caused by having the wrong IP address configured for the gateway, or it may be another issue, such as a mis-configured switch port.
We can check the entries in our ARP table with the ip neighbor command:
IP Neighbor Command:
Output:
("is the Ethernet cable plugged in?") We can easily troubleshoot physical layer problems from the Linux command line.
Start with the most asked question: Is the physical interface up? For this, use the ip command.
The ip link show command tells us:
IP Link Command:
Output:
Notice the indication of DOWN in the above output for the enp57s0f1 interface. This result means that Layer 1 isn't coming up. Try troubleshooting by checking the cabling or the remote end of the connection (e.g., the switch) for problems.
Before you start checking cables, though, it's a good idea to make sure that the interface isn't just disabled. Running a command to bring the interface up can rule this problem out:
The output of ip link show can be difficult to parse at a quick glance. Luckily, the -br switch prints this output in a much more readable table format:
Command:
Output:
It looks like ip link set enp57s0f1 up did the trick, and the Ethernet interface enp57s0f1 is up and running again.
Interfaces can be misconfigured for the incorrect speed, or collisions (besides those inherent with Ethernet) and physical layer problems can cause packet loss or corruption that results in retransmissions. Use the -s flag with the ip command to print additional statistics about an interface. The output below shows an interface, with only a few dropped receive packets and no other signs of physical layer issues:
Command:
On the other hand, wlp0s20f3 has both UP and RUNNING flags present. The name prefix wl indicates this is a wireless interface, which makes sense as you said this is a laptop. An en prefix would indicate a wired interface.
So, the IP address of the wlp0s20f3 interface (i.e. 192.168.0.23) would be the one to use for inbound SSH connections from other physical hosts.
The interfaces docker0, virbr0 and virbr1 are for facilitating networking between Docker containers and/or virtual machines running on this system: depending on other settings, they might allow containers/VMs communicate only with the host OS, or they might allow NAT-based access to the world outside this physical host. To understand their exact purpose, it might be necessary to study the iptables NAT and forward filtering rules (i.e. sudo iptables -Lvn -t NAT and sudo iptables -Lvn).
If your laptop had the appropriate data records embedded in its firmware, its integrated wired network interface should get identified as eno1 and the wireless one as wlo1. But apparently your laptop's firmware does not include those records. If you wish, you could change the interface names by creating two simple /etc/systemd/network/*.link files.
First, you would need to use e.g. sudo udevadm info -q all -p /sys/class/net/enp0s31f6 | grep -e ID_NET_NAME -e ID_PATH to identify the hardware path and the autodetected name candidates for your network interface. The output might look something like this:
If the ID_NET_NAME_ONBOARD line does not appear, that confirms your system firmware does not properly identify the network interface as an onboard one. You might wish to fix this by renaming the interfaces to use the names they would have ideally been assigned to anyway. To rename this interface, you would note the ID_PATH= line, and use it to write a configuration file as e.g /etc/systemd/network/70-eno1.link with the following contents:
and likewise for the wireless interface.
Related Questions
No More Questions available at this moment!
