Ping-Bug: 11858
Change-Id: I53a223f1b46b513e693b40dc8754837eee5cfec0
Reviewed-on: https://code.wireshark.org/review/15242
Reviewed-by: Michael Mann <mmann78@netscape.net>
With Q033, connection id (CID) flag change (only on one byte and only say 0 or 8 bytes length
cid never have length 2 or 4 bytes (from old spec), see https://groups.google.com/a/chromium.org/d/msg/proto-quic/pR6FA7oyeV8/4Ec42-GrMQAJ
Change-Id: I9fffe0369a8cc0811bdbc85a9c9fa8539f049981
Reviewed-on: https://code.wireshark.org/review/15164
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Ic40f86850dc94338a8c2205e04679793f368672f
Reviewed-on: https://code.wireshark.org/review/14967
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Before, the dissector didn't have any code path to dissect the PT
discovery parameters. The code path necessary as well as the
parameter definitions have been added.
Change-Id: I17665a56d033ffbfd16d47fe2e7374111aff9530
Reviewed-on: https://code.wireshark.org/review/14804
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Check for destination or source MAC addresses that aren't 12 characters
(hex dump of 6 octets) long and type/length fields that aren't 4
characters (hex dump of 2 octets) long.
The buffer into which we copy the hex dump characters doesn't need to be
null-terminated, so don't bother to null-terminate it. Use the final
offset into the buffer as the buffer length, rather than using strlen().
Just memcpy the MAC addresses and type/length fields into the buffer;
the buffer is guaranteed to be big enough for all of them, and, as
noted, it doesn't need to be null-terminated.
Change-Id: I790e953542ae8443af01c81229a8deb877448ee3
Reviewed-on: https://code.wireshark.org/review/15239
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We don't check against it. Insteead, use phdr->caplen as the buffer
size; that's based on the number of hex digits we've found.
While we're at it, also get rid of ISERIES_PKT_ALLOC_SIZE - it makes it
less obvious that it's based on the packet length from the packet
header.
Change-Id: I8ad6306c62e7bc4cf896b335f39a5a77780fb2ea
Reviewed-on: https://code.wireshark.org/review/15236
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I397da333b467d140613947fe49cd98338ab1d8f6
Reviewed-on: https://code.wireshark.org/review/15218
Tested-by: João Valverde <j@v6e.pt>
Reviewed-by: Michael Mann <mmann78@netscape.net>
If the IMAP TCP stream doesn't include the STARTTLS command/response
the IMAP dissector will try to dissect TLS ciphertext as IMAP protocol
plaintext.
Add heuristic check for SSLv3/TLS and if the heuristic matches register
dissect_ssl() as the dissector for that IMAP session.
Change-Id: If84eca22315193a306e93e66c608de6634e6cd85
Reviewed-on: https://code.wireshark.org/review/13570
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12394
Change-Id: I4b19b95f2e1ffc96dac5c91bff6698c246f52007
Reviewed-on: https://code.wireshark.org/review/15230
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12395
Change-Id: I43b458a73b0934e9a5c2c89d34eac5a8f21a7455
Reviewed-on: https://code.wireshark.org/review/15223
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Bug: 12400
Change-Id: Ic4116082b0f6c119172b222aadefab821f1b0971
Reviewed-on: https://code.wireshark.org/review/15205
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12396
Change-Id: I54fe8f61f42c32b5ef33da633ece51bbcda8c95f
Reviewed-on: https://code.wireshark.org/review/15220
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Change-Id: I6450d468504e942df72342176a0e145e5ac3db5f
Reviewed-on: https://code.wireshark.org/review/15216
Reviewed-by: Guy Harris <guy@alum.mit.edu>
USB dissectors can't assume that only their class type has been passed around in the conversation. Make explicit check that class type expected matches the dissector and stop/prevent dissection if there isn't a match.
Bug: 12356
Change-Id: Ib23973a4ebd0fbb51952ffc118daf95e3389a209
Reviewed-on: https://code.wireshark.org/review/15212
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
add a version check in order to fix compilation with older Qt versions
(I couldn't figure out when exactly SH_ScrollBar_Transient was
introduced. It appears in the Qt 5.6 documentation, it's unavailable in
Qt 5.2)
Change-Id: Idf7ea1302e4a40e290a6750cbe077d9d2b7b56a8
Reviewed-on: https://code.wireshark.org/review/15196
Reviewed-by: Gerald Combs <gerald@wireshark.org>
0 means that the dissector rejected the packet.
Change-Id: I9e04443a5f378198f94038e0e67b2e1fde8054be
Reviewed-on: https://code.wireshark.org/review/15210
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
If a dissector returns 0, it rejects the packet ("this is not my
protocol"). This is in contradiction to requesting more data from TCP.
Bug: 12359
Change-Id: Ib0da7fc3ef92b35b3950e74f50484d9e21a93a6f
Reviewed-on: https://code.wireshark.org/review/15198
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
this avoids warnings about unused variables
Change-Id: I0ee033f90c1387615ffc167161e53f4293d89763
Reviewed-on: https://code.wireshark.org/review/15195
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
And note that our limit (which is what we use as the fixed buffer size)
is less than WTAP_MAX_PACKET_SIZE, so we don't have to check against
WTAP_MAX_PACKET_SIZE.
Change-Id: I28cd95c40fd2fba9994a5d64ef323f1d8c1c4478
Reviewed-on: https://code.wireshark.org/review/15204
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
A normal packet should be Ethernet-sized; initially make the buffer big
enough for a maximum-sized Ethernet packet.
Once we know the payload length, check to make sure the packet length
won't be > WTAP_MAX_PACKET_SIZE and fail if it will. Then boost the
buffer size to be large enough for the packet, even if it's bigger than
a maximum-sized Ethernet packet.
Change-Id: I75b2108dd68f5bc5cd436bf5b82990089a7116bf
Reviewed-on: https://code.wireshark.org/review/15200
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Q_NULLPTR is not defined in Qt4
Change-Id: I0dd5444c6c019b7e8f1a346d9e12432d9b306d8a
Reviewed-on: https://code.wireshark.org/review/15197
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Share more code between the read and seek-read routines.
Also note why that code doesn't have to check against
WTAP_MAX_PACKET_SIZE.
Change-Id: I09086fcd3c16883c2598fb0aeb172c66f480d315
Reviewed-on: https://code.wireshark.org/review/15193
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Since Ie5e670b769eb0674950f3679ef511047641c2873 we no longer support
synchronous name resolution.
Change-Id: Icc65bd665bd610d89f894549e77608cfb5ef4c53
Reviewed-on: https://code.wireshark.org/review/15165
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I38c2b337bf276f6edc6b5d3f10e47ae81a1610b5
Reviewed-on: https://code.wireshark.org/review/15167
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The preference is disabled by default and saves a little
bit of memory for those that don't get process information
from IPFIX.
Change-Id: I4b6a106d156862a8d53bf2ad5ee88ea857637815
Reviewed-on: https://code.wireshark.org/review/15139
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
These file formats have 16-bit packet lengths, so, even with some extra
metadata added, the packet data length will never be bigger than
WTAP_MAX_PACKET_SIZE. (No, we won't ever reduce WTAP_MAX_PACKET_SIZE.)
Change-Id: I9e1b1d90971f91cc6e5d66d0aa93841445b2bc22
Reviewed-on: https://code.wireshark.org/review/15186
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And note the cases where we don't have to check, as the length in the
file is 2 bytes long, and 65535 + the metadata length is <
WTAP_MAX_PACKET_SIZE.
Change-Id: I1e690eeee900b9aa7484dc0bd0c106dc38c77269
Reviewed-on: https://code.wireshark.org/review/15180
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And use the actual packet length, rather than a fixed value, as the
buffer size we need for the packet.
Change-Id: I3af6724210a85b50610839d1bdf97fcf5a152b2f
Reviewed-on: https://code.wireshark.org/review/15179
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Merge the header and packet data parsing routines while we're at it.
Bug: 12396
Change-Id: I7f981f9cdcbea7ecdeb88bfff2f12d875de2244f
Reviewed-on: https://code.wireshark.org/review/15176
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Merge the header and packet data parsing routines while we're at it.
Bug: 12395
Change-Id: Ia70f33b71ff28451190fcf144c333fd1362646b2
Reviewed-on: https://code.wireshark.org/review/15172
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Qt 5.2 added QMenu::setAsDockMenu. Use it to add recent items to the
Wireshark dock menu.
Add QWinJumpList code which does something similar. Comment it out
because it does it slowly and not-quite-correctly.
Change-Id: I801b1037b998516eacab695f982d7d6e889bafb6
Reviewed-on: https://code.wireshark.org/review/15166
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Bug: 12394
Change-Id: Ifa023ce70f7a2697bf151009b035a6e6cf8d5d90
Reviewed-on: https://code.wireshark.org/review/15169
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way they only need to be allocated if analysis is being done.
Inspired by https://www.wireshark.org/lists/wireshark-dev/201604/msg00218.html
Ping-Bug: 12367
Change-Id: I797e5b305133d85a2a89688109cc3a218d0a9e88
Reviewed-on: https://code.wireshark.org/review/15138
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Wireshark was failing to parse DOCSIS 3.1 BPKM Response (Auth Reply)
messages with a key length of 256 bytes, which is in the DOCSIS 3.1
specification located here:
http://www.cablelabs.com/specification/docsis-3-1-security-specification/
See Appendix I.4 "Authorization Reply"
Change-Id: Ic50eb4a2d637a7bc47385b7c0a96c830f7a920be
Reviewed-on: https://code.wireshark.org/review/15149
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Make sure we replace a line using the same line endings.
Change-Id: I73b07a773bc39b05ba7a73b3c3c984a73c545a48
Reviewed-on: https://code.wireshark.org/review/15157
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Print our various version variables when we set versions.
Change-Id: I9212369c17f3d2a040e83900945eb57670d4992d
Reviewed-on: https://code.wireshark.org/review/15156
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Alexis La Goutte