Wireshark-dev: Re: [Wireshark-dev] LUA TCP protocol dissector

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Sun, 03 Feb 2008 20:04:31 +0100
Hi Christer,

Great that you've been able to put together your prototype dissector in LUA to 'hit the ground running' so to speak. Now that you venture into the more advanced stages of protocol dissection it may be time to implement the design in C. This opens the option of using the various support features, conversations and TCP reassembly, which you seem to seek.

You might want to enter the observations you made about TvbRange and tvb_get_stringz in bugzilla, so they won't be lost.

Thanx,
Jaap


Christer Palm wrote:
Hi,

First of all you should know that I'm new to wireshark development, so please forgive me if any of this doesn't make sense.

I'm trying to slap together a quick and dirty dissector for helping me out in debugging a proprietary protocol. I also need the dissector to run on both linux and windows, but I don't have access to the windows development environment.

Thus, I've been toying around with a dissector written in LUA, which appears to be a perfect match for my needs.

The LUA stuff is quite impressive and I've got everything to mostly work. However, I have run into a fundamental problem - the protocol is TCP based, and as such I need to at least be able to keep some state on a conversation level.

It seems that there is no way to access the two recommended (in README.developer) methods of reassembling TCP PDU:s, i.e. tcp_dissect_pdus() or the pinfo->desegment_offset/len stuff.

Neither does it seem to be a LUA API support for any of the conversation stuff in wireshark.

I've been experimenting with keeping my own state in a frame-indexed LUA table, which works fine for keeping state for a given frame, but I haven't been able to access the tcp.continuation_to field (I always get nil reading it), which I need to get to the header frame entry.

Any ideas/tricks that can be used to get around this?


Also, I have found some other minor problems that might be worth reporting:

- TvbRange.len doesn't seem to work for some reason. As a workaround I use TvbRange:bytes():len(). - There's no equivalent to tvb_get_stringz(), although it's easy enough to code your own one.


Regards,
--
Christer Palm