When you become aware of a network problem, the first step is always to define the specific symptoms of the problem. This section describes some problems, presents strategies for obtaining more specific information, and offers solutions for the possible causes.
NetWare for Macintosh provides the ATCON server utility for diagnosing conditions on the AppleTalk network. If you have a problem with general network operation, it is a good idea to start diagnosing the problem by using ATCON.
Please see Using ATCON to Diagnose the AppleTalk Network for an introduction.
To diagnose the cause of this problem, you need to narrow the problem down and try to localize it to one of the components: the Macintosh client itself, the AppleTalk configuration in the NetWare server, the network hardware connecting them, or the configuration of another router on the network.
Figure 62 depicts a typical error condition where zone names appear in the Chooser, but the server name does not appear when the Macintosh user selects the server's zone.
Figure 62
Server Name Does Not Appear in Chooser
Another type of error condition can occur in which no zone names appear in the Chooser, or zones that you just specified in a newly configured server do not appear. In either this case or the case depicted in Figure 62, you can begin to troubleshoot the problem by verifying these conditions:
Can the client can see other AppleTalk services?
First, choose another AppleTalk service on the same network as the problem Macintosh.
If the Macintosh cannot see any AppleTalk services (or any AppleTalk zones) and you know that other services or zones exist, then the workstation itself or the cable to which it is connected are suspect. See Macintosh Client Solutions and Network Cabling Solutions.
If the name of another service appears, you know that the Macintosh is capable of communicating on the AppleTalk network. In this case, the problem is more likely to be a router or cabling problem. See AppleTalk Solutions on the NetWare Server and Network Cabling Solutions.
Can another Macintosh client see the NetWare server?
Go to another Macintosh client, select the file server's zone in the Chooser, and see whether the server's name appears. The physical proximity of the client to the server and thus the actual network cable may be a factor.
If the Macintosh client at the second location can see the NetWare server, swap the problem Macintosh to that network connection and see whether you can still see the server. If so, the network connection at the original problem location is suspect. See Network Cabling Solutions.
If the second Macintosh client can't see the NetWare server either, then the server's AppleTalk configuration is suspect. See AppleTalk Solutions on the NetWare Server.
Can the NetWare server see the Macintosh?
Use the Echo test function in ATCON. Or, if you have a copy of the Macintosh Responder application, install it in the client Macintosh and then use the Lookup service function in ATCON from the server console. See Looking Up an AppleTalk Service.
If the server can "see" the Macintosh but not vice versa, then the network software in the Macintosh is suspect. Step 4 will verify whether the problem originates with the Macintosh, but it helps to narrow the problem if the server cannot see the Macintosh client running Responder.
Can the server see another Macintosh on the same network?
Use the Echo test function in ATCON. Or, if you have a copy of the Macintosh Responder application, install it in the client Macintosh and then use the Lookup service function in ATCON from the server console. If the server can "see" the second Macintosh but could not see the original problem Macintosh, then there could be a problem with the connectors at the Macintosh client or the Macintosh network interface board.
This section provides a checklist to rule out possible problems on Macintosh clients that cannot see the NetWare server. In most cases, a problem with one of the items in this section prevents any AppleTalk zones from showing in the Chooser.
If the network hardware in the Macintosh is loose or incorrect, the Macintosh will not be up on the AppleTalk network, so no zones will show in that workstation's Chooser.
If you are using an Ethernet or Token Ring board for the Macintosh, check that the network connection to the Macintosh network board is secure, and properly connected to the board and the cable. On Ethernet, make sure the Thick/Thin switch is set correctly on the network board. Also, make sure that any Ethernet cable is properly terminated.
If the client Macintosh is connected to LocalTalk, make sure the LocalTalk cable is connected to the Macintosh printer port, not the modem port, and that the LocalTalk cable connections are not loose or unplugged. LocalTalk cable connections can work loose if you don't secure them with cable ties.
If you have set the network CDEV in the Macintosh Control Panel incorrectly, the Macintosh will not be up on the AppleTalk network, so no zones will show in the Chooser.
In the Network area of the Macintosh Control Panel, the selected network connection software icon indicates the network CDEV. This must match the type of network configured in the router for the cable supporting the Macintosh. A common mistake is to confuse EtherTalk Phase 1 and EtherTalk Phase 2. See the Using the NetWare for Macintosh Client guide for more information.
Network drivers are provided with Macintosh network boards. Please see the documentation for the board to verify that you installed the driver properly.
If AppleTalk is not enabled in the Chooser, the Macintosh will not be up on the AppleTalk network, so no zones will show in the Chooser.
If you are using Token Ring Source Routing, make sure that you use it consistently on all Token Ring interfaces, including TokenTalk boards in Macintosh clients. Please see the documentation for the TokenTalk board to verify that you enabled Source Routing if appropriate.
Disconnect the Macintosh client from the network cable and connect it to a printer via a single LocalTalk connection. Verify that its peripheral devices (if any) and power source are operating correctly.
This section provides a checklist to rule out possible problems in the NetWare server. You can check which protocols you bound to the network board by using the CONFIG command at the console prompt. You should see "lan protocol: AARP" and "lan protocol: AppleTlk."
The list of AT-compatible and Micro-Channel network boards that are known to work with AppleTalk is continually being updated. The list as of this printing is included in the README.1ST file on the NWMAC diskette. You can obtain the most up-to-date information on these boards from your dealer or through NetWire.
You can check which modules are loaded by using the MODULES command at the console prompt. If the NetWare for Macintosh v3.12 modules fail to load and you see an error message that begins with you are probably loading the modules in incorrect order. The load order is critical to the Macintosh NLMs. You must load the AppleTalk module first. That is, you must load the APPLETLK NLM before any others, such as AFP, ATPS, or ATCON.
If you are using Token Ring Source Routing, make sure that you use it consistently on all Token Ring interfaces, including TokenTalk. Novell's NetWare Supplement for IBM Token Ring boards documents Token Ring Source Routing. See Using Token Ring with Macintosh Clients.
Use the ATCON utility to see whether the server can communicate on the AppleTalk network and to determine where it runs into problems. Please see Using ATCON to Diagnose the AppleTalk Network for an introduction and the subsequent sections in Using ATCON for details.
This section provides a checklist to rule out possible problems with the network cabling between the Macintosh client and the NetWare server. If there is a bridge or router between the server and Macintosh client(s), make sure that this condition is true: If there is more than one router or bridge between the server and the Macintosh client, first try to isolate the problem by using the ATCON utility to verify communication through each router/bridge, one by one, using the Echo test and/or Lookup services. Please see Using ATCON to Diagnose the AppleTalk Network for an introduction, and the subsequent sections in Appendix C for details.
If the network cable is either twisted-pair or thin Ethernet, make sure that this condition is true:
If the network cable is twisted-pair Ethernet, make sure that this condition is true: Some twisted-pair concentrators have link-status lights to indicate that a connection is functioning properly.
If the cable is thin Ethernet, make sure that these conditions are true: Make sure all nodes on the cable have a T-connector connecting the node to the thin Ethernet segment, as shown in Figure 63. Figure 63
On thin Ethernet, the last node on a segment must have the open end of its T-connector terminated.
If the cable is thick Ethernet, make sure that this condition is true: If you have packet-analyzer software, you can verify that the transceiver and cable are passing packets. Some transceiver boxes have a status light that verifies that packets are moving properly across the cable.
If the cable is Token Ring, make sure that these conditions are true: You should see a console message if the Token Ring MAU is not working.
Many Token Ring cards support both 4 and 16 MBs. Make sure that all nodes on the cable are operating at the same speed.
If you have checked the above conditions and still suspect the network cabling or connectors, follow these steps: If you have a resistance meter, use it to look for intermittent faults in the cable and connectors.
Swapping the equipment with another cable and set of connectors will definitely verify whether the cable or connectors are at fault.
This problem results from the way in which AppleTalk maintains routing tables and zone information on the internet. The reasons for this problem are explained in How Zone Information Is Maintained on an Internet. If this problem is occurring at your site, and the reconfigured router is the only router directly connected to the network supporting new zones, bring down the router again and allow it to stay off the network for at least twenty minutes. When you bring up the router again, the new zones will be in effect. Of course, if more than one router is connected to the network supporting new zones, all of them must be reconfigured to support the same zones. Make sure that other networks don't support the old zones. If they do, bring down all the routers, reconfigure the zones, and leave them down for at least twenty minutes. When you bring up the routers, the new zones will be in effect. Please see Changing the AppleTalk Zone Name or Zones List and How Zone Information Is Maintained on an Internet. You must correctly configure AppleTalk network numbers for the router to function correctly on an internet. If you see errors about mismatched or conflicting network numbers in the system log, select View Router Interfaces in ATCON to see what each server is advertising as its network numbers. NOTE: The DISPLAY NETWORK command shows only IPX network numbers. Use ATCON to view the AppleTalk network numbers. The example internet shown in Figure 64 demonstrates the basic principles of correct configuration:
Figure 64
These ports must both use exactly the same network and zone configuration for the backbone. The first name in the zones list (default zone) must be consistent in both routers.
These ports must use different network numbers, because they are two different cables.
These ports must use different network numbers, because they represent two different networks.
All facets of checking for consistent and unique network numbers on an internet cannot be covered here, but you can use the following general checklist for router configurations. For each AppleTalk port in a router, make sure that these conditions are true: This condition does not imply that each AppleTalk port must be configured with a unique network number or range. It means that the network number or range of the network in which the AppleTalk port is configured must be unique among networks in the internet. Multiple AppleTalk ports in a single network will be configured with the same network number or range.
For a router in Transition Mode (for a description of Transition Mode, see Transition Mode Routing), make sure that these conditions are true:
NOTE: One of the most effective ways to insure against mismatched network numbers or conflicting zone names is to take advantage of seed routing when you configure your internetwork. For more information about seed routing and its benefits for configuring your internetwork, see Learning Network and Zone Configurations from Seed Routers.
The most common reason for this error condition is a conflicting AppleTalk configuration on the internet, but this error can also derive from low memory conditions or a Chooser limitation on the number of devices that can be visible. If you are seeing this symptom at Macintosh clients, load the ATCON utility at the server console and check the system log. If the system log contains messages about mismatched network numbers, refer to Symptom: Messages about Mismatched Network Numbers for additional information. If the system log contains messages about low memory, see AppleTalk Stack/Router Memory Requirements. If the system log does not contain AppleTalk error messages, the problem could be caused by too many device names (or device names that are too long) in the Chooser. The exact limitation in the Chooser depends on the number of characters in each device name. To fix this problem, you can either divide the AppleTalk network into zones containing fewer services (LaserWriters or file servers), or reduce the number of characters in some or all of the device names. If additional zone names show up in the Chooser or ATCON after you have brought up a file server on the AppleTalk network, check that these conditions hold in the NetWare for Macintosh v3.12 router configuration: Zone names are case-sensitive, and variations in case in the same words will result in different zone names. This can occur when you create individual ATZONES.CFG files for different routers in the internetwork. It can also occur when you have inconsistent AUTOEXEC.NCF files for the routers in your internetwork.
Trailing blanks in zone names could exist on other routers, if not on the current router that you are checking. Because space characters are permitted in zone names, these must also be checked.
Special characters that are allowed in zone names are shown in Table 27.
AppleTalk Solutions on the NetWare Server
Loader cannot find public ...Network Cabling Solutions
T-connector Connecting to a Macintosh
Symptom: Reconfigured Zones Continue to Show in the Chooser
Symptom: Messages about Mismatched Network Numbers
Consistent Network Numbers on an Internet
Symptom: Device Names Appear and Disappear in the Chooser
Symptom: Zone Names Do Not Match Existing Zone Names
Table 27. Decimal Codes for Eight-bit Character Mapping in AppleTalk
| Character | Value | Character | Value | Character | Value |
|---|---|---|---|---|---|
Ä |
128 |
(Dagger) |
160 |
[iquest] |
192 |
Å |
129 |
° |
161 |
[iexcl ] |
193 |
Ç |
130 |
(U.S. Cent) |
162 |
[not ] |
194 |
É |
131 |
(U.K. Pound) |
163 |
|
195 |
Ñ |
132 |
[sect ] |
164 |
f |
196 |
Ö |
133 |
|
165 |
|
197 |
Ü |
134 |
[para ] |
166 |
|
198 |
á |
135 |
ß |
167 |
[laquo ] |
199 |
à |
136 |
® |
168 |
[raquo ] |
200 |
â |
137 |
© |
169 |
... |
201 |
ä |
138 |
TM |
170 |
(blank) |
202 |
ã |
139 |
|
171 |
À |
203 |
å |
140 |
¨ |
172 |
à |
204 |
ç |
141 |
|
173 |
Õ |
205 |
é |
142 |
Æ |
174 |
OE |
206 |
è |
143 |
Ø |
175 |
oe |
207 |
ê |
144 |
|
176 |
- |
208 |
ë |
145 |
|
177 |
--- |
209 |
í |
146 |
<= |
178 |
" |
210 |
ì |
147 |
>= |
179 |
" |
211 |
î |
148 |
(Yen) |
180 |
` |
212 |
ï |
149 |
|
181 |
' |
213 |
ñ |
150 |
|
182 |
/ |
214 |
ó |
151 |
|
183 |
|
215 |
ò |
152 |
|
184 |
|
216 |
ô |
153 |
|
185 |
(Apple) |
240 |
ö |
154 |
|
186 |
|
|
õ |
155 |
[ordf ] |
187 |
|
|
ú |
156 |
[ordm ] |
188 |
|
|
ù |
157 |
|
189 |
|
|
û |
158 |
æ |
190 |
|
|
ü |
159 |
ø |
191 |
|
|
You can enter the characters shown in Table 27 in the ATZONES.CFG file by using any text editor that lets you enter numerical character codes; for example, you can use the editor called by the INSTALL module, the EDIT NLM, or the EDLIN text editor on a DOS client.
In EDLIN, you can enter these special characters by holding down <Alt> and entering the decimal value for the character. (Note that the character that displays on the screen of the DOS client does not look like the Macintosh character above. However, the specified decimal value matches the Macintosh character in existing zone names.)
This symptom is not a problem. ATPS always advertises its print queues in the zone of the internal network, or if multiple zones are configured on the internal network, it advertises print queues in the default zone or a specified zone of the internal network. The printers themselves appear in the zone configured for the LocalTalk network to which they are physically connected.
For example, Figure 65 shows an internet where there is one LaserWriter in the LocalTalk1 zone and two LaserWriters in the LocalTalk2 zone. Both file servers have the zone name Backbone for their internal network:
Figure 65
Spoolers and Printers in Different Zones
In this case, the print queues supported on both of these servers appear in the Backbone zone in the Chooser, while the individual LaserWriters appear in the LocalTalk1 and LocalTalk2 zones.