This involves checking each service out individually, and confirming that it’s working correctly. Layers 5 and 6 are normally fairly barren territory for the troubleshooter on Mac local networks, with layer 7 as the next large and thorny area. When changing settings in that pane, remember to click on the Apply button, or your changes may not take effect. Click on the Apply button, wait a few moments, then add it back with the + button and check its advanced settings. One useful procedure that can fix such problems is to make that service inactive in the Network pane, then delete it with the – button. While you might be able to connect to another local Mac using Wi-Fi, a wired Ethernet connection may not work right, if at all. Sometimes, perhaps following a macOS update, services can behave oddly. Ping is the standard tool for this, and well-supported in WhatRoute.Īs illustrated in my opening example of the blocked kernel extension, there’s more to layers 1-3 than just a visible connection. Multiple DHCP servers are not uncommon when a network has two or more systems which can route traffic and may by default provide a DHCP service, and can give rise to all sorts of strange problems when different devices are assigned the same IP address by different servers.Īrmed with your IP map, you can now start confirming which devices are visible from others on the network, and start looking at layer 4, by checking whether packets are being delayed or lost. If those rely instead on DHCP assigning IP addresses, there could be either of two surprises in store: you could have two DHCP servers handing out IPs, or you could have two devices with the same IP. This is easiest if all your IPs are set manually, as you should know what’s where already, and checking each device is quick and simple. Once you’re happy that there’s no air gap blocking the packets, move on to the most important step of mapping IP addresses, which covers layers 2 and 3. You can also try more direct connections: all modern Macs with built-in Ethernet ports autosense their connections, so you don’t need to use a ‘crossover’ cable intended for back-to-back connection between them. Starting with layer 1, it’s more than helpful if you have a spare Ethernet cable or adaptor you can swap into a wired network to confirm whether a component has failed. That said, you could find yourself coming back to look at lower layers according to your findings. For example, if only one of the protocols in layer 7 is affected, and the others are working fine, there’s little point in going round checking all your Ethernet cables, as you should already know that the first few layers are fully functional. However, if you have a thorough assessment of the symptoms and signs already, you may be able to satisfy yourself that lower layers are already working normally. I summarise its layers in this diagram.Īfter your first inspired guesswork, you’ll often need to start at the bottom with layer 1 and work your way steadily upwards. The best way to structure your testing and diagnosis of network problems is based on the seven layers of the OSI model, which we should all be at least vaguely familiar with. One important collection of tools, Network Utility, has now been removed from macOS Monterey the best third-party replacement for that is Bryan Christianson’s superb and superior WhatRoute, which I’ll use here. As I’ve recently explained its use in detail, I won’t repeat that here. Key tools for working with network problems are the Network and Sharing panes where services are configured, and the Wireless Diagnostics app. Using a more systematic approach is then essential, and the subject of this article. Although this can solve some problems simply, when they prove more obscure we often don’t know what to do next. We tend to try a few things at random, hoping that we can guess right quickly. Apple didn’t push a fixed update until two days later, and neither apology nor explanation was ever provided.ĭiagnosing that and other network problems isn’t easy. Its effect was to completely disable and vanish that Ethernet port when an affected Mac was next started up. On 26 February 2016, Apple pushed an update to the Incompatible Kernel Extension which came with a bug blocking the loading of the kernel extension responsible for implementing the Ethernet port on many Macs.
0 Comments
Leave a Reply. |