Previous Table of Contents Next Application Antics Let's travel back to Hour 18, "Lots of Different People in Your Neighborhood: In-depth Application Troubleshooting," to the problem in the "I Can't Spool, Take Two" section. Remember that we had a UNIX host that would not spool more than one print job to a given network print server at one time, even if that print server had multiple printers attached to it. In other words, the host assumed that each print server only had one printer-a seriously wrong assumption! In this scenario, even though I had proved to myself that the host was at fault by using black box troubleshooting, I wanted evidence to submit to the vendor to prove that its stuff worked differently (wrongly) from other vendors' implementations of UNIX printing in order to try to force the vendor to fix it. It was fairly easy to take a trace of this by specifying a capture filter of the print server's MAC address or TCP/IP address. Why not the UNIX host? Because the UNIX host had hundreds and hundreds of users, all accessing it via TCP/IP-had I specified the UNIX host, I would have had a little more data than I could handle. I set up two test queues on the suspect host-queue1 and queue2-one for each printer on the print server. As a "control experiment," I set up the same two queues on another host. I started the analyzer capture, went back to my desk, and quickly printed two jobs to the two test queues. I went back to the analyzer, stopped the capture, and saved it to disk, giving it the filename problem. Then I did the exact same procedure, but used another host to print to the queues. I called this trace file good, because this capture illustrated what happens with a UNIX host that's not brain dead. (Although the vendor didn't immediately act, our salesperson saw that we acted on this objective data and bought something else, which had good long-term effects on our leverage with this vendor-so it was worth doing. In fact, when we started having more problems with the machine and implementation of UNIX, we were given a new machine in reparation.) Here are the important points to remember when submitting analyzer traces to a vendor: o Traces should be small. Filter as much as you can. o Traces should be discrete. As shown earlier, you should take several traces showing a "good" event versus a "bad" event. o Traces should be backed up with an objective and succinct description of the problem, describing what troubleshooting measures were taken. Identifying a Station I've been at sites where the MAC addresses weren't terribly well documented, so any MAC-related error was difficult to run down. For example, suppose Windows exclaims that there's a duplicate TCP/IP address on MAC address 00:00:C9:05:89:62. It doesn't do a troubleshooter a lot of good if the MAC addresses aren't documented, and if your analyzer doesn't automatically identify network names for you, you might think you're out of luck. Same goes for when your expert analyzer tells you that 00:08:02:55:29:2A is probably a bad network card and is causing many network errors. Hey, no problem-you've got a wiretap! You can listen in to all the MAC traffic generated by this workstation, and it's likely that you'll get something that will identify the user. By taking a look at the data in the hexadecimal or character-oriented decode window, you can see various data that might lead you to identify the workstation's user (or department). This is something that takes a little practice, but use your head and you'll get good at it in no time. For example, filtering on Telnet sessions will give you the entirety of a user's Telnet. Go to the beginning, and you'll get the login name. Check the middle data out, and you might see a report or a menu screen that only a particular user or department uses. This is a good opportunity to get good at reading your protocol decodes. If you have the time on a noncritical problem, you should go for it! ______________________________________________________________ If you're filtering on TCP sessions, look for a SYN packet. This is the beginning of a TCP session-the equivalent of saying "hello?" when you first pick up the telephone-and it likely has the username in a nearby packet. ______________________________________________________________ Previous Table of Contents Next