TCP/IP Connections Introduction User Modes Connect Via... Addressing Subnet Masks Config Router Address DNS Search Paths Hosts File 802.3 Saving Configs Troubleshooting Tools For More Info Glossary updated: 08/11/97

Troubleshooting There are a lot of factors that could cause network connectivity problems: Problems with physical connections between host and network Problems with local system software Problems with local configuration Problems with local applications Problems with physical connections between 2 or more networks Problems with services being down (mail servers, dns servers) Try to determine what type of problem you're dealing with: Is it clearly a "local" software problem, such as system errors, freezing, corruption in software (error -39)? TIPS. Does the problem occur in different applications? when connecting to different hosts? when using IP addresses instead of domain names? Finding the answer to these questions will help you determine if you're dealing with something application-specific, host-specific, dns server specific, or something in between (configurations, physical connections). TIPS. Is everyone else on the network experiencing the same kind of problem? If so, (and if these services worked before) its probably not a problem with their applications or configurations, but something outside that: look for problems with hubs, routers, servers, etc. TIPS If only one of the machines on the network can duplicate the problem, then check physical connections and configuration. TIPS TIPS When its a software problem... Use the usual software troubleshooting techniques to isolate problems such as system errors, freezing, and applications unexpectedly quitting, such as testing with third party extensions off, removing preference files, and reinstalling corrupt software. Remember that its helpful to have customers take a screenshot of their TCP/IP configuration before removing their preferences, so they'll be able to reconfigure. Also, its not necessary to actually trash preference files, just leave them on the desktop. When it occurs in only one application... If other IP applications work properly--they can open connections, names get resolved, etc.--then the problem would seem to be one "problem" application, or its settings. Unless the application is a supported Apple product, like Cyberdog, we would refer the customer to the developer of the application he or she is using. When problems occur in all applications... If none of the users applications are working properly, its time to find out if other nodes on the network are affected or if its just this one machine. When all nodes are affected... If all devices on the network are having the same problem, then it's likely to be some network, router, or server problem. Test Physical Connection See if AppleTalk is working over the network to verify the physical connection (could be a problem with the hub they're all connected to). Try Pinging Different Devices If AppleTalk works, see if the customer can make a connection to another device on the same subnet; ping utilities (MacTCP Ping, MacTCP Watcher) are very useful for this, since it doesn't require the target host to be running any particular type of service. Targeting devices on the same subnet, and using IP addresses to ping rather than domain names, removes a couple of variables from the picture and helps you isolate where the problem is coming from. When pinging Mac to Mac, make sure that both Macs that TCP/IP is active on both machines. The TCP/IP stack become active when an IP application is launched (or on startup if the "load only when needed" option in the TCP/IP control panel is UNchecked). A Mac cannot respond to pings if the IP stack is not active. If the two devices are able to ping each other, next try pinging the router (it could be down or the address may be incorrect), then the dns server, then some external hosts. Check Configuration Having two devices on the same subnet ping each other removes many of the variables that can affect connections. If the two devices can't ping each other, check configuration information carefully; the two devices should have the same network number, should be using the same subnet mask, and should have the same settings for "802.3" (normally, this will be unchecked). In addition, when two Macs are trying to communicate directly to each other, they should either both be using MacIP, or neither using MacIP. If both are using MacIP, make sure they're talking on the same AppleTalk network (can they see each other in the chooser?) And again make sure that the IP stack is active on the Macs; if the "load only when needed" option is checked in the TCP/IP cdev, the stack only becomes active when an application that uses TCP/IP (NetScape, Telnet, Fetch) is first launched. If no IP applications are running, the IP stack may not be active, and the Mac may not respond. When only one node is affected... With only one device having problems on a network, its likely to be a problem with physical connections, with configuration, or with the particular application they're using. But when you're dealing with some, but not all, machines having problems, don't rule out misconfiguration, since its possible that they were set up at the same time by the same person, and were all misconfigured or miswired. Check physical connections; see if Appletalk is working by looking for servers or printers in the Chooser. Check TCP/IP Settings. If the physical connection appears to be okay, check configuration in the TCP/IP control panel carefully. Compare the configuration to that of a machine on the same subnet that is able to connect successfully; look especially for mistypings of the IP addresses, the subnet masks, the router, and dns servers. Make sure the link selected in "connect via" popup is correct. Make sure "802.3" is not selected if using Ethernet. Check for duplicate IP addresses. Make sure the IP address being used is not already in use by someone else. You could do this by shutting down the problem machine, then attempting to ping its address from another machine. If you get a response, some else is using that address. Another test is to take the settings from a machine that's working properly,shut down that machine, and set up the "problem" machine with the same settings. When it appears to be router problem If two devices on a network can ping each other, but nothing else, the problem is most likely the router. Check the router address in the TCP/IP control panel, and try pinging it. If no ping utilities are available, you can usually try opening a connection to the router with NCSA Telnet. If you get the "login:" prompt, you're connecting. If you get no response from the router, it could be that that the router is down for maintenance, or this is the wrong address. If the IP address of the router does respond, but you still can't connect to anything outside the customer's subnet, its still time to check the address. Possibly this is not, in fact, the router address. You will need to deal with the network administrator at this point. When its a DNS problem If devices can connect using IP addresses but not domain names (and remember, try with different applications and try with different domain names), look for problems with their dns entries, or the dns server itself. If you can't ping the dns servers that they have entered in the TCP/IP control panel, they may be down for maintenance, or a router between you and them may be down. The customer should deal with his network administrators or ISP's at this point. [Intro |UserModes |ConnectVia |Addressing |Subnet Masks |Config|Routers |DNS |Search Paths |Hosts File |802.3 |Saving Configs |Troubleshooting ]Tools |More Info |Glossary ]