1 / 14

The Technology Firm

The Technology Firm. How to use Triggers and make troubleshooting easier. With Sniffer Pro 4. Thursday, December 14, 2000. Biggest Issue when Sniffing.

kieran-fletcher
Download Presentation

The Technology Firm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Technology Firm How to use Triggers and make troubleshooting easier. With Sniffer Pro 4 Thursday, December 14, 2000

  2. Biggest Issue when Sniffing The toughest challenge when running a protocol analyzer and waiting for a problem to happen is that you usually don’t know when the problem is going to happen. A way to deal with this is to use a remote protocol analyzer so that the analyst doesn’t have waste time sitting at the customer site waiting. But there is still the strong possibility that the problem will occur when the analyst goes home, lunch or whatever reason. So here is a way to leverage Triggers to have the client stop the Sniffer remotely and simply when the problem occurs. When using triggers you have to ensure that it is precise enough that it doesn’t meet generic criteria and accidentally ‘go off’. In this case, I want something totally unexpected to set off this trigger. So I typically choose this scenario; “The Client clicks a Desktop Icon which attempts to Telnet into the remote analyzer. This failure becomes the trigger for the Sniffer to stop capturing. So now, the client has a mechanism to stop the Sniffer when the problem happens.

  3. Gather Your Info. When creating this Telnet trigger, I try to document the following: The IP of the remote Analyzer. The TCP source port 25. The RST Flag indicating it refused the connection. So I captured the session failing for my documentation. Now that I have a failed connection attempt, I can design my trigger.

  4. Information Summary Since the IP address and Port number are fairly obvious, I won’t bother spending any more time on these topics. I will spend a few minutes explaining how to create this filter entirely from a Data Pattern perspective. You can set triggers based on many criteria, but in this case I will use a Pattern Match.

  5. Pattern Match Summary Since the IP address and Port number are fairly obvious, I won’t bother spending any more time on these topics. I will spend a few minutes explaining how to create this filter entirely from a Data Pattern perspective. In summary my Pattern Match looks this:

  6. Step 1: Select RST frame and Define Filter Name Go find the RST frame from the DSS. This can be done relatively easily by Searching for the test RST in the Summary field. When you find this frame, get ready to define a Capture Filter called ‘Telnet RST’.

  7. Step 2: Go to Data Pattern. The criteria for us was predefined back in the beginning. Now we have to locate this information to build our criteria list. From the screen below, select Add Pattern.

  8. Step 3: Define IP Source Address Pattern. Start with the IP address. Scroll down the decode screen until you find the Source IP address and check on the icon to the left of the IP classifier. Then select Set Data to paste these values. Then Click OK

  9. Step 4: Define TCP Port Address Pattern. After clicking OK ensure that the top most level is selected before moving on. Select Add Pattern and Scroll down the decode screen until you find the Source TCP address and check on the icon to the left of the TCP classifier. Then select Set Data to paste these values. Then Click OK

  10. Step 5: Define TCP RST Pattern. After clicking OK ensure that the top most level is selected before moving on. Select Add Pattern and Scroll down the decode screen until you find the TCP RST and check on the icon to the left of the TCP classifier. Then select Set Data to paste these values. Then Click OK twice.

  11. Step 6: Test your Filter. After creating any kind of filter, you must test it. Mistakes happen. Select the Telnet RST Filter, start a capture and attempt to Telnet to your remote analyzer. You should notice that you captured a few packets after the failure by referencing the Packet Capture counter. If this test failed, go back and check your previous steps to ensure they were done properly.

  12. Step 7: Defining Your Trigger. Go to Capture and select Trigger Setup. In this case we want to define a Trigger, based on our Filter to stop the Sniffer. • Select Stop Trigger/Enable. • Choose your filter name from the list. • Choose the number of packets you would like captured after the trigger ‘goes off’. • Click OK • There are obviously many things we could choose but this is fine for now.

  13. Step 8: Test Your Trigger. If everything went well, you should notice the following ICON at the bottom of your screen. Start a new Capture - With no Filters. Ping something to generate a few packets Telnet to your remote target. Ping something to generate a few packets. You should have noticed that the stop button is now grayed out. If so, great you’re good to go.

  14. Step 9: Trigger the Trigger. Now all we do is go to the customer site and add the following Telnet command as an icon. telnet 10.10.10.120 Give the icon a representative name like STOP SNIFFER. So when the client experiences the problem, the click the icon to stop the Sniffer. And again don’t forget to TEST, TEST, and TEST some more. Enjoy

More Related