On Wed, May 09, 2007 at 01:11:08AM +0200, M??she Van der Sterre wrote:
> Ok. The stuff commented with C++ comments are mostly stubs for packet
> types I did not yet implement. I forgot delete replace them before
> generating the patch. I'll try to implement all opcodes for the next
> patch. I made the dissector because we need it at work, we don't
> really need the packets not in the patch, so I can't work on them that
> much.
If someone else needs them, they can always add them if you don't :)
> packet-ib shows only the opcode from the packets. packet-gdsdb also
> shows the information from the packets (as far as implemented). Most
> useful to us is the distraction of the SQL queries. I don't think IB
> is the best name for the protocol (Both Firebird and Interbase use the
> protocol), IANA has named the protocol gds_db, so I chose that one. (I
> tried to get some hints and opinions on this choice within the
> firebird and wireshark communities, but got little response). Also, I
> saw no use in using packet-ib as a base for packet-gdsdb, there isn't
> that much to it.
Thanks for the explanation. Using the IANA assigned name is the way to
go. I see now that packet-ib is very small so I can see why it was not
used as a base.
> We have been using this dissector successfully for some time now, and
> I have some more updates for it, but liked to receive some comments
> first, before heading in the wrong direction ;)
A closer look at your code yielded a few minor changes I would recommend
to make it look more like the rest of Wireshark:
- Change the names that you #define to uppercase. For example, use
HANDLE_FUNCTION(parameter) instead of handle_function(parameter) so it
is clear that handle_function isn't really the name of the function.
- Although we do use the syntax like you have where the opening brace
starts at the end of a statement such as:
if(this) {
}
.. we usually don't use that form for functions. We instead do:
function_name(parameter)
{
}
> Alsa where can I best send mails to? Do some people respond faster to
> private mail? Or do I just have to be patient? :P
The developers get to the mailing list posts as quickly as we can.
Your patience is appreciated as we're often busy with our day jobs and
such. :)
> At last a question about tshark: As I said, we are using this
> dissector to generate a log of our database queries, and tshark's
> memory usage grows slowly. So we have to restart it once in a few
> days. I don't know if I coded some memory leaks, or if this is normal
> for tshark (I can imagine tshark keeps some packets/data in memory?)
Yes, Wireshark and tshark keep state data for various protocols. You
could limit the amount of protocols even considered for display by using
capture filters (you're using display filters right now for the protocol
dissector you wrote). Check out the user guide (on the web site) or
tshark's command-line option help for more details on using the capture
filters. Basically, you could limit captured traffic to just the port
your protocol uses. Then it wouldn't gather state data for other
protocols.
Steve