Lua display filter in Listener.new

asked 2020-08-10 13:20:55 +0000

TomLaBaude
112 ●22 ●29 ●41 https://debookee.com

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 flag offensive close merge delete

Comments

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 ?

TomLaBaude ( 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 
F   Bad checksum    wlan.fcs.bad_checksum   FT_NONE wlan        0x0 
F   Bad FCS radiotap.flags.badfcs   FT_BOOLEAN  radiotap    8   0x40    Frame received with bad FCS

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

add a comment

answered 2020-08-10 15:57:35 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

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"
wlan.fcs.bad_checksum    Expert    Presence/Absence    wlan.fcs.bad_checksum
radiotap.flags.badfcs    Normal    Comparison          radiotap.flags.badfcs == 1

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.

edit flag offensive delete link

Comments

Thanks a lot for your detailed answer.

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 ?

TomLaBaude ( 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...

TomLaBaude ( 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)

cmaynard ( 2020-08-10 18:01:17 +0000 )edit

add a comment

Lua display filter in Listener.new

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Lua display filter in Listener.new edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Lua display filter in Listener.new