Columns Lazy initialization clobbers cinfo packet buffer. Open a file, goto packet 1000, menu View->Show packet in a new window, the wrong packet is decoded (it's the last displayed in the packet list pane). gtk/packet_win.c:new_window_cb() should call wtap_seek_reread().
svn path=/trunk/; revision=29997
Fedora 11/Gtk2.16.6: Get two Gtk-Critical messages each time a capture fie is opened:
(lt-wireshark:15705): Gtk-CRITICAL **: gtk_tree_view_column_set_fixed_width: assertion `fixed_width > 0' failed
gtk_tree_view_column_set_fixed_width is incompatible with variable width columns.
svn path=/trunk/; revision=29989
(See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3542)
The current get_dfs_referral response code is based on old protocol specs,
which are unofficial, erroneous.
I modify packet-smb.c to be confirm to protocol's official spec. Some
changes are:
1. handle referral entry version 2, 3, 4 separately. The current code does
not distinguish v3 from v2, however they are not same.
2. change server type, referral flags etc.
3. refactor some code, such as string dissecting.
Also: From me: a small change to handle possible overflow
when subtracting from a guint16.
svn path=/trunk/; revision=29986
Errors occur which means decrypted_len - esp_iv len will render a negative value and thus
cause the problem. This patch prevents the crash. Not sure if this is a proper fix. At least it
looks like a sane check to do.
svn path=/trunk/; revision=29979
In ntp_fmt_ts() in packet-ntp.c time stamps are displayed to 4 digits (0.1
msec). More digits may be significant (e.g., if GPS local clocks are used).
Change time stamp format in g_snprintf() from
%07.4f
to
%09.6f
svn path=/trunk/; revision=29961
on the stack! There is no guarantee that the header length won't cause a
buffer overflow - there could be a bug in some version of Surveyor
generating a bad file, there could be a future version of Surveyor that
has a really big pseudo-header, the file could've been written by
something other than Surveyor that has a bug in it, there could be a
file that's corrupted in transit, or there could be a deliberately
malformed packet trying to cause *Shark to execute arbitrary code.
Also, explicitly check for a too-short header length and fail with
WTAP_ERR_BAD_RECORD in that case.
Add some comments asking some questions about the header.
(The previous change was for bug 3856:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3856
not bug 3865.)
svn path=/trunk/; revision=29958
epan\dissectors\packet-edonkey.c
In the fuction dissect_emule_sourceOBFU(): the line
ti = proto_tree_add_item(tree, hf_emule_sourceOBFU, tvb, offset, 7 + ((settings & 0x08) ? 16 : 0), FALSE);
should be
ti = proto_tree_add_item(tree, hf_emule_sourceOBFU, tvb, offset, 7 + ((settings & 0x80) ? 16 : 0), FALSE);
and, the line:
if (settings & 0x08)
should be:
if (settings & 0x80)
That is, 0x08 should be revised to 0x80.
reference: the eMule0.49c source code, file PartFile.cpp, line 2730, in the
function CPartFile::AddSources().
svn path=/trunk/; revision=29957
The Shomiti Wireless head was modified in a recent release such that wireshark
can no longer read Shomiti wireless capture files.
This new format is backwards compatible with the old format.
svn path=/trunk/; revision=29956
SDNVs are theoretically unlimited in size. The value of most SDNVs in the
Bundle Protocol is practically limited to far less than a 32 bit number. The
initial dissector included only 1 SDNV evaluation routine which returned a 32
bit number. SDNV fields that evaluated to greater than a 32 bit number were
considered in error. One BP implementation chose to add some syntax to one of
the SDNV fields that extends it to more than 32 bits. The patch included here
adds an evaluation routine that will return a 64 bit number. That routine is
called to evaluate the field where it makes sense to have a value in excess of
32 bits.
svn path=/trunk/; revision=29954
Improved AIM protocol dissector:
* Decodes more values acording to official Oscar spec
* Renamed clientautoresp to client_err (as written in spec)
* Fix decoding orror on rendezvous channel
* Other small improvements
svn path=/trunk/; revision=29953
http://support.microsoft.com/kb/912222. Print a warning on the welcome
page if it's present and enabled.
This hasn't yet been tested on a chimney-enabled machine, but it should
work.
svn path=/trunk/; revision=29948
Anders Broman