This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I can't filter displayed frames where specific byte is equal ff or fc (eq. frame[4] == ff), the filter sequence is not allowed, filter window turns red. Any solution, please?

asked 01 Dec '11, 02:12

Jenda%20Nespor's gravatar image

Jenda Nespor
1112
accept rate: 0%


The problem is because both fc and ff are filters on their own, for "Fibre Channel" and "FOUNDATION Fieldbus", respectively. You should be able to work around it using frame[4] == ff:

permanent link

answered 01 Dec '11, 07:22

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

edited 01 Sep '16, 06:48

Good to know. Still I think this behavior is a little strange to work with; isn't it possible to look at fc and ff as values instead of as filter names?

(01 Dec '11, 07:56) Jasper ♦♦

Well, it's only a problem for single bytes. If you were searching for 2 (or more) bytes, then frame[4:2]==ff:fc would work just fine without the trailing colon.

But I do agree with you, and I think there is very likely a bug here since the display filter parsing doesn't support display filters on the right-hand side of a comparison operator anyway, at least as far as I'm aware, so it shouldn't be trying to match a filter here. You might want to file a bug report about this.

(01 Dec '11, 09:03) cmaynard ♦♦

It's a bit more complex. You talk about a "filter" above but I guess what you exactly had in mind was a filter primitive, like tcp or ip.addr == 1.1.1.1. As any field name may be used alone as a filter primitive (which makes true if that field is present in the frame, regardless what is its value and whether it has a value at all), the preference between interpretation of [a-f][0-9a-f] strings as hexadecimal values or filter primitives would at least have to take into account whether the field bearing the name has a value or not. A display filter wlan.ta == wlan.sa does work and is useful in some cases, so blindly giving priority to the hexadecimal constant over field name interpretation at the right side of comparison operators could cause other issues. But doing it this way would just make the issue better hidden - if I assign to a protocol field which has a value a name like "ab", omitting the protocol name (like some dissectors do), I'll bump into the same wall again.

(01 Sep '16, 07:19) sindy

You might want to file a bug report about this.

FYI: Stig has recently filed bug 12810 for this.

(01 Sep '16, 08:11) cmaynard ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×349
×63
×41

question asked: 01 Dec '11, 02:12

question was seen: 3,757 times

last updated: 01 Sep '16, 08:11

p​o​w​e​r​e​d by O​S​Q​A