Bill Meier wrote:
> Martin Warnes wrote:
>
>> Unhandled exception ("proto.c:4238: failed assertion "hfinfo->display ==
>> BASE_NONE"", group=1, code=4)
>>
>>
>
>
>> I'm guessing something may have changed that need
Hi
I've been compiling the JGroups plugin
(http://javagroups.cvs.sourceforge.net/viewvc/javagroups/wireshark-plugin/)
into the unstable branch for a while; up till 1.3.0 I hadn't run into
any problems and everything worked great. But I ran into a issue after I
tried to build against 1.3.3, I did a
Hi/
Attached is a small patch that correct an issue with reading certain IBM
iSeries Comms traces.
Traces where data has been dropped for whatever reason now have the
packet number suffixed with an asterix "*", this causes the current
iSeries wiretap routine to report a "bad" header. The attached
Hi/
The recent revision to the MySQL dissector seems to have had an impact
on a dissector I'm developing for a protocol that can carry a MySQL payload.
Within my code I have the following:
db_handle = find_dissector ("mysql");
if (db_handle)
call_dissector (db_handle, next_
s converted! lawyers unfortunately are a different species
altogether ;-)
Still one day you never know...
- Martin
Ulf Lamping wrote the following on 07/11/2007 09:25 PM:
> Martin Warnes schrieb:
>> Unfortunately this appears to be the case, which is possibly a shame as
>>
> I w
Unfortunately this appears to be the case, which is possibly a shame as
we have a bunch of plug-in dissectors we would willingly release for
free download, but it would be a cold day in hell before our lawyers
agreed to release the source code, even though I doubt there's anything
of proprietr
Stephen Fisher wrote the following on 06/18/2007 03:28 AM:
On Sun, Jun 10, 2007 at 07:23:38PM +0100, Martin Warnes wrote:
Attached is a small patch that adds a preference option to allow the
SQL Query string to be appended to the INFO column display. This makes
life a little bit easier when
Attached is a small patch that adds a preference option to allow the SQL
Query string to be appended to the INFO column display. This makes life
a little bit easier when scanning a trace to find the packet associated
with a specific query. I thought it was better to implement it as a
preference
Currently the MySQL dissector assumes that an OK-Packet Response
contains the Server_Status field. Having checked the MySQL protocol page
I can't say conclusively whether it should or it shouldn't, however I've
come across a couple of MySQL Java clients that receive the OK-Packet
without the Se
Stephen Fisher wrote the following on 12/01/2007 19:34:
> On Fri, Jan 12, 2007 at 07:19:59PM +0000, Martin Warnes wrote:
>
>
>> The Connect:Direct protocol in this case is just a header record:
>>
>> 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2
06:50:31PM +0000, Martin Warnes wrote:
>
>
>> Checking the SSL preferences I had an entry for RSA keys list;
>> 127.0.0.1,1364,tls,c:\ssltest.key which specified this port so it was
>> correctly attempting to dissect this packet as SSL after all.
>>
>
> I
27;m working on.
Regards .. Martin
Martin Warnes wrote the following on 12/01/2007 16:27:
> Hi,
>
> I'm developing a dissector plugin for the Connect:Direct file transfer
> protocol, the protocol itself can contain a SSL payload. Until recently
> i didn't have too many probl
Hi,
I'm developing a dissector plugin for the Connect:Direct file transfer
protocol, the protocol itself can contain a SSL payload. Until recently
i didn't have too many problems with my dissector identifying it's own
data, adding some information to the tree and then passing the SSL
payload o
The following works for me when debugging a plugin it should be the same
for a built in dissector:
1. Open wireshark.exe in MSVC and F5 to start debug.
2. When it pauses in ..\gtk\main.c press F5 again to continue Wireshark
startup.
3. Once you see the main display window open your dissector code
Attached updated patch to use "dissect_mysql_pdu" instead of
"dissect_mysql" when registering the protocol dissector.
Regards .. Martin
Martin Warnes wrote the following on 29/11/2006 10:50:
> Obviously not so trivial as dissect_mysql does reassembly, so it looks
Hi,
Much simplified patch to use column fences on the COL_INFO field to
prevent sebsequent calls to the SSL dissector for the same packet
clearing the information placed by earlier calls. After each SSL record
is processed a col_set_fence() call is now issued to preserve what has
been written.
Th
Hi,
Yes, I hadn't come across column fences, this would be the preferred
method so I will rework the patch.
Thanks .. Martin
Jaap Keuter wrote the following on 29/11/2006 11:23:
> Hi,
>
> Isn't this what column fences were supposed to be used for?
>
> Thanx,
> Jaap
>
>
> ___
Obviously not so trivial as dissect_mysql does reassembly, so it looks
like I shoud register dissect_mysql_pdu instead
... or would this only work if the higher level dissector also did
reassembly which mine does?
Martin Warnes wrote the following on 29/11/2006 09:37:
> Add register_dissec
Hi,
This patch modifies the way the COL_INFO field is updated and when
col_info is used to clear the contents, see below for a more detailed
explanation.
The SSL dissector (packet-ssl) is capable of handling multiple handshake
message, if this occurs then the handshake protocol for each message i
Add register_dissector() call to allow being called as a subdissector
Index: packet-mysql.c
===
--- packet-mysql.c (revision 20004)
+++ packet-mysql.c (working copy)
@@ -901,6 +901,8 @@
Hi/
I submitted the attached patch a while back but it seems to have slipped
through the cracks.
The patch addresses issues with higher precision packet
timings on top end iSeries hardware and should enable the iseries
wiretap to handle timings in both micro and nano seconds.
Regards .. Martin
Hi/
Attached is a patch that addresses issues with higher precision packet
timings on top end iSeries hardware and should enable the iseries
wiretap to handle timings in both micro and nano seconds.
Regards .. Martin
Index: iseries.c
==
22 matches
Mail list logo