On 5/8/07, Stephen Fisher <stephentfisher@xxxxxxxxx> wrote:
On Sun, Apr 15, 2007 at 11:45:57PM +0200, M??she Van der Sterre wrote:
> As far as I know this dissector conforms to the usual way things are
> done with wireshark. But I like to hear about anything I missed, or
> should have done another way.
With only a quick glance, I noticed some C++ style comments (//) in
there that need to be changed to C style (/* */). Could you send an
updated patch with this fixed and that includes the correction you made
in a follow-up e-mail to this one on the 16th.
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.
> This dissector currently has all the features the current
> (packet-ib.c) dissector has, so replacing it right away should not be
> a problem.
I'm not familar with packet-ib, so excuse my ignorance. Is there any
reason that packet-ib couldn't be updated instead of replacing it? What
else does your dissector cover that packet-ib didn'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.
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 ;)
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
PS.
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?)
--
Mvg
Môshe van der Sterre
http://www.moshe.nl/
http://www.coecu.nl/
