- Reference 23.1 Troubleshoot General Network Issues
- Reference 23.2 Use Terminal to Troubleshoot Network Issues
- Exercise 23.1 Troubleshoot Network Connectivity
Reference 23.2 Use Terminal to Troubleshoot Network Issues
macOS provides several network identification and diagnostic commands that you can access in Terminal. This includes, but isn’t limited to, the following:
ifconfig (interface configuration)—Inspect details regarding hardware network interfaces.
netstat (network status)—View routing information and network statistics.
ping—Test network connectivity and latency.
nslookup, dig, host, and dscacheutil—Test DNS resolution.
traceroute—Analyze how your network connections are routed to their destination.
nc (netcat)—Check whether a network device has specific services available.
You can also open Terminal when you start your Mac from macOS Recovery (as covered in Lesson 5, “Use macOS Recovery”) by choosing Utilities > Terminal. In macOS Recovery you can access the Wi-Fi status menu to use a different Wi-Fi network.
The ifconfig command enables you to view the detailed status of any network interface. Each network interface has a short UNIX-given name; for example, the default Wi-Fi interface for Mac portable computers is en0.
If you run ifconfig by itself, it returns the status of all network interfaces, even ones that aren’t configured and that don’t appear in Network preferences. The following figure displays only a portion of the result of running the command. en7 is the name of an Apple USB Ethernet Adapter that’s connected to the MacBook Pro with a USB-C adapter. The name for a network interface may vary depending on the configuration of your Mac, including the other network interfaces you’ve configured for your Mac.
ifconfig is often run with the name of a single network interface. For example, the following figure illustrates running the command ifconfig en0, which returns information about the default Wi-Fi interface.
The entire extent of the output of the command is outside the scope of this guide, but some of the key pieces of information include:
media—Connection speed and characteristics
status—Active or inactive
The netstat command enables you to view even more detailed status of any network interface. One example is netstat -di -I, followed by the interface name. The options include:
-di—Show the number of dropped packets
-I (name of interface)—Show information only about that specific interface
For example, the following figure illustrates running the command netstat -di -I en7, which returns information about a connected Apple USB Ethernet Adapter.
The -I option provides a table with cumulative counts of network packets transferred, errors, and collisions. The -di option adds a count of dropped packets as well. Here are some of the values in the table:
Name—Name of the interface
Address—MAC address, IPv6 address, or IPv6 address; it’s common to see each interface have three addresses listed
Ipkts—Number of packets received by the interface
Ierrs—Number of errors related to packets received by the interface
Opkts—Number of packets sent by the interface
Oerrs—Number of errors related to packets sent by the interface
Coll—Number of collisions detected
Drop—Number of dropped packets detected
You can also use netstat to analyze network transfer statistics. If you open an app like Safari to cause some network traffic, then run the netstat command again, you can verify that packets are being sent and received from this interface. In the following example, there were initially 1,276 received packets; Safari was then used to generate network traffic; then there were 16,100 received packets. It’s safe to conclude that Safari used the en7 interface for network traffic.
If the transfer statistics indicates activity but you still experience problems, the issue is probably a network or service problem and not the network interface. Or, if this interface is experiencing transfer errors, a local network hardware connectivity issue may be the root of your problem.
To resolve hardware network interface issues, check the physical connection. With wired networks, try different network ports or cabling to rule out physical connection issues. With wireless networks, double-check the Wi-Fi settings and the configuration of any wireless base stations. If the Mac network hardware isn’t working, contact an Apple Authorized Service Provider.
If your network settings are properly configured and the hardware network interface appears to be working correctly but you still experience network issues, test network connectivity using the ping command.
The word ping refers to several concepts:
The name of a command
A kind of network packet
The act of using the ping command to send a ping packet
The ping command determines whether your Mac can successfully send and receive data to another network device. Your Mac sends a ping data packet to the destination IP address, and the other device returns the ping packet to indicate connectivity.
To use ping, type ping, then a space, then an IP address to a device on the LAN that should always be accessible, such as the network router; then press Return. Using a domain name assumes that your Mac is properly communicating with a DNS server, which might not be the case if you’re troubleshooting connectivity issues.
If the ping command is successful, it returns the amount of time it took for the ping to travel to the network device and back. This round trip typically takes a few milliseconds. You can use the -c option (count) with a number of packets to send, or if you omit the -c option, the ping command will repeatedly send packets until you stop the ping command by pressing Control-C or Command-Period.
After you stop the ping command, the ping command returns how many packets ping transmitted, how many packets were received by the remote device, and a percentage of packet loss.
Some network administrators configure their firewalls to block pings or to set up their network devices not to respond to network pings.
After you establish successful pings to local devices, branch out to WAN or internet addresses. Using ping, you may find that everything works except for the one service you were looking for that prompted you to start troubleshooting the network.
If you are able to successfully ping other network devices by their IP address but you can’t connect to another device by its hostname, you likely have issues related to DNS. Several commands are available that let you test name resolution against your DNS server. This section covers the following commands, each listed here along with the description from the name section of its man page:
host—DNS lookup utility
dig—DNS lookup utility
nslookup—Query internet name servers interactively
dscacheutil—Gather information and statistics and initiate queries to the Directory Services cache
To verify DNS, use one of the commands in this section to query the hostname of a device or service in your local domain. If you can resolve local hostnames but not internet hostnames, your local DNS server is resolving local names but isn’t properly connecting to the worldwide DNS network. If you don’t have a local domain, use any internet hostname.
To start the network lookup process with the host command (DNS lookup utility), type host, a space, then an IP address or hostname; then press Return.
The following figure illustrates a successful forward lookup, which returns the IP address of the hostname you entered.
The following figure illustrates a successful reverse lookup, which returns the hostname of the IP address you entered.
The nslookup command returns a bit more information, which might be useful for your troubleshooting. The following figure illustrates using nslookup for a forward lookup and then a reverse lookup.
The dig command returns even more information. Use the -x option to perform a reverse lookup. The following figures illustrate using dig for forward and reverse lookups.
And finally, for this section, you can use the dscacheutil command for more advanced DNS troubleshooting.
For a DNS lookup, use two dscacheutil options followed by the hostname or IP address you want to look up. Here are the two options, along with arguments you should use for a DNS lookup:
-q—This is the type of query, like user, group, or host. For DNS lookups, use -q host.
-a—This is the key to look up. For forward lookups, use -a name; for reverse lookups, use -a ip_address. And as a bonus, to use an IPv6 reverse lookup, use -a ipv6_address.
To perform a forward DNS lookup, type dscacheutil, a space, -q host -a name, a space, and the hostname; then press Return.
To perform a reverse DNS lookup, type dscacheutil, a space, -q host -a ip_address, a space, and the IPv4 address; then press Return.
If you are unable to successfully return lookups, it’s possible that your Mac isn’t connecting to the DNS server. Use the ping command to test for basic connectivity to the DNS server IP address.
If you are able to connect to some network resources but not others, use traceroute to determine where the connection fails. WAN and internet connections often require the data to travel through many network routers to reach their destination. The traceroute command examines every network hop between routers by sending packets with low time-to-live (TTL) fields to determine where connections fail or slow down.
To verify a network TCP/IP route, use traceroute followed by an IP address of a device on the LAN that should always be accessible, such as the network router. Using a domain name assumes that your Mac is properly communicating with a DNS server, which might not be the case if you’re troubleshooting connectivity issues.
If traceroute is successful, it returns a list of routers required to complete the connection and the amount of time it took for the test packets to travel to each network router. It sends three probes at each distance, so three times are listed for each hop. The delay is typically measured in milliseconds; experiencing delay times of any longer than a full second is unusual. If traceroute doesn’t get a reply from a particular router at all, it shows an asterisk rather than listing the router address, but this could be because the network equipment is configured not to respond to network requests.
Once you’ve established successful routes to local devices, you can branch out to WAN or internet addresses. Using the traceroute command, you may find that a specific network router is the cause of the problem.
For more information about any of the commands in this lesson, use the man page for the command.