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

Lua error: “Tvbs can only be created and used in dissectors”

1

I am trying to use lua to dissect my protocol stack.

The one problem I cannot solve is this:

I can get several messages that are completed in the same packet.

I would then like to make tvbs for each of the completed messages and hand them over to a dissector. But if I get more than one extra tvb - and a dissector that is not the generic data-dissector - I get this fault message:

"Tvbs can only be created and used in dissectors"

What am I doing wrong?

This is smallest lua file that can reproduce the problem:

------------- lua dissector
local data_dis = Dissector.get ("data")

– mini dissector I would like to use on reassembled messages local p_foo = Proto ("foo", "foo proto") local f_foo_first_byte = ProtoField.uint8 ("foo.ind", "Index") p_foo.fields = {f_foo_first_byte}

function p_foo.dissector(tvb, pinfo, tree) local subtree = tree:add (p_foo, tvb()) subtree:add (f_foo_first_byte, tvb(0,1)) end

– the dissector for the udp packets on port 2800 local p_bar = Proto ("bar", "bar proto") local f_bar_ind = ProtoField.uint8 ("bar.ind", "Index") p_bar.fields = {f_bar_ind}

function p_bar.dissector (tvb, pinfo, tree) local subtree = tree:add (p_bar, tvb())

subtree:add (f_bar_ind, tvb(0,1)) data_dis:call(tvb, pinfo, tree)

local dissector

local alt = 0 – alt = 1 – uncomment to see that it does not works with the foo-dissector

if alt == 0 then dissector = Dissector.get ("data") else dissector = Dissector.get ("foo") end

– The following is just done to fake reassembly local range = tvb(0,tvb:len()) bytes = range:bytes()

newTvb = ByteArray.tvb(bytes, "first") dissector:call(newTvb, pinfo, tree)

newTvb1 = ByteArray.tvb(bytes, "second") dissector:call(newTvb1, pinfo, tree)

end

local udp_encap_table = DissectorTable.get("udp.port") udp_encap_table:add(2800,p_bar)

And here a script that generates a packet to dissect

#!/bin/bash

port=2800

messageIndex="00" data="00010203040506070809"

packetSender() { sudo nping 4.3.2.1 –udp -c 1 –source-ip 1.2.3.4 –source-port $port –dest-port $port –data "$messageIndex$data" }

packetSender

asked 03 Oct ‘16, 14:17

mj99's gravatar image

mj99
26227
accept rate: 50%

1

Not that I would understand why, but if you first create both new tvbs and then dissect them, it works:

newTvb = ByteArray.tvb(bytes, "first")
newTvb1 = ByteArray.tvb(bytes, "second")
dissector:call(newTvb, pinfo, tree)
dissector:call(newTvb1, pinfo, tree)

makes

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Send_00 (20:53:45:4e:44:00), Dst: Receive_00 (20:52:45:43:56:00)
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2
User Datagram Protocol, Src Port: 2800, Dst Port: 0
bar proto
Data (10 bytes)
Data: 00010203040506070809
[Length: 10]
foo proto
Index: 0
foo proto
Index: 0
(03 Oct ‘16, 22:24) sindy

Thanks a lot for this workaround!

I will try to use this, but I think I will have to do two passes over the tvb since I do not know how many reassembled tvbs I will get from a packet and I like to have the reassembled messages along with the fragment that made it complete.

(04 Oct ‘16, 10:18) mj99

Thanks a lot, I could make my dissector work based on this.

It was however quite painful. I got a lot of “expired tvb” errors before I figured out how to juggle it.

Is it my code in the question that is buggy some way I cannot see, or is it wireshark that does not support doing this with lua?

(04 Oct ‘16, 14:55) mj99
1

I think it’s a bug and I think I see where the problem is. Let me see if I can whip together a patch…

(06 Oct ‘16, 06:46) JeffMorriss ♦

@mj99 Where did you get the idea of using ByteArray.tvb(bytes, “first”) instead of bytes:tvb(“first”)? The former is not supposed to work and might break in future versions of Wireshark.

(17 Oct ‘16, 03:41) Lekensteyn

I’d suppose the OP has copied the idea from the “official” example page.

(17 Oct ‘16, 04:09) sindy
showing 5 of 6 show 1 more comments


One Answer:

2

It seems this is a bug--what @sindy noticed made that much easier to see.

I've attempted to fix the problem in change 18095. I don't have time at the moment to actually test the change--maybe tonight (if you don't beat me to it :-)).

answered 06 Oct '16, 07:34

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

Thanks a lot for your work. I am, for the moment, away from my build environment. I will try to build tomorrow CET.

(06 Oct '16, 14:08) mj99

I did not manage to build wireshark with lua support. Can I download a build with the change to test it?

(08 Oct '16, 15:30) mj99

Sorry, I haven't had a chance to do anything more with this yet. Once I can test it then I can merge the change and you'll be able to pick up an automated build. I just need some free time...

(13 Oct '16, 12:31) JeffMorriss ♦

It turns out my change was incomplete but I fixed that and now it works well. Just awaiting code-review and merge.

(13 Oct '16, 18:55) JeffMorriss ♦

The change was merged about an hour ago. You should be able to pick up an automated build from here fairly soon. Choose a version with the number 1042 or higher (as in "v2.3.0rc0-1042-g3868252").

(14 Oct '16, 10:57) JeffMorriss ♦

The problem occurs in a very specific situation: a Lua dissector calls another Lua dissector, then invokes bytearray:new("source"). Would it be worth backporting it? Otherwise it takes about another 8 months before it is released I guess.

(14 Oct '16, 14:07) Lekensteyn

Yep, just did (actually before I saw your note but...).

(14 Oct '16, 18:09) JeffMorriss ♦
showing 5 of 7 show 2 more comments