# Lua display filter in Listener.new

I'm upgrading my wlan monitoring Lua scripts back from v2.0.0 (ping @cmaynard who helped me a lot at this time) as some display filters have changed.

Old script started with :

local wlan = Listener.new("wlan", "wlan.fcs_good == 1")


Changed to

local wlan = Listener.new("wlan", "wlan.fcs.status == 1")


Simply changing this, my callback function wlan.packet(pinfo,tvb,tapinfo) is never called.

I changed to :

local wlan = Listener.new("wlan", "radiotap.flags.badfcs == 0")


and my callback is working great directly, so it seems to be linked with this very special display filter.

Am I doing something wrong with it or it looks like a bug ?

edit retag close merge delete

Using Wireshark 3.2.5

I realized that preparing a filter, Wireshark doesn't use a boolean but a string ton wlan.fcs.status -> wlan.fcs.status == "Good"

I tried local wlan = Listener.new("wlan", 'wlan.fcs.status == "Good"'), but it didn't work neither.

Could it be linked to a boolean/string field value stuff ?

( 2020-08-10 13:26:16 +0000 )edit

I discovered also wlan.fcs.bad_checksum but it's type is not a boolean, but FT_NONE... Not sure how to use it...

radiotap.flags.badfcs is a boolean.

To sum-up: Why wlan.fcs.status == 1 works in GUI but not in Lua (without errors)

How to use wlan.fcs.status / wlan.fcs.bad_checksum if there are not booleans ? (And what are their differences...)

F   Frame check sequence    wlan.fcs    FT_UINT32   wlan    BASE_HEX    0x0 Frame Check Sequence (FCS)
F   FCS Status  wlan.fcs.status FT_UINT8    wlan    BASE_NONE   0x0

( 2020-08-10 13:39:19 +0000 )edit

Sort by » oldest newest most voted

I think you've stumbled upon Bug 8859 - Apply consistent naming convention to checksum display filter fields and expert info..

I think the basic problem you're experiencing is due to fields that are only part of the Expert category. These fields are either present or absent and don't contain a value per se. So while you can test for the existence of Expert Info fields such as wlan.fcs.bad_checksum, you can't test for it having a particular value, i.e., wlan.fcs.bad_checksum == 1. The bigger problem here is, "How is the user supposed to know which fields are Expert only fields where you can only test for presence/absence, and which fields are normal fields where you can perform comparisons against specific values?". Of course one can always check the source code of packet-ieee80211.c, but that's not the most user-friendly method. The online display filter reference page does list these types of fields as a Label, so that is a clue, but I don't think that's entirely obvious to users either. Perhaps as a part of the resolution to Bug 8859, improvements could be made in this area too, although the issue isn't restricted to checksum-related fields but rather to all expert fields, so perhaps a new bug should be filed with the problem being that it's unclear how to use "Expert" fields vs so-called "Normal" fields.

So, to summarize:

FIELD                    TYPE      TEST                EXAMPLE
wlan.fcs                 Normal    Comparison          wlan.fcs == 0xa2619a02
wlan.fcs.status          Normal    Comparison          wlan.fcs.status == "Bad"


NOTE: "Normal" fields can also be tested for presence/absence too.

Lastly, you mentioned, "Why wlan.fcs.status == 1 works in GUI but not in Lua (without errors)". Does it? It doesn't work in the GUI for me. I mean, it's accepted as a valid filter, but it doesn't really achieve the desired result. Instead, you need wlan.fcs.status == "Bad" for that.

more

I've rechecked that on macOS, wlan.fcs.status == 1 works exactly as wlan.fcs.status == "Good"

So, if I understood correctly, my test with local wlan = Listener.new("wlan", 'wlan.fcs.status == "Good"') should have worked, but it did not.

Could it be a matter of quote in my code ? Or maybe another bug hiding there ?

( 2020-08-10 16:17:27 +0000 )edit

For Bug 8859, a simple yellow color with a warning specifying that it's an expert filter would be simple and already super 'warningful' for the user.

As far as you know, was it evoked as a solution ? Bug speaks about "color filter", but not sure it's related...

( 2020-08-10 16:23:32 +0000 )edit

You're right regarding the use of wlan.fcs.status. I misinterpreted 1 as "Bad" and 0 as "Good" and thought a 1 would indicate that the status was bad and 0 would indicate that the status was good. The field name itself isn't particularly well-named; the old filter wlan.fcs_good with values of 0 or 1 was much clearer, in my opinion.

Well, getting back to the problem with neither of these working for you:

local wlan = Listener.new("wlan", "wlan.fcs.status == 1")
local wlan = Listener.new("wlan", 'wlan.fcs.status == "Good"')


Maybe try this?:

local wlan = Listener.new("wlan", "wlan.fcs.status == \"Good\"")


If that doesn't work, then perhaps the problem may be related to the base for this field, namely BASE_NONE, although README.dissector specifically indicates that this is valid and intentional:

                  BASE_NONE may be used with a non-NULL FIELDCONVERT when the
numeric value ...
(more)
( 2020-08-10 18:01:17 +0000 )edit