Observer Analyzer : Analyzer : Filtering : Pre-filtering your packet captures
Pre-filtering your packet captures
Page Contents
Tell me how to filter by protocol
Tell me how to filter by pattern
Activating and deactivating filters
How to chain filter rules using logical operators
Revised: 2018-03-29
By filtering your packet captures, you can extract and examine only network packets that meet certain criteria. You can introduce such a filter either before (pre-filter) or after (post-filter) you perform a packet capture.
When you pre-filter your packet captures, you have two choices. You can choose to use a software pre-filter or a hardware pre-filter.
Some countries or locales have laws regarding data privacy and strictly regulate what information may be captured. Failure to abide by these laws could result in fines or jail time. This means that if you are troubleshooting an issue for a specific user you may not be able to create a generic filter. Instead, you must create a filter that captures only traffic for that individual. If you need to be very specific about what you capture, we recommend a hardware filter with a pattern filter. If it is necessary to filter multiple levels of VLAN tags, use an offset to find the necessary location in the packet payload.
Caution: Failing to click OK in step 8 causes Observer to discard any and all changes made since the Active Filters window first appeared in step 1, including all filters you may have created during that period of time.
This section describes pre-filters only; these filters affect what your future packet captures record. If you have an existing capture file and would like to post-filter it instead, see Post-filtering your packet captures.
To create and apply a pre-filter, complete the following steps:
1. Choose one of the following to create your filter.
On the Home tab, in the Probe group, click Filters > Configure Software Filter.
On the Home tab, in the Probe group, click Filters > Configure Hardware Filter.
2. Click New Filter.
The New Filter dialog appears.
3. Type a name for your new filter, and click OK.
The Edit Filter window appears.
4. Use the editor to create a filter.
The maximum number of elements a filter expression may have is 256.
See Tell me more about modifiers for a list of rules, types, and their usage.
5. Click OK to confirm your changes.
Your new filter appears in the Active Filters window.
6. (Optional) To exclude, negate, or do the inverse of what you just defined, select the rule, right-click and choose Toggle Include/Exclude on rule.
(Optional) When you exclude a rule, a diagonal red line crosses through it.
7. (Optional) Activate your new filter by enabling it from the list.
8. Click OK to save your changes.
Your newly created filter is available to use when capturing packets.
Tell me how to filter by protocol
Observer’s Protocol Data Field filter rule lets you search for specific values in selected protocol header fields. For example, you can filter for ICMP destination unreachable packets and wireless control, data, and management packets. You can also define your own custom protocol filter, either by port or search pattern.
Figure 20: Protocol Filters
Click Add and give the protocol filter a descriptive name and choose whether you want to define the protocol by a pattern filter or a port filter. After you click OK, the appropriate filter dialog is displayed allowing you to enter the pattern or port that defines the protocol.
Tell me how to filter by pattern
Tip! For hexadecimal patterns, you must enter the two-character representation of each byte in the hex pattern, with a SPACE between. For the example above, telnet is on port 23, which is represented as 00 17 in hex. Note the SPACE between the 00 and the 17. For binary patterns, you must enter each byte as two 8-position bit strings separated by a space (for example,10011101 11001100).
When defining a Pattern rule, you can enter a specific offset from the beginning of a packet header (or from the beginning of a protocol’s header), and a specific pattern or data sequence to search for after that offset.
The offset is the decimal position to start looking for the sequence, in the byte order you specify (Big Endian or Little Endian, or most significant bit first or last, respectively). Enter the offset as a decimal value. If you select Search Using Range you can enter an ending offset beyond which the filter will not search for the pattern. You can also make the search case sensitive or insensitive.
The pattern itself is the actual ASCII, Regular Expression, Hex or Binary string that you are filtering for.
Figure 21: Pattern Filter
For example, to define an offset-sequencing filter to look for telnet packets (i.e., looking for TCP port 23) in one direction, the offset would be 34 (14 bytes of Ethernet header + 20 more bytes of IP header) and the hex pattern would be 00 17 (23 in hex).
To create a Hex Pattern rule for telnet in both directions, you could first tell Observer you want to start the offset at the IP-TCP protocol portion of the header (specify IP-TCP in the Protocol dialog), then tell Observer that you want the first offset to start immediately (port number is the first field after the TCP header) by entering 0 in the first offset field and 00 17 in the first Offset Filter area. This will filter for telnet packets in the direction of source to destination. To see the telnet response packets, you should enter a second offset (in the same dialog) for offset 2 and with a value of 00 17. The second offset specifies the destination port (this is the reason for the offset of 2).
Table 10. Rules types
Rule Type
Address - IP Range/IP
Specify a hardware or IP address or range of addresses for source and destination. You can also limit the rule to apply only to packets from particular source or destination ports. For IPv4 packets, you can specify a subnet mask for inclusion/exclusion.
Packets with Comments
Filter for packets that have been commented by an Observer user and saved with a capture file. Comments are useful for annotating packets when two analysts are working on a problem together, perhaps sending each other captures from remote sites on a corporate network. There are no setup options. Available for post-filter only.
Specify the categories of errors you want to filter for: CRC, Alignment, packet to small, and packet too large are available for all network types. You can also filter for Wireless WEP errors if you are analyzing a wireless network. If you are analyzing a WAN link, you can filter for WAN abort and RBIT errors. Observer also lets you filter for Token Ring error notifications when analyzing Token Ring networks.
Ethernet Physical Port
Allows you to filter on the physical port or link of the Ethernet capture card. When choosing to filter by link, you can also choose the direction (DCE or DTE).
Expert Packets
This rule lets you filter for Observer -generated Expert packets. These packets will only be generated if the Include Expert Load information packets box has been checked in Mode Commands Setup for Packet Capture. There are no setup options. Available for post-filter only.
Full Duplex Ethernet Port
Lets you filter for direction (DCE or DTE) on a selected full-duplex port.
Length (Bytes)
Specify a packet length, and whether you want to filter for packets that are less than, equal to, or greater than that length. You can also filter for packets that fall within a range of length values.
The MPLS filter allows you to filter on any level of the MultiProtocol Label Switching protocol.
Numeric Value
This rule is useful when you need to filter for a numeric value (or range of values) that is embedded within a byte, word or double word.
Packet Time
Allows you to create a capture file with packets only before, after, or during a specific time. This filter is only available for pre- and post-filtering.
Partial Packet Payload for TCP/UDP
Allows you to capture (or not capture) specific payload data based on how the rule is configured. This is especially useful if you need to share packet captures. See Sharing packet captures with third-parties
Use this rule to filter an ASCII, Regular Expression, hexadecimal, or binary string starting at specified offset or within a specified range. Hexadecimal and binary strings allow you to filter for values embedded within a particular byte, word, or double word if you know the offset, either from the beginning of the packet, or from the beginning of a particular protocol header. If you want to filter for numeric value or range of values within a byte or word, consider using the numeric value filter. Regular Expression filters allow you to use Unix/Perl-style regular expressions, which let you wildcard for single characters, groups of characters, ranges of characters and numeric values, and more.
Specify a port or range of ports for inclusion or exclusion.
Select a protocol and field to filter on. For example, you can filter for ICMP Destination unreachable messages, or the presence of a VLAN tag.
VLAN 802.1Q
Match specific tag values for a Virtual Local Area Network (VLAN). You can filter on VLAN ID, priority (or a range of priorities) and the canonical format indicator. You can also filter for packets that contain any VLAN tag regardless of values.
VLAN ISL (Cisco proprietary VLAN). Beyond the VLAN ID, you can filter by user-defined bits.
Source address (MAC):
CDP and BPDU indicator:
High bits of source address:
Port index:
Reserved field:
Allows you to define the direction, loop, DVIF, and SVIF for tags created by the vNIC in your virtual network.
WAN - DLCI Address
Specify a WAN DLCI by number.
WAN Port
Specify a WAN Port by number.
WAN Conditions
Lets you filter for direction (DCE or DTE or both), and logically chain tests for forward congestion packets, backward congestion packets, and discard eligibility.
Wireless Access Point
Enter or select a hardware address that corresponds to the wireless access point you want to capture traffic from.
Wireless Data Rate
Select a wireless data rate, and whether you want to filter for packets traveling at, under, or over that rate.
Wireless Channel
Select a wireless channel, and whether you want to filter for packets received from channels less than, greater than, or equal to that channel.
Wireless Channel Strength
Select a wireless signal strength, and whether you want to filter for packets received at, under, or over that signal strength.
Tell me more about regular expressions
Regular expressions provide a powerful method of building sophisticated search filters in which you can wildcard single characters, groups of characters, ranges of characters and numbers, and more. If you are familiar with Snort pattern-matching, you probably already have some familiarity with regular expressions.
The power of regular expressions comes from the ability to interpret meta-characters, which are a kind of programming code to specify search patterns. For example, in a regular expression, a period by itself means match any single character in this position. Suppose you want to find all references of the phone number 555-5155 in a large buffer filled with email traffic, for purposes of SOX audit. Depending on who typed the email, the number could be separated with the dash, a space, or even a period. You could search separately for all these versions of the phone number, or you could use the regular expression (the forward slashes enclosing the string identify it as a regular expression; these are optional unless you use modifiers).
Rather than providing a comprehensive definition or tutorial, this section gives a few short examples which are intended to give you an idea of the kinds of things you can do with regular expressions.

Which would match 555-5155, 555 5155,555.5155, etc. But it would also match 555X5155, 555B5155 etc. A more precise regular expression would be:

/555[ |-|\.]5155/
which demonstrates how to use the bracket and pipe ([x|y|z]) construct to search for any of a class of characters. This regular expression would only match 555-5155, 555 5155, and 555.5155. Note the slash in front of the period, which tells the filter to look for a literal period rather than interpreting the period as a meta-character. This use of the slash (interpret a meta-character as a literal character) is called slash-quoting.
Be careful with meta-characters. Consider the following regular expression:

This would match not only the IP address, but also any other string of digits that included the literal elements (i.e., non-meta-characters) in the string;

would all match. As noted before, to specify a literal period match, you must slash-quote the meta-character: To match only the IP address, use the regular expression

Tell me more about modifiers
The backslash not only turns meta-characters into literal characters, it is also used to give otherwise literal characters special meaning. In the Perl-compatible regular expressions supported by Observer, this includes modifiers or controls that affect the way the entire expression is interpreted. For example, regular expressions are case-sensitive unless you use the /i modifier:
/network instruments/i
Would match:
Network Instruments and NETWORK INSTRUMENTS and Network instruments
Table 11 lists the modifiers supported by Observer’s regular expression filters. For more comprehensive definitions of all the meta-characters supported by Perl-compatible regular expressions, see
Table 11. Modifiers
Make the search case insensitive.
Interpret the period (.) meta-character to include newlines.
By default, the string is treated as one big line of characters. ˆ and $ (two other meta-characters) match at the beginning and ending of the string. When \m is set, ˆ and $ match immediately following or immediately before any newline in the buffer, as well as the very start and very end of the buffer.
Whitespace data characters in the pattern are ignored unless escaped or inside a character class. This is useful for making long regular expressions more readable.
The pattern must match only at the start of the buffer (same as ˆ)
Set $ to match only after the subject string. Without E, $ also matches immediately before the final character if it is a newline (but not before any other newlines).
Inverts the greediness of the quantifiers so that they are not greedy by default, but become greedy if followed by a question mark (?). Greediness refers to how many characters it will consider when trying to match strings of variable length.
Activating and deactivating filters
Typically, an active (activated) filter narrows the scope of your packet captures according to that filters’ rules. For example, a filter that filters LDAP traffic—if active—causes only LDAP packets to be captured to the capture buffer. Furthermore, this effect is additive, meaning if you activate an additional filter, both filters’ rules apply to future captures using a logical OR expression.
Tip! While enabling filters narrows the scope of your future packet captures, you can broaden that scope by enabling more filters. Alternatively, consider creating a “negative” filter to ignore packets you do not want to capture, and use that instead.
Note: By activating more than one filter (if desired), all activated filters are linked together with a logical OR statement.
Also, if you apply a rule that is not relevant to your pre-filter or post-filter scenario, that rule is ignored.
1. On the Home tab, in the Probe group, click Filters > Configure Software Filter.
2. Browse the list of filters, and activate any filter by enabling it.
3. (Optional) Edit any filter by selecting it and clicking Edit Filter.
4. (Optional) If you want to deactivate all filters, activate the “Empty Filter” filter.
5. Click OK to save your changes.
All future packet captures now adhere to the rules of all active filters. When necessary, you can deactivate filters by disabling them during step 2. To deactivate all active filters simultaneously, activate the Empty Filter filter.
How to chain filter rules using logical operators
Sometimes you need more sophisticated rules to capture packets from several addresses that meet complex criteria.
For these kinds of situations, you can chain multiple rules together into a single filter using the logical operators AND, OR, and BRANCH. The filter rule editor arranges the rules according to where they fall logically in the decision tree that you are building when using multiple rules. Each rule is represented by a rectangle, ANDs are represented by horizontal connecting lines, ORs and BRANCHes are represented by vertical lines.
AND and OR mean exactly what you would think. For example, the following rule would cause Observer to include only CRC error packets that originate from IP (in other words, both the address rule AND the error rule must return positive for the packet to be captured).
Figure 22: AND filter example
If you want to capture traffic from along with any error packets regardless of originating station, you would chain the rules with OR:
Figure 23: OR filter example
BRANCH is somewhat like an OR, but if the packet matches the first rule in the branch, it is matched only against the rules that follow on that branch.
When you chain multiple rules in a filter, packets are processed using the first match wins method: If a packet matches an exclude in the filter, further processing through that particular string stops. However, the packet is still processed through any subsequent OR or BRANCH rules in the filter.