On 5/8/07, Stephen Fisher <[EMAIL PROTECTED]> 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/ _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
