# Wait for Response Packets

## Contents
Overview Packet Sniffer Configuration Sniffing Response Packets

## Overview
Packet Sniffers are a type of Passive Service. Rather than opening up a TCP port and actively listening for requests, the Packet Sniffer passively reads data packets off the network interface. The Sniffer assembles these Packets into complete messages that can then be passed into an associated policy. Because the Packet Sniffer operates passively (does not listen on a TCP port) and transparently to the client, it is most useful for monitoring and managing Web Services. For example, you can deploy the Sniffer on a machine running a Web Server acting as a container for Web Services. Assuming that the Web Server is listening on TCP port 80 for traffic, the Packet Sniffer can be configured to read all packets destined for port 80 (or any other port, if necessary). The packets can then be marshaled into complete HTTP/SOAP messages by the Sniffer and passed into a policy that, for example, logs the message to a database.
## Packet Sniffer Configuration
Because Packet Sniffers are mainly used as passive monitoring agents, they are usually created in their own Service Group. For example, you can create a new group for this purpose by right-clicking the Process on the Services tab in the Policy Studio, selecting Add Service Group, and the entering `Packet Sniffer Group` on the Add Service Group dialog. You can then add a Relative Path Service to this Group by right-clicking the `Packet Sniffer Group`, and selecting Add Relative Path. Enter a path in the field provided, and select the policy that you want to dispatch messages to when the Packet Sniffer detects a request for this path (after it assembles the packets). For example, if the Relative Path is configured as `/a`, and the Packet Sniffer assembles packets into a request for this path, the request is dispatched to the policy selected in the Relative Path Service. Finally, you can add the Packet Sniffer by right-clicking the `Packet Sniffer Group` node, selecting Packet Sniffer -> Add. Complete the following fields on the Packet Sniffer dialog: Device to Monitor: Enter the name or identifier of the network interface that the Packet Sniffer monitors. The default entry is `any`, but it is this is only valid on Linux. On UNIX-based systems, network interfaces are usually identified using names like `eth0`, `eth1`, and so on. On Windows, these names are more complicated (for example, `\Device\NPF_{00B756E0-518A-4144 ... }`). Filter: You can configure the Packet Sniffer to only intercept certain types of packets. For example, it can ignore all UDP packets, only intercept packets destined for port 80 on the network interface, ignore packets from a certain IP address, listen for all packets on the network, and so on. The Packet Sniffer uses the libpcap library filter language to achieve this. This language has a complicated but powerful syntax that enables you to filter what packets are intercepted, and what packets are ignored. As a general rule, the syntax consists of one or more expressions combined with conjunctions, such as `and`, `or`, and `not`. The following table lists a few examples of common filters and explains what they filter:
Filter Expression | Description
`port 80` | Captures only traffic for the HTTP Port (i.e. 80).
`host 192.168.0.1` | Captures traffic to and from IP address 192.168.0.1.
`tcp` | Captures only TCP traffic.
`host 192.168.0.1 and port 80` | Captures traffic to and from port 80 on IP address 192.168.0.1.
`tcp portrange 8080-8090` | Captures all TCP traffic destined for ports from 8080 through to 8090.
`tcp port 8080 and not src host 192.168.0.1` | Captures all TCP traffic destined for port 8080 but not from IP address 192.168.0.1.
The default filter of `tcp` captures all TCP packets arriving on the network interface. For more information on how to configure filter expressions like these, see the tcpdump man page. Promiscuous Mode: When listening in promiscuous mode, the Packet Sniffer captures all packets on the same Ethernet network, regardless of whether the packets are addressed to the network interface that the Sniffer is monitoring.
## Sniffing Response Packets
The Enterprise Gateway can capture both incoming and outgoing packets when it is listening passively (not opening any ports) on the network interface. For example, a Web Service is deployed in a web server that listens on port 80. The Enterprise Gateway can be installed on the same machine as the web server. It is configured not to open any ports and to use a Packet Sniffer to capture all packets destined for TCP port 80. When packets arrive on the network interface that are destined for this port, they are assembled by the Packet Sniffer into HTTP messages and passed into the configured policy. Typically, this policy logs the message to an audit trail, and so usually consists of just a Log Message filter. Assuming that you also want to log response messages passively, as is typically required for a complete audit trail, you can use the Wait for Response Packets filter to correlate response packets with their corresponding requests. The Wait for Response Packets filter assembles the response messages into HTTP messages and can then log them again using the Log Message Payload filter. The following circuit logs both request and response messages captured transparently by the Packet Sniffer:
Circuit to log both request and response messages after capturing messages passively using the Packet Sniffer
You can see from the circuit that the first logging filter logs the request message. By this stage, the Packet Sniffer has assembled the request packets into a complete HTTP request, and this is what is passed to the Log Request Message filter. The Assemble response packets filter is a Wait for Response Packets filter that assembles response packets into complete HTTP response messages and passes them to the Log Response Message filter, which logs the complete response message. More information on the Log Message Payload filter is available in the Log Message Payload topic.