https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6343
--- Comment #4 from Pierre-Marie de Rodat <pmderodat@xxxxxxxx> 2011-09-16 02:26:07 PDT ---
(In reply to comment #2)
> + proto_tree_add_item(tree, hf_val_count, tvb, n, 2, FALSE);
> ti = proto_tree_add_text(tree, tvb, n, 2, "Columns: %d", i);
>
> It seems to me that these bytes should only be displayed once: as a field;
> i.e., remove the proto_tree_add_text()).
You’re right: the proto_tree_add_text call must be there because the original
author had no field to display this value. Since I’ve added “val_count”, the
call to proto_tree_add_text is no longer needed. I’ve removed it in the updated
patch.
> What do you think would be the right name for this field ?
I called the C symbol “hf_val_count” because it counts how many “hf_val_length”
there is in the packet. The pretty name was “Data count”, but this field counts
the number of fields in a DataRow message and in a RowDescription message, so
“Field count” may be more suited (I’ve fixed it in the updated patch). I have
no other idea for this name, so I gently let anyone suggest something else. ;-)
> P.S. the patch as supplied is "invalid". At the end it had:
> […]
> I assumed that this was not relevant and removed it from the patch.
Indeed, I was clumsy: when inspecting PostgreSQL sessions, I tried to use the
dissector with the SSL deciphering module. I used the method indicated here:
http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/
. I worked with the HTTP dissector, but not with the PgSQL one. I haven’t read
a lot from the documentation, but I was able to notice a line which seemed
relevant in the HTTP dissector code and I tried it on the PgSQL dissector :
@@ -838,6 +844,7 @@
proto_register_field_array(proto_pgsql, hf, array_length(hf));
proto_register_subtree_array(ett, array_length(ett));
+ register_dissector("pgsql", dissect_pgsql_msg, proto_pgsql);
mod_pgsql = prefs_register_protocol(proto_pgsql, proto_reg_handoff_pgsql);
prefs_register_uint_preference(
mod_pgsql, "tcp.port", "PGSQL TCP port", "Set the port for PGSQL "
When preparing the first patch I submitted, I realized this line was part of
it, so I removed it too quickly. Here is why this unrelevant chunk of code was
there. ;-)
The point is that even if I succeeded in running the SSL deciphering module
with the PgSQL dissector, the SSL module couldn’t decipher the TCP stream. I
think the reason for this is that the SSL handshake begins only after a little
clear (ie. unciphered) exchange of messages between the frontend and the
backend. The only way for the SSL deciphering to work would be then to trigger
it from the PgSQL dissector when the SSL handshake really begins. I don’t know
if that’s possible, but that’s another story, and I may start a new bug report
for that when I’ll have enought time to try this.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
