http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2410
--- Comment #2 from Bill Meier <wmeier@xxxxxxxxxxx> 2008-04-27 15:11:37 GMT ---
Packets 2418-2419 in the original file are the ones apparently causing the
problem. (I've attached a file with just those two packets).
Note that certain tcp preferences must be set as follows:
<Validate TCP checksum if possible> Off
<Allow subdissector to reassemble TCP streams> On
I note that the tshark & wireshark behavior when reading this file are a bit
different on Windows and Linux.
==== Windows:
-->tshark -V -r ...
<snip>
mechToken: 608208D706092A864886F71201025801005F8208C6308208...
krb5_blob: 608208D706092A864886F71201025801005F8208C6308208...
KRB5 OID: 1.2.840.113554.1.2.88 (iso.2.840.113554.1.2.88)
krb5_tok_id: KRB5_AP_REQ (0x0001)
[Malformed Packet: SMB]
[Dissector bug, protocol NBSS: STATUS_ACCESS_VIOLATION: dissector accessed
an invalid memory address]
-->wireshark -r ...
<crash>
Interestingly enough the following works *without* a wireshark crash
1. Start wireshark
2. set tcp preference <validate TCP checksum ...> to On.
3. open the file ...
4. set tcp preference <validate TCP checksum ...> to Off.
Wireshark does not crash but then shows "[Dissector bug ..." in the
details for the second packet.
===== Linux
Both tshark & wireshark segment fault when reading the file.
The trick of having wireshark read
the file before setting the <tcp validate checksum ...> preference to Off
doesn't seem to work.
So: my conclusion:
1. packet-nbns has a problem re-assembling the two packets (one or both of
which
presumably have invalid [fuzz'ed] data).
2. The exception chandling ode (TRY ... ENDTRY) seems to have a problem
on Windows wireshark (at least for the case of initially reading and
decoding a file).
Should the access violation also be trapped on Linux ??
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
