Make pcapng decode options in an NRB during read, and store the comment
option, and write it back out as well. Also make it handle plugin handlers
for unknown options in received NRB(s).
Change-Id: I81863ef8d85cb1c8b5ba6673ba0e562efe77714f
Reviewed-on: https://code.wireshark.org/review/9723
Petri-Dish: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Use "3gpp32423" instead of "nettrace3gpp324423":
- There were too many "4"s in the previous name ("324423" vs "32423").
- "nettrace" isn't an official name, per 3GPP TS 32 423
- It's shorter.
Change-Id: Ic981d0351a3014fb79702955ebef7b13f6ce4a2e
Reviewed-on: https://code.wireshark.org/review/9863
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Improve consistency when referring to 3GPP TS 32.423:
- The standard name is "3GPP TS 32.423" (with "TS", and "." separator).
- Fix typo in number series ("32" not "34").
- The standard refers to "Trace", not "Nettrace".
Change-Id: If9994b9c6de69b6e1bdfc6679fbaabe698971949
Reviewed-on: https://code.wireshark.org/review/9795
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>
There were some cases where it wasn't getting initialized when we set
the PHY to 11b, in addition to the one Pascal found.
Change-Id: I127737cd29dc53c96342364de5cb722b135f23f3
Reviewed-on: https://code.wireshark.org/review/9540
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It doesn't appear to provide the FEC type, although radiotap does, so
add a flag to indicate whether we have that.
Change-Id: I298d79bc6b640ee2408c3d70075c32bf331a210c
Reviewed-on: https://code.wireshark.org/review/9533
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The command byte values aren't FPGA-specific - if they were, the code
wouldn't have worked. Provide #defines for the main ones and check for
them, and use that to determine whether the packet is transmitted or
received.
Add a bunch of #defines, shuffle some defines to cluster related ones
together and separate unrelated ones, get rid of duplicate #defines
(where different FPGAs use the same value).
Fix some typoes.
Change-Id: Ic8adc589d7c36a4a91a81858de40c904743dd067
Reviewed-on: https://code.wireshark.org/review/9529
Reviewed-by: Guy Harris <guy@alum.mit.edu>
OK, where's NSS for the presumably-one-and-only user hiding for 11ac?
Change-Id: I53eb216c5d209dc5bb46c1d0aca7f8a200161e3e
Reviewed-on: https://code.wireshark.org/review/9512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
OK, anybody know how to convert a frequency between 4.9 GHz and 5.0 GHz
into a channel number, in a fashion that handles what's actually used in
both the US and Japan?
Change-Id: I95f4f9649e379b3d6651aadf8f62d8406b81b3b3
Reviewed-on: https://code.wireshark.org/review/9511
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We're already only setting it for 11b and 11g; this makes it a bit
cleaner, e.g. we don't need to say "oh, wait, we *don't* have short
preamble" for 11n and 11ac.
Change-Id: Idcf3e8c93d6a417f0319e4bd33247b98f07b6052
Reviewed-on: https://code.wireshark.org/review/9209
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The assignment of a short to a guint8 in packet-ieee80211-radiotap.c line 1696
generates a narrowing warning.
In my reading of the spec which shows the field as 9 bits,
and looking at the hf fields for this item I think it should be a guint16.
Change-Id: Ic7785c2bfc66d72f7b1e914b1a46f32079fc99d9
Reviewed-on: https://code.wireshark.org/review/9197
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Petri-Dish: Graham Bloice <graham.bloice@trihedral.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Add more fields to the metadata to handle everything radiotap has, and
show them.
Call the FEC type field just "FEC", and have it be an integer field with
0 meaning BCC and 1 meaning LDPC, rather than a Boolean.
11ac doesn't have *an* MCS, it can have up to 4, one per user.
Label the 11ac bandwidth values the same way we do in the radiotap
dissector.
Change-Id: I2c2415baff3e5d68d49dda497980e8271d26b1f6
Reviewed-on: https://code.wireshark.org/review/9176
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Just for completeness' sake.
Change-Id: I1ed609431c8bc62a79ebbf837fa2fc62f627a002
Reviewed-on: https://code.wireshark.org/review/9157
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
BTSNOOP format is supported by libwiretap and this dissector add
ability to open the same file in second mode:
1. Wireshark aka Protocol Viewer (default)
2. Fileshark aka File Viewer
Mode 2 also has feature to dissect protocols contained by this file,
try "Protocol Preferences -> Dissect next layer".
Change-Id: I99f0df5b55d31bf5a7d6e9269bfc054c09022b51
Reviewed-on: https://code.wireshark.org/review/17
Reviewed-by: Evan Huus <eapache@gmail.com>
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Provide that information so that the "802.11 radio information" protocol
can indicate whether a packet was 802.11 legacy/11b/11a/11g/11n/11ac,
and possibly whether it's 2.4 GHz or 5 GHz 11n. (Sometimes the center
frequency might not be supplied, so the band information can be useful.)
Also, provide some 11ac information, now that we can distinguish between
11n and 11ac. Don't calculate the data rate from the MCS index unless
it's 11n; we don't yet have code to calculate it for 11ac.
For radiotap, only provide guard interval information for 11n and 11ac,
not for earlier standards.
Handle the 11ac flag in the Peek remote protocol.
For Peek tagged files, the "extension flags" are 11n/11ac flags, so we
don't have to check for the "MCS used" bit in order to decide that the
packet is 11n or 11ac or to decide whether to provide the "bandwidth" or
"short GI" information.
Change-Id: Ia8a1a9b11a35243ed84eb4e72c384cc77512b098
Reviewed-on: https://code.wireshark.org/review/9032
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have dissectors of various forms of radio information headers in the
packets fill in a struct ieee_802_11_phdr with radio information as
appropriate, and call the "802.11 radio information" dissector rather
than the raw 802.11 dissector.
This means that the radio information can be found in a
protocol-independent and encapsulation-independent form when you're
looking at the packet; that information can be presented in a form
somewhat easier to read than the raw metadata header format.
It also enables having a single "radio information" tap that allows
statistics to handle all different sorts of radio information
encapsulation.
In addition, it lets us clean up some of the arguments passed to the
common 802.11 dissector routine, by having it pull that information from
the struct ieee_802_11_phdr.
Ensure that the right structure gets passed to that routine, and that
all the appropriate parts of that structure are filled in.
Rename the 802.11 radio protocol to "wlan_radio", rather than just
"radio", as it's 802.11-specific. Give all its fields "wlan_radio."
names rather than "wlan." names.
Change-Id: I78d79afece0ce0cf5fc17293c1e29596413b31c8
Reviewed-on: https://code.wireshark.org/review/8992
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Remove some unused members, and move the presence flags after the
should-always-be-set fields, right before the fields to which it
applies.
Change-Id: I8d6f08e1d3d8de0c11a9e04de4e98408d6b90693
Reviewed-on: https://code.wireshark.org/review/8972
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Those aren't pseudo-headers exported from libwiretap, they're just
structures corresponding to the pseudo-headers for some pcap/pcap-ng
link-layer header types.
Change-Id: Iec37cfc162b64adacdeb57e14e546bced7b673fa
Reviewed-on: https://code.wireshark.org/review/8941
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Only this issue with a netscaler trace file
Bug: 11248
Change-Id: I2bc2cae5c988eeff7bdd08471bf421faafcd4e73
Reviewed-on: https://code.wireshark.org/review/8672
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
It points to an array of bytes, not a character string.
Add some casts to squelch other Sun/Oracle C warnings.
Clean up some comments while we're at it.
Change-Id: Id0908178cb00d537e95569b9ce6f745c8fd6d716
Reviewed-on: https://code.wireshark.org/review/8369
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The LHS of the & operation is unsigned; make the RHS unsigned as well.
That squelches a Sun/Oracle C warning.
Change-Id: I6983cc89603a512020b8e8b560c00632de6b2fb3
Reviewed-on: https://code.wireshark.org/review/8363
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Shift 1U instead, to make sure it's unsigned; the result of, for
example, the result of shifting a signed value left is undefined if the
value times 2^{shift count} doesn't fit in the *signed* type of the
shifted value. That means, in particular, that the result of shifting 1
left by {number of bits in an int - 1} is undefined. (In *practice*,
it'll probably be -2^32, with the bit you want set, but that's not
guaranteed, and GCC 5.1 seems not to like it.)
Change-Id: I0d27565c382a04ceda9eec65f45a430ceb74cf53
Reviewed-on: https://code.wireshark.org/review/8255
Reviewed-by: Guy Harris <guy@alum.mit.edu>
declaration of 'random' shadows a global declaration.
Change-Id: I2dde89a3f0e5abb3b8acc3c7d09e1a0d53a6c0f7
Reviewed-on: https://code.wireshark.org/review/8245
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a variant of filetime_to_nstime() that takes a value that's like a
FILETIME but in units of nanoseconds rather than tenths of a
microsecond, and use that. (It looks as if they might just get FILETIME
values from the OS and multiply them by 100, as the nanosecond-FILETIME
values appear to be multiples of 100 in the captures I've seen, but they
might have chosen nanosecond resolution in case they need to support a
higher-resolution time stamp source, so we don't assume that the values
will always be a multiple of 100.)
Change-Id: If6a1cb2cb673688b042eb113b79cfd267f5454a5
Reviewed-on: https://code.wireshark.org/review/8150
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We had several copies of that code; put it into a filetime_to_nstime()
routine in wsutil, and call that common routine instead.
Change-Id: I1eb5579c36c129ff8d23f9212285ab3f63be0f43
Reviewed-on: https://code.wireshark.org/review/8142
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I.e., make them time_t's.
Change-Id: I102e9f585ae2798927757fe7f0f7a5a3fa251ec2
Reviewed-on: https://code.wireshark.org/review/8134
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The time is calculated based on a 32-bit "seconds since the Epoch" value
for the start time and a 32-bit delta from that time, in milliseconds.
We can just split that delta into seconds and milliseconds, add the
seconds to the start time to get the seconds part of the time stamp, and
multiply the milliseconds by 1,000,000 to get the nanoseconds part of
the time stamp. The only 64-bit arithmetic needed is adding the seconds
to a 64-bit version of the start time (just in case seconds+start time
goes past Y2.038K).
Change-Id: Id7c4c6255870627f81fc99dae919abaf47efc710
Reviewed-on: https://code.wireshark.org/review/8132
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Increase file size limit for mime files that can be
loaded by Wireshark to AddressSpace/2. On 32bit machines the limit can be
2 GiB.
Change-Id: I5b38b3ebe401077f4e1e873cff4b37da560d592f
Reviewed-on: https://code.wireshark.org/review/4907
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: Ica74f3f9239a96486967cf248feb4313bc390734
Reviewed-on: https://code.wireshark.org/review/7751
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Specifically: Management/Control frames saved by Microsoft Netmon (3.4?)
with "IEEE 802.11 plus Network Monitor radio header" encapsulation
may or may not be saved with an FCS.
See Bug 11105.
Fix: Use "check fcs" preference to specify whether Management & Control
frames have an fcs for this encapsulation.
Change-Id: Ibd0be7b4765c2df2b959cb2234aeed027266246b
Reviewed-on: https://code.wireshark.org/review/7939
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
mp2t.c: In function 'mp2t_find_next_pcr':
mp2t.c:160: warning: declaration of 'index' shadows a global declaration
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/string.h:125:
warning: shadowed declaration is here
mp2t.c: In function 'mp2t_bits_per_second':
mp2t.c:208: warning: declaration of 'index' shadows a global declaration
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/string.h:125:
warning: shadowed declaration is here
Change-Id: Ia8591990409a0730d913c50d80b6950425a22052
Reviewed-on: https://code.wireshark.org/review/7905
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Hadriel Kaplan