Observe that tcp_flags_to_str_first_letter is a copy of tcp_flags_to_str
with the flags[][4] variables copied and the loop variables inverted.
This misses the FIN bit, and runs past the flags buffer.
Behavior change: for consistency, move the reserved bits to the front
and print reserved bits individually. Old output / new output:
NCEUAPRSRRR
RRRNCEUAPRSF
Tested with this pcap with all flag bits set (0x0fff). hexdump:
d4c3b2a1020004000000000000000000ff7f000065000000b6b77455f3ac
06002800000028000000450000280001000040067ccd7f0000017f000001
0014005000000000000000005fff2000907f0000
Change-Id: I70e070808d1f0f9cd60eaf4f2b3f4ac6e3cfaada
Reviewed-on: https://code.wireshark.org/review/8826
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The Device ID of the OEM part may additionally be offered using OEM Device ID
Change-Id: Ic51cc4c05a41a8d18f265fb1abab739d1e82e28a
Reviewed-on: https://code.wireshark.org/review/8832
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: Michael Mann <mmann78@netscape.net>
pointer truncation from 'const guint16 *' to 'unsigned long'.
Even if we only require GLIB 2.16 this will fix the Windows build as we do
have a newer Glib on Windows.
Change-Id: Ie0644536783e8b298de59094fec240e249c9b27f
Reviewed-on: https://code.wireshark.org/review/8833
Reviewed-by: Anders Broman <a.broman58@gmail.com>
make a separate Value_string.
Change-Id: I79cb3b9d7261f8fba97f1938464d38c218282cb5
Reviewed-on: https://code.wireshark.org/review/8834
Reviewed-by: Anders Broman <a.broman58@gmail.com>
First, search for packages with the version number without the period (bug
11219).
Second, don't look for Lua 5.3 because we don't work with it. If what we find
(without pkg-config's help) is Lua 5.3, disable Lua support (bug 10881).
Cmake support by Peter Wu (originally Ie73e5b53640f10432881a9671c0a605f7f027ed8):
Note the check for "lua<=5.2.99" instead of "lua<5.3" since cmake does not
support the latter syntax. Tested with lua5.2, lua5.1 and lua (5.3) installed.
Bug: 11219
Ping-Bug: 10881
Change-Id: I382d07ca00eafc6111cd4e9faa2b66f6b8f95b6e
Reviewed-on: https://code.wireshark.org/review/8783
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
This avoids assertions when the field is added with proto_tree_add_string*()
(some of which show up in the fuzzed capture in bug 11254).
Ping-Bug: 11254
Change-Id: Iaf02f59443da0cf279d65eed049122d4dfaf7bcd
Reviewed-on: https://code.wireshark.org/review/8829
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
"file" dissectors are now rid of proto_tree_add_text.
Change-Id: I4e0f7248135e6ce194fcafde47e538db84b964aa
Reviewed-on: https://code.wireshark.org/review/8828
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
dissector_add_uint_range walks through ranges and then does not need the
range anymore. Discovered with `tshark -G fields` and GCC 5.1 + ASAN.
Change-Id: I76f98a6ccee6dbbecc1efb847c358bd6d010e1dc
Reviewed-on: https://code.wireshark.org/review/8825
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The buildbot printed "expr: syntax error", presumably from this, but
that oh-so-descriptive error message doesn't indicate what the problem
is, and just about any string should be valid as the left-hand operand
of the : operator.
Change-Id: I1140522357b8df07e4183bf0eb8c5fa9fbe275e4
Reviewed-on: https://code.wireshark.org/review/8827
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The variable is assigned values twice successively. Perhaps this is a mistake.
Change-Id: I3b567626c6046be8898db70580e98b339c0c8c2a
Reviewed-on: https://code.wireshark.org/review/8819
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Consider reviewing the expression of the 'A = B == C' kind. The expression is calculated as following: 'A = (B == C)'.
Change-Id: I162a2d081a70cb39b326d3aa2dc4108f49962169
Reviewed-on: https://code.wireshark.org/review/8821
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
The variable 'ii' is being used for this loop and for the outer loop.
Change-Id: I3e6e0e390a646fac62fd46ebf9dcdc56070f7609
Reviewed-on: https://code.wireshark.org/review/8820
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Be advised that compiler may delete this cycle or make it infinity. Use volatile variable(s) or synchronization primitives to avoid this.
Change-Id: I39104ec09f4c12994d62ed23e7a0cc00829b1255
Reviewed-on: https://code.wireshark.org/review/8818
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Range intersections are possible within conditional expressions. Example: if (A > 0 && A < 5) { ... } else if (A > 3 && A < 9) { ... }.
E-GSM and R-GSM EARFCNs are overlapping, as seen in 3GPP TS 05.05.
Change-Id: I5b9be53ba85109a674b05ae16cd729557cec6318
Reviewed-on: https://code.wireshark.org/review/8817
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
It's odd to compare 0 or 1 with a value of 1: ((entries > 1)) == 1.
Change-Id: I6261389dddbbd7e60e98b8c351150d491f9cbddb
Reviewed-on: https://code.wireshark.org/review/8810
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Consider inspecting the '1 << shift' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type.
Change-Id: I9939f3c471fcbbb033bbd5f846b9e09e8b8fd125
Reviewed-on: https://code.wireshark.org/review/8808
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
A call of the 'memcpy' function will lead to the '& tmp_key' buffer becoming out of range.
Change-Id: I615a6c3e0dab8cfc2d240b6b39cff387e0689f35
Reviewed-on: https://code.wireshark.org/review/8796
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Otherwise it could throw an exception if captured length < reported length
Change-Id: Ia9eb2778dbfebc1865a0040020a62ba20882b482
Reviewed-on: https://code.wireshark.org/review/8804
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
the pinfo parameter is not unused btw
Change-Id: Id038979cb64e858aa0b7b44ca8c6e3d4b7d2d05e
Reviewed-on: https://code.wireshark.org/review/8798
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: Idc6fc8fb21ee2e096e92e590c9b27c8363fced4f
Reviewed-on: https://code.wireshark.org/review/8797
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Yes, there is a mistake !
Change-Id: I6c6c67300c0e05d3ede00be27f675cc8b15bb439
Reviewed-on: https://code.wireshark.org/review/8794
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Yes, there is a bug ! :-)
Change-Id: I16319e6441575b9d7b702e6b23f7a7996ef85523
Reviewed-on: https://code.wireshark.org/review/8793
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Type 1 is Peek type (using Peek dissector)
Peek dissector is also update for Cisco AP, Pass info to peek dissector it is "Aruba PEEK" (with buggy FCS)
Add also check of signal value (when signal strength = 100%) it is a TX packet and there is no FCS
Bug:11204
Change-Id: I435e0e3275bc0a03fa534e49e86251114f568040
Reviewed-on: https://code.wireshark.org/review/8710
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Add a check of signal value (when signal strength = 100%) it is a TX packet and there is no FCS
Only work for Type3 (no signal information on Type 0)
For type 0, Always display the FCS
Bug:11204
Change-Id: I837f8c01c0d0284ecb218b6b03fa9ac025fac5f2
Reviewed-on: https://code.wireshark.org/review/8569
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Pascal Quantin