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
Version 4.8.0 of collectd introduced two new data source types: DERIVE and ABSOLUTE.
With this patch support for the new data source types is added so they are displayed correctly.
svn path=/trunk/; revision=29947
for the MS Power Level and FPC in the L1 Information and MS Power IEs.
This should fix https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4017
(though I don't have a sample capture to verify the fix and that I didn't
break anything.)
svn path=/trunk/; revision=29944
Anders Broman