When using the Internet, individuals can obtain a Public IPv4 address, such as 142.158.205.201
, or an IPv6 address like 2000:9372:7d2f:34ef:1115:e6b0:5807:eed0
. Verification of this can be done at https://test-ipv6.com/. However, attempting to communicate these addresses, or even referencing MAC addresses like e9:fe:76:34:21:c3
, can be prone to errors and quickly become complex for those not well-versed in technology. Furthermore, this method does not provide any historical data, especially from previous occurrences of problems.
When wanting to access a web page, such as https://ratke-robel.info, the first step is to contact a DNS server to convert the host portion (ratke-robel) along with the Top Level Domain (info) of the URL to an IP address, such as 224.213.240.139
. With each web request, your computer and browser actually conveys its type, as seen in an example like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/7046A194A
.
Typically, the default gateway is an address that is automatically configured via DHCP. A default gateway could be 192.168.193.83
(although they usually end in .1 or .254 depending on the scope size), and it is where a computer sends all its traffic to be routed onwards. For a detailed explanation on IPv6
, refer to how-to-fix-ipv6-connectivity/. Verification on Mac or Linux systems can be done using:
netstat -rn -f inet | egrep -i "default|0/1|128.0/1"
0/1 172.18.12.193 UGScg utun3 default 192.168.193.83 UGScg en0 128.0/1 172.18.12.193 UGSc utun3
Note: We are not just looking for the default but also for any VPN that overrides the public v4 address space.
netstat -rn -f inet6 | egrep -i "default|2000::/3"
If you have IPv6 active the above should return at least one route (as per below) via a known interface such as “en0 " on a Mac.
default fe80:af1a:1150:c754:8c0c%en0 UGcg en0 default fe80::%utun0 UGcIg utun0 default fe80::%utun1 UGcIg utun1 default fe80::%utun2 UGcIg utun2 2000::/3 utun3 USc utun3
Note: We are not just looking for the default but also for any VPN that overrides the public v6 address space.
To get a look at the low level DHCP configuration (Mac/Linux):
ipconfig getpacket en0
... domain_name_server (ip_mult): {252.136.82.48, 140.235.106.139} end (none): ...
So, in the above we are not getting IPv6 DNS servers from the DHCPv4 reply but…
ipconfig getv6packet en0
DHCPv6 REPLY (7) Transaction ID 0x80940b Length 76 Options[4] = { CLIENTID (1) Length 14: DUID LLT HW 1 Time 668691856 Addr e9:fe:76:34:21:c3 DNS_SERVERS (23) Length 32: 2606:4700:4700::1111, 2001:4860:4860::8844 DOMAIN_LIST (24) Length 0: Invalid SERVERID (2) Length 10: DUID LL HW 1 Addr eb:ab:4d:58:72:31 }
When it comes to transmitting data to your router, you may be using either a wired or wireless (Wi-Fi) medium at the physical and data layer.
Regardless of the version of OSX/macOS you are using, whether it’s 10.11.7, 11.0.8, or 12.3.6, there are various troubleshooting tools available. However, these manual actions and scripts do not provide a series of correlated values over time. This is where automated remote troubleshooting becomes especially valuable, particularly for teams that have embraced remote work and Work From Anywhere (WFA) practices.
A very useful tool on OSX/macOS is ‘sudo wdutil info’, which provides a dump to the CLI of current wireless settings, and can also be configured to generate specific troubleshooting logs. Additionally, the ‘sysdiagnose’ tool can be used to generate a wide range of logs, although much of it is only point-in-time information related to wireless, similar to wdutil.
To run ‘sysdiagnose’ in the background, use the command ‘sudo nohup /usr/bin/sysdiagnose -u &’ and it will write logs to ‘/var/tmp/