This is a static archive of our old Q&A Site. Please post any new questions and answers at

IPv6 Dissecting throws Lua FT not yet supported error! Why?


I am using field.IPV6 = ProtoField.ipv6 ("IPv6", "IPv6 Address")

subtree:add(IPv6, buffer(offset, 16)

it throws LUA: FT not supported yet error. why do they then have in in the API reference? what's going on?

asked 02 Aug '13, 09:19

adityashankar's gravatar image

accept rate: 0%

3 Answers:


From wslua_tree.c

static int TreeItem_add_item_any(lua_State *L, gboolean little_endian) {
            switch(type) {               
                case FT_IPv4:
                    item = proto_tree_add_ipv4(tree_item->tree,hfid,tvbr->tvb->ws_tvb,tvbr->offset,tvbr->len,*((guint32*)(checkAddress(L,1)->data)));
                case FT_IPv6:
                case FT_IPXNET:
                case FT_GUID:
                case FT_OID:
                    luaL_error(L,"FT_ not yet supported");

So, adding IPv6 items to the tree is not yet implemented, whereas it is for IPv4.

@adityashankar: If you need that, please file an enhancement bug at


answered 23 Sep '13, 01:24

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%


I don't think this is correct. I finally decided to write a quick Lua dissector to test this, and I was able to successfully add an IPv6 address.

Anyway, I deleted my original answer, and I'm too lazy to retype it, but I think it might have been the correct answer after all, or closer to it anyway.

In a nutshell though, try something along the lines of the following:

local field_ipv6 = ProtoField.ipv6("foo.IPv6", "IPv6 Address")

foo.fields = { …, field_ipv6, … }

subtree:add(field_ipv6, buffer(offset, 16)

Refer to the User Guide for more help.

answered 24 Sep ‘13, 12:13

cmaynard's gravatar image

cmaynard ♦♦
accept rate: 20%

let’s make this your answer ;-)

I admit I did not check very thoroughly if that’s the reason, although it looked reasonable to me. Do you mind to post the ‘IPv6 dissector’? I would like to do some tests myself.


(24 Sep ‘13, 13:06) Kurt Knochner ♦

Here is a VERY basic Lua dissector that you can start with. You will need to replace FOO_PORT with some port number of your choice and then run: wireshark -X lua_script:foo.lua.

– Protocol
local p_foo = Proto("foo", "FOO Protocol")

-- Fields
local f_foo_val8 = ProtoField.uint8("foo.val8", "Value 8", base.OCT)
local f_foo_val16 = ProtoField.uint16("foo.val16", "Value 16", base.DEC)
local f_foo_val32 = ProtoField.uint32("foo.val32", "Value 32", base.HEX)
local f_foo_ipv4 = ProtoField.ipv4("foo.ipv4", "IPv4 Address")
local f_foo_ipv6 = ProtoField.ipv6("foo.ipv6", "IPv6 Address")

p_foo.fields = { f_foo_val8, f_foo_val16, f_foo_val32, f_foo_ipv4, f_foo_ipv6 }

-- Dissection
function p_foo.dissector(buf, pinfo, tree)
    local foo_tree = tree:add(p_foo, buf(0,-1))

    foo_tree:add(f_foo_val8, buf(0, 1))
    foo_tree:add(f_foo_val16, buf(1, 2))
    foo_tree:add(f_foo_val32, buf(3, 4))
    foo_tree:add(f_foo_ipv4, buf(7, 4))
    foo_tree:add(f_foo_ipv6, buf(11, 16))

-- Registration
local udp_table = DissectorTable.get("udp.port")
udp_table:add(FOO_PORT, p_foo)


(24 Sep ‘13, 13:21) cmaynard ♦♦

I uploaded a sample capture file to cloudshark that this lua dissector will be able to dissect. See if you’re interested. (If you decide to download it, you might want to download the original file, as there’s a capture file comment in it that references this question to let you know how it was intended to be dissected.)

That aside, after thinking about this some more, I think we’re missing some information, because the question clearly indicates, it throws LUA: FT not supported yet error., so if that’s the case, then it certainly does seem that Kurt’s answer is the correct one.

However, I know for certain that ProtoField.ipv6 works because I tested it. So, looking back at the question again (and after experimenting with Lua a bit), I now see:

field.IPV6 = ProtoField.ipv6 ("IPv6", "IPv6 Address")
subtree:add(IPv6, buffer(offset, 16)

Besides the poor naming convention of the filter (which isn't actually a problem in itself), there are a couple of syntax errors, the first of which is field.IPV6. This is an invalid name yielding an error dialog box that reads something along the lines of:

Lua: syntax error during precompilation of 'foo.lua':
[string "foo.lua"]:11: unexpected symbol near '.' [OK]

So let's assume field_IPV6 was intended, but then the next line should be:

subtree:add(field_IPV6, buffer(offset, 16)

So I tested this too, passing the invalid original IPv6 instead of field_IPV6, but Wireshark seems to start up just fine without any indications of any errors. The field doesn't get added to the tree of course, but there's no error message either. So basically I can't reproduce what @adityashankar reported given only the information provided. Maybe someone else can or maybe @adityashankar can provide some additional information.

(24 Sep '13, 18:07) cmaynard ♦♦

thanks for the code and the capture file. I'll have a look.

maybe @adityashankar can provide some additional information.

I think we need the original code that caused the error message to understand what's going on.

(25 Sep '13, 04:11) Kurt Knochner ♦


This question is old, but since I know the answer I figured I'd answer it in case someone finds this Q&A topic through the much-maligned search algorithm (or just via google):

The reason the original ask'er would get that error, but not in cmaynard's script, is because the treeitem:add() method does different things depending on the number of arguments and argument types it gets. (in other words it has multiple function prototypes/signatures) In fact one might say it has too many possible signatures, because it's really confusing.

When it's called with a first argument of a Proto or ProtoField, and a second argument of a TvbRange, and no more arguments than that, then it adds the given field type to the tree based on the given tvbrange. In that case, using an IPv6-based field is fine.

That's what happens in cmaynard's script when it does this:

foo_tree:add(f_foo_ipv6, buf(11, 16))

Since that has only two arguments, and the first one is a ProtoField and the second is a TvbRange, it'll add the TVB's bytes starting at offset 11 for length 16, as an IPv6 address into the tree.

But if there were a third argument to treeitem:add(), then the third argument is a value, to be used for the field in the tree display. The TvbRange (second argument) would still be used, to highlight in the bytes window pane where the value is, but the value third argument is used for the value shown in the details pane and filters and such. Unfortunately, in that model, one cannot use an IPv6 field type for the first argument. (probably because it would be a pain to handle a value being passed in from Lua for that, since an IPv6 value can't be represented by a number or boolean)

The reason I say the function is too confusing, however, is because it also has other signatures: if the first argument is a Proto or ProtoField and the second argument is not a TvbRange, but is instead something else, then that second argument is treated as the value to be set, and again if the first argument is a IPv6 field type, then again you can't do it and will hit this error.

But wait, don't act yet! We'll also throw in a free steak knife set... because the treeitem:add() has other signatures too, including ones where there are neither Proto/ProtoField nor TvbRange, and one where the first argument is a TvbRange and the second is a string, and another where there's only a TvbRange argument.

So I guess one could say the function is very flexible and accommodating. :)

answered 07 Mar '14, 16:21

Hadriel's gravatar image

accept rate: 18%