new_packet_list: crash in add_byte_views from decrypted zigbee data
The cause of the crash I saw was that the add_byte_views() function in
main_proto_draw.c relies on output from previous dissector run while the
function may eventually trigger dissector to run again which wipes out the
previous output.
The patch copies the output of the dissector before calling add_byte_tab() so
that even when add_byte_tab() updates the dissector output, the loop continues
with previous dissector output.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5130
svn path=/trunk/; revision=41158
That means we don't need to do the block length check in
pcapng_read_block(); each block type reader, including the one for
unknown block types, does a check that's as stringent as that block
length check or more stringent, which means any block whose length is
less than the minimum will fail with the same error in both cases.
Fix the message for a too-short NRB.
svn path=/trunk/; revision=41152
1) contain the block length fields and block type field;
2) contain that plus the fixed-length portion of the block;
3) for blocks that have a variable-length portion other than the
options, contain that variable-length portion.
Fixes a crash we're seeing with a bad pcap-NG file in the Wireshark
menagerie (7799-lastPacketWithoutComment.pcapng - the last packet's
block length is 128, but it claims to have 98 bytes of packet data,
which requires a 132-byte block).
Clean up white space (use 8-space tabs).
svn path=/trunk/; revision=41143
In line 4722 of dictionary.xml file there is comment:
<-- Requesting-Node-Type is from old (v8.1.0 - v8.2.0) versions of 29.272. -->
This is not a valid XML comment and that line should read:
<!-- Requesting-Node-Type is from old (v8.1.0 - v8.2.0) versions of 29.272. -->
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6858
svn path=/trunk/; revision=41141
Dissector for Alcatel-Lucent Enterprise Universal Alcatel- and NOE protocol
families.
Meant as a replacement for existing UA-dissector in trunk because of better
feature set:
- latest protocol specifiaction
- more detailed dissection and filtering possibilities on subprotocols
- RTP stream setup
- NOE over SIP
Lars Ruoff
On behalf of Alcatel-Lucent Enterprise
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6844
svn path=/trunk/; revision=41134
the "Wrote xxx" messages was printed, although the compiler appeared to
have been run on the .c file that was never claimed to have been
written, but got an error because it couldn't find the .h file (also
never claimed to have been written), and in one of the successes on the
same buildbot, they were both printed for the same file.
svn path=/trunk/; revision=41133
block, which could be the case even in a *valid* file (consider a file
with an SHB, an NRB, an IDB, and a packet block, in that order); even if
there's no IDB before the first packet block, that should be reported to
the user as "interface N not less than interface count M", to more
precisely indicate the problem.
(Yes, the loop should probably keep going until it finds a packet block,
not just a non-IDB block.)
svn path=/trunk/; revision=41132
The problem was that when reading a .pcap file, we don't have any IDBs.
If reqested to write out an pcapng file, we (now) build a dummy IDB which
uses the file's encapsulation as the interface encapsulation. Therefore
it can't be per=packet.
We need to fix this by using wtap_dump_open_ng()...
svn path=/trunk/; revision=41122
you provide NULL when you call it via wtap_dump_open.
This does not make the buildbots happy, but at least
tshark doesn't crash anymore.
svn path=/trunk/; revision=41111
Michael Tüxen