Previous | Table of Contents | Next |
Lets travel back to Hour 18, Lots of Different People in Your Neighborhood: In-depth Application Troubleshooting, to the problem in the I Cant 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 printera 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 servers 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/IPhad 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 hostqueue1 and queue2one 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 thats not brain dead. (Although the vendor didnt 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 vendorso 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:
Ive been at sites where the MAC addresses werent terribly well documented, so any MAC-related error was difficult to run down. For example, suppose Windows exclaims that theres a duplicate TCP/IP address on MAC address 00:00:C9:05:89:62. It doesnt do a troubleshooter a lot of good if the MAC addresses arent documented, and if your analyzer doesnt automatically identify network names for you, you might think youre 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 problemyouve got a wiretap! You can listen in to all the MAC traffic generated by this workstation, and its likely that youll 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 workstations user (or department).
This is something that takes a little practice, but use your head and youll get good at it in no time. For example, filtering on Telnet sessions will give you the entirety of a users Telnet. Go to the beginning, and youll 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 youre filtering on TCP sessions, look for a SYN packet. This is the beginning of a TCP sessionthe equivalent of saying hello? when you first pick up the telephoneand it likely has the username in a nearby packet.
Previous | Table of Contents | Next |