Filters

1. Row filter (what you look at)

The row filter narrows what the views display. It does not discard anything from the capture: clearing the filter brings the hidden frames straight back.

• Keyword, interpreted as hex, as ASCII or as a remark, depending on how you enter it.
• Direction (read, write or both).
• Port, so a multi-port capture can be read one device at a time.
• IRP or IOCTL, to isolate a single class of request.
• Protocol, to keep only the frames a plugin recognised.

Where a filter is applied, it is applied consistently: the redirect engine uses the same row-filter decision when deciding what to write to disk.

2. IRP filter (what the driver reports)

This one is configured per monitored port and is passed down to the kernel driver. It is a bitmap of 67 entries: 39 serial control codes and 28 IRP major function codes.

Only the requests whose bit is set are reported to the application. Narrowing this bitmap reduces the amount of data the driver has to deliver, which is the only filter that can make a capture cheaper rather than just quieter.

3. Working practice

• Start wide and narrow down: an over-tight IRP filter is the usual reason a capture looks empty.
• If you are hunting one byte pattern, filter the row and let the capture keep running rather than restarting it.
• Filters are saved with the session, so a capture can be reopened with the same view you left it in.