Wireshark-dev: Re: [Wireshark-dev] LUA TCP protocol dissector
From: Jaap Keuter <[email protected]>
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