This is the first step towards implementing the mechanisms requestd in
bug 8590; currently, we don't return any records other than packet
records from libwiretap, and just ignore non-packet records in the rest
of Wireshark, but this at least gets the ball rolling.
Change-Id: I34a45b54dd361f69fdad1a758d8ca4f42d67d574
Reviewed-on: https://code.wireshark.org/review/1736
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit 1abeb277f5.
This isn't building, and looks as if it requires significant work to fix.
Change-Id: I622b1bb243e353e874883a302ab419532b7601f2
Reviewed-on: https://code.wireshark.org/review/1568
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Start of refactoring Wiretap and breaking structures down into "generally useful fields for dissection" and "capture specific". Since this in intended as a "base" for Wiretap and Filetap, the "wft" prefix is used for "common" functionality.
The "architectural" changes can be found in cfile.h, wtap.h, wtap-int.h and (new file) wftap-int.h. Most of the other (painstaking) changes were really just the result of compiling those new architecture changes.
bug:9607
Change-Id: Ife858a61760d7a8a03be073546c0e7e582cab2ae
Reviewed-on: https://code.wireshark.org/review/1485
Reviewed-by: Michael Mann <mmann78@netscape.net>
Leave it there, but commented out, just in case it *should* be used.
"#if 0" out the code that sets it.
Change-Id: I8802fc416030106d9d8421b0d7b8612597794bab
Reviewed-on: https://code.wireshark.org/review/867
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The "48 bits, in a weird byte order" is a variant of 64-bit
"Corey-endian", with the upper 16 bits of the result - which are in the
*middle* of the bytes of the number - ignored. Define a pcorey48tohll()
macro and use that, rather than the loop.
There are a bunch of #defines for offsets in the headers; use them
rather than magic constants.
Change-Id: Idfdc8a741278d71a5db47c067914c97615c3e02d
Reviewed-on: https://code.wireshark.org/review/864
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And rename to #define for the stats block trailer length to indicate
that it's the length of the trailer, not the length of the stats block
in its entirety.
Change-Id: Iec82c971b32f2d3f4a604fe75a91633e1813ebd5
Reviewed-on: https://code.wireshark.org/review/701
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The #defines came from Radiotap, but this isn't Radiotap (I see no
presence bits here), and Radiotap has to handle stuff that this code
doesn't (such as, for example, Atheros Wi-Fi adapters that, annoyingly,
pad the space between the 802.11 header and the 802.11 payload when in
monitor mode, hence the "datapad" flag).
Change-Id: I87ca3539e0f9254ab94cc8897bdf69e4574f0525
Reviewed-on: https://code.wireshark.org/review/690
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Pull the packet data copying code into the routines that parse the rest
of the record data. Have those routines directly fill in the metadata
headers in the packet data, without bothering to fill in a structure
first.
As a result, those routines no longer can set phdr->caplen to a value
different from phdr->len, so don't set WTAP_HAS_CAP_LEN.
Have the existing sanity checking code cause the read to fail if the
checks fail, and add some additional sanity checking.
Use #defines for some offsets into the statistics header and trailer.
Change-Id: Ie936683b96888961d6e2598131cc0eb6146b37e9
Reviewed-on: https://code.wireshark.org/review/689
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Always include the length of the metadata headers, as we're always
copying them.
Do a straightforward check to make sure the data length is >= 4 before
subtracting out the FCS (which appears not to actually be an FCS; at
least in the captures I've seen, it looks like random junk).
Improve the comments for that code.
Get rid of some tabs, in favor of spaces, while we're at it, and make
the 3 sections of code where that's done more alike.
Change-Id: Ica338cd492ac535833933a8b7cd5191217c5ab5b
Reviewed-on: https://code.wireshark.org/review/685
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In some cases, we know, based on the FPGA code, what vwr->STATS_LEN is,
so use that #define.
While we're at it, replace some hardcoded numbers that represent the
statistics trailer length with the appropriate #define.
Also, combine two identical case arms for Ethernet into one.
Change-Id: I0bdea8e5aab146094ad21fa7e67dca2913da688b
Reviewed-on: https://code.wireshark.org/review/672
Reviewed-by: Guy Harris <guy@alum.mit.edu>
vwr->STATS_LEN is the length of the statistics trailer at the end of the
packet, and it's the same for S2 and S3 versions of the WLAN card. It
should *not* be set to the length of the metadata headers that we
*generate and put in front of the packet data that we hand to our
callers*.
Get rid of a debugging message while we're at it.
Change-Id: I465b5ba4dedb88f1f401d34439b44b16a4bb01cc
Reviewed-on: https://code.wireshark.org/review/671
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The so-called "radiotap headers" bear no resemblance to actual
radiotap.org radiotap headers; there are no presence bits, for example.
Get rid of the words "radiotap" and "radio tap", get rid of #defines
that aren't used, get rid of duplicate definitions.
Change-Id: I0bb6abda5d13bf20810dc865a567f4ec51a38056
Reviewed-on: https://code.wireshark.org/review/670
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In the S1 FPGA code, copy the "MPDU starts at 4 or 6" comment.
Get rid of misleading comment in the S2/S3 FPGA code; we're using the
MPDU_OFF field from the private data structure, so we're not calculating
*anything* at that point. Put in comments indicating what's being done
at the point where those calculations are actually done.
Change-Id: Ifda709a6b2aa7edad964f639086012c72c0a71fe
Reviewed-on: https://code.wireshark.org/review/668
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a comment describing (some of) the record, while we're at it, and
update another comment to reflect reality.
Change-Id: Ia7f1432402b843b96983375c0e0842c030de0cee
Reviewed-on: https://code.wireshark.org/review/667
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Instead of throwing in 48 and 64 as numbers, use vwr->STATS_LEN to
indicate what the lengths are. Yeah, it has to be fetched at run time,
but big deal.
That also shows that, as we've already rejected records whose size is
less than vwr->STATS_LEN, we don't have to check for that, so eliminate
those checks.
Change-Id: Id4822b3e5a02abfffb2da96a50999e36548a4279
Reviewed-on: https://code.wireshark.org/review/663
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fix presumed typo while we're at it.
Change-Id: Ic8ae6e6669e5c5fc618ec2516af98ba2390487ce
Reviewed-on: https://code.wireshark.org/review/660
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
subtypes, e.g. Network Monitor version 1 and Network Monitor version 2
are separate "file types", even though they both come from Network
Monitor.
Rename various functions, #defines, and variables appropriately.
svn path=/trunk/; revision=53166
We read a two-byte length field and add a constant number of header
bytes to this length, so we could in theory be larger than guint16.
svn path=/trunk/; revision=52619
range check for array index
don't assign the result of pntohs() to a gint16
range check for the values stored in phdr.(cap)len
svn path=/trunk/; revision=52618
don't assign the output of pntoh24() to a gint16
unfortunately, vwr detection does not work reliably and many pdf files
are recognized as vwr - this commit should prevent wireshark from
crashing when it tries to load the USB 2.0 spec as pdf ;-)
svn path=/trunk/; revision=52599
and assign float constants, not double constants, to float variables.
Floating-point constants are double by default; you have to add "f" to
the end to make them float.
This squelches 64-bit-to-32-bit warnings.
svn path=/trunk/; revision=51289
This was the 4th patch, but also:
- use gmalloc0() to allocate vwr struct. Otherwise, valgrind says that
many of fields were still uninitialised when parse_s1_W_stats later
read them
- whitespace tidyup, got rid of remaining tabs and trailing whitespace
Did a fair bit of fuzz-testing without seeing any problems.
svn path=/trunk/; revision=51248
as the "where to put the packet data" argument.
This lets more of the libwiretap code be common between the read and
seek-read code paths, and also allows for more flexibility in the "fill
in the data" path - we can expand the buffer as needed in both cases.
svn path=/trunk/; revision=49949
Check that the record length we got out of the file is at least as big as
stats block trailer; if not, declare the file bad.
svn path=/trunk/; revision=49739
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
Guy Harris