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

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)));
                    break;
                case FT_IPv6:
                case FT_IPXNET:
                case FT_GUID:
                case FT_OID:
                default:
                    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 https://bugs.wireshark.org

Regards
Kurt

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.

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 ask.wireshark.org 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. :)