dns qry class always nil?

Question

hello,

I'm attempting to write a Lua tap to grab DNS info from some pcap files using tshark. I have one problem: every approach I've tried to get the dns.qry.class or dns.resp.class entities returns nil, even on packets that I know are dns packets (dns.qry.name, for example, isn't nil).

Example code:

local class = Field.new('dns.qry.class')
function init_listener()
    local tap = Listener.new("ip")
    function tap.packet(pinfo,buffer, ip)
        if class() == nil then
           debug('class is nil')
        end
    end
end
init_listener()

That bit of code always finds that the qry class is nil. I've tried downloading the nightly build of wireshark also, but that's giving me the same result. Does anyone have hints as to what I'm doing wrong here, or is there a bug in tshark's lua interface?

Answer 1

This is a bug either in the Lua interface or in the DNS dissector [which should probably be reported].

I recreated your symptom using the DNS sample capture. The interesting thing is that Wireshark knows which packets contain dns.qry.class, as indicated by the packet results after entering this field name into the Display Filter Textbox. So, one would think Lua would have the same benefit but apparently not.

For some reason, the same Lua tap can detect dns.qry.class in the mDNS sample capture. To me, this suggests that the mDNS dissector might be doing something necessary for the Lua tap to work properly, and the DNS dissector isn't doing that.

Answer 2

It's a deficiency of the field specification in Lua. It uses the display filter string as identification of the field. But there's no guarantee of uniqueness of this string for each individual field.

If you look in the DNS dissector there are two fields using this filter string: hf_dns_qry_class and hf_dns_qry_class_mdns. The Lua script uses the latter, which isn't assigned a representation with your capture. It does get assigned one with the mDNS sample capture.