[Cristian Constantin <const.crist@xxxxxxxxxxxxxx>]

On Sat, Mar 16, 2013 at 11:46 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
>> From: Cristian Constantin <const.crist@xxxxxxxxxxxxxx>
>> Date: Fri, 15 Mar 2013 19:24:39 +0100
>>
>> I am trying to access from a lua script the length indictator field of
>> the mtp2 protocol.
>>
>> 1. yes, I am sure that the capture contains ss7 mtp2 traffic
>> 2. yes, I am sure that the filter selects the ss7 mtp2 traffic.
>> 3. I am using wireshark:
>>
>> wireshark -v
>> wireshark 1.8.2
>
> I suggest you upgrade to a newer Wireshark.  There were some bugs with Lua-based Fields which were fixed in newer releases, like 1.9.0.
> I don't think you've hit one of those bugs, but it may help you avoid hitting them in the future. :)

cristian: o.k. I have compiled the latest svn version with lua support
and I am using it now:

wireshark 1.9.1 (SVN Rev 48390 from /trunk)

Copyright 1998-2013 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.29.4, with
GLib 2.32.3, with libpcap, with libz 1.2.3.4, with POSIX capabilities (Linux),
without libnl, with SMI 0.4.8, with c-ares 1.7.5, with Lua 5.1, with Python
2.7.3rc2, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP,
with PortAudio V19-devel (built Jul 20 2011 00:01:38), with AirPcap.

Running on Linux 3.1.0-1-amd64, with locale en_US.UTF-8, with libpcap version
1.1.1, with libz 1.2.3.4, GnuTLS 2.12.19, Gcrypt 1.5.0, without AirPcap.
AMD Phenom(tm) II X4 940 Processor

Built using gcc 4.6.3.

>
>
>> does anyone here know why for example this snippet:
>>
>> local mtp2_li_field = Field.new("mtp2.li")
>>
>> function tap.packet(pinfo, tvb)
>>  local mtp2_len = mtp2_li_field()
>>  print("mtp2 len:", tostring(mtp2_len))
>>  print("mtp2 len:", tostring(mtp2_len.value))
>> end
>>
>> dumps something like:
>>
>> mtp2 len:       nil
>> [string "get_isup.lua"]:187: attempt to index local 'mtp2_len' (a nil value)
>>
>> ??
>
> A Lua Listener tap will be executed against every packet/frame that it's registered the type for, which by default is every frame.
> So if there's even a single packet in your pcap file without a 'mtp2.li' field, your mtp2_len variable will be nil for that execution of tap.packet() for that packet.
>
> Therefore my guess is you've got one or more packets in the capture that don't have such a field.
>
> When you do this:
>     print("mtp2 len:", tostring(mtp2_len.value))
> You're trying to access the 'value' field of the 'mtp2_len' object, and 'mtp2_len' isn't an object but instead nil for a packet that doesn't have such a field, and thus errors.

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.

>
> So you should do this instead:
> function tap.packet(pinfo, tvb)
>     local mtp2_len = mtp2_li_field()
>     if mtp2_len then
>         print("mtp2 len:" .. tostring(mtp2_len))
>         print("mtp2 len:" .. tostring(mtp2_len.value))
>     else
>         print("packet #" .. pinfo.number .. " didn't have a mtp2.li field")
>     end
> end
>
> 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?

> 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.
>
>
>> otoh this one:
>>
>> local mtp2_field = Field.new("mtp2")
>>
>> function tap.packet(pinfo, tvb)
>>  local mtp2 = mtp2_field()
>>  local l = string.byte(mtp2.value,3);
>> end
>>
>> barks like this:
>>
>> [string "get_isup.lua"]:189: bad argument #1 to 'byte' (string
>> expected, got userdata)
>
> "mtp2" is a protocol field, I think - not a "normal" value field.  Therefore, when you do this:
>     local l = string.byte(mtp2.value,3);
> the 'mtp2.value' retrieves a ByteArray object (one of the object types defined by Wireshark's Lua), as opposed to a Lua string.  Since the string.byte() function expects a Lua string for its first argument, this will fail.  Lua's error message is a bit opaque because all Lua knows about the ByteArray object is that it's a Lua userdata type, as opposed to for example a Lua number or table type.
>
> Since it's a ByteArray object, you can call some methods against it to get values.
> See this:
> http://www.wireshark.org/docs/wsug_html_chunked/lua_module_Tvb.html#lua_class_ByteArray
>
> 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.

thanks a lot!
bye now!
cristian