Wireshark · Wireshark-dev: Re: [Wireshark-dev] lua and ss7 mtp2

[Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>]

This email is getting long - sorry bout that.


On Mar 18, 2013, at 6:24 AM, Cristian Constantin <const.crist@xxxxxxxxxxxxxx> wrote:

> cristian: even when the packet filter looks like this:
> 
> tap = Listener.new(nil, "mtp2 && isup")
> 
> ??
> 
> the script prints the 'nil' for all the packets in the capture.


Oh, no it shouldn't do that if your Listener was created with that specific filter, because every "mtp2 && isdn" packet has a "mtp2.li" field.  Sorry, I assumed you just created a default Listener (ie, did Listener.new()).

Right, so it's a different problem.  See below for the cause...


>> Another possibility is that you're parsing an Annex A MTP2 packet, or you have "Use extended sequence numbers" enabled for the "mtp2" protocol in your Wireshark preferences.
> 
> cristian:  "Use extended sequence numbers" is NOT checked in the ws preferences.
> as far as "Annex A MTP2" goes I cannot tell much since I am not an
> hardcore ss7 expert.
> I can tell you that when I look with ws at the packet I see that MTP2 has:
> 
> - one byte Backward seq. no + indicator bit
> - one byte Forward seq. no + indicator bit
> - one byte Length indicator + 2 bits spare
> 
> how can one actually tell if this is "Annex A" or not?

Heck if I know - I'm no expert in the mtp2 dissector either - just telling you what it appears to do. :)
It looks like it determines if it's a annex-a or not from either the preferences, or from the mtp2 pseudo-header, not from a bit in the on-the-wire header itself though.
So maybe it can only know it's an annex-a if the pcap file had it that way (used a "MTP2 with pseudoheader" encoding for the frames).

Anyway, in your case it's just a normal one, not annex-a.
And it turns out that's the problem - or rather, it turns out that when it's *not* an annex-a, it's going to be nil every time, which is obviously a bug.
See below for the cause...


>> In that case, I think it may be possible your mtp2_len field will always be nil, because there are *two* "mtp2.li" fields really: one using 8-bit numbering, and a second using 16-bit numbering.  Internally they're really two separate fields, and which one gets populated depends on whether the packet is an Annex A or not, or if the preferences dictate it or not.
>> When you do this:
>>    local mtp2_len = mtp2_li_field()
>> I'm pretty sure Wireshark will correctly return the appropriate one as the one and only value; but it's possible it is returning either just nil because the first one is not filled in, or it's returning both - and if it's returning both, then setting the value of variable 'mtp2_len' to the first returned value from 'mtp2_li_field()' means you're getting the 8-bit one and thus probably nil.

So apparently I'm wrong... well, sorta wrong - there are two 'mtp2.li' fields as I said, but it appears that the Lua code will unfortunately return nil if the "first" one is not filled in, and the "first" one in this case happens to be the second 'mtp2.li' field, namely the 16-bit extended annex-a one.  I had assumed the second field of the same name would be second in the lookup tree, but apparently it replaces the previous one's spot and the previous one gets attached to it, so effectively the 16-bit mtp2.li field is the first one found.  Since your packets aren't annex-a, that mtp2.li field is empty, and the code pushes back a nil into Lua.

ISTM that's a bug.  The code should walk through all fields of the same name, and push back the values of any it finds populated, into Lua.


>> For example:
>> function tap.packet(pinfo, tvb)
>>    local mtp2 = mtp2_field()
>>    local mtp2val = mtp2 and mtp2.value  -- gets the value if mtp2 is not nil/false
>>    if mtp2val then
>>        local l = mtp2val:get_index(3)   -- gets the decimal number of third byte
>>        print("The third byte of the mtp2 protocol section is: " .. l)
>>    end
>> end
>> 
> 
> cristian: this one actually works. anyway, it looks like the indexing
> starts at 0 and the length is  mtp2val:get_index(2) though.

That's unfortunate - Lua's indexing starts at 1, so the code should follow that behavior instead of using C's index numbering; oh well, too late to change it now for that function.

-hadriel