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

Problem while filtering frame[x] == ff (or fc)

0

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
1●1●1●2
accept rate: 0%

One Answer:

2

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:

answered 01 Dec '11, 07:22

cmaynard's gravatar image

cmaynard ♦♦
9.4k●10●38●142
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 ♦♦