summaryrefslogtreecommitdiff
path: root/wiretap/k12.c
AgeCommit message (Collapse)AuthorFilesLines
2017-06-05Allow bigger snapshot lengths for D-Bus captures.Guy Harris1-3/+3
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for them, because that's the largest possible D-Bus message size. See https://bugs.freedesktop.org/show_bug.cgi?id=100220 for an example of the problems caused by limiting the snapshot length to 256KB for D-Bus. Have a snapshot length of 0 in a capture_file structure mean "there is no snapshot length for the file"; we don't need the has_snap field in that case, a value of 0 mean "no, we don't have a snapshot length". In dumpcap, start out with a pipe buffer size of 2KB, and grow it as necessary. When checking for a too-big packet from a pipe, check against the appropriate maximum - 128MB for DLT_DBUS, 256KB for everything else. Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20 Reviewed-on: https://code.wireshark.org/review/21952 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-03-02Remove a cast that now causes rather than squelching warnings.Guy Harris1-1/+1
We're now comparing an unsigned with an expression made mostly of unsigned, so there's no need to cast the expression to long to squelch signed vs. unsigned warnings. Change-Id: I3b8c6f6faf26a9c252eb55d9e69fb298a3ad4c3b Reviewed-on: https://code.wireshark.org/review/20347 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-03-02Add more sanity checks.Guy Harris1-14/+27
Bug: 13431 Change-Id: I330cb087c6e89277120057019cb5155f005ed269 Reviewed-on: https://code.wireshark.org/review/20337 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2016-09-28Use wtap_read_bytes() to skip over bytes when reading a record.Guy Harris1-2/+2
Allow file_read() to take a null pointer as a buffer argument; a null argument means "do everything except copy the bytes from the file to the user buffer". That means that wtap_read_bytes() and wtap_read_bytes_or_eof() also support a null pointer as a buffer argument. Use wtap_read_bytes() with a null buffer argument rather than file_skip() to skip forward over data. This fixes some places where files were mis-identified as ERF files, as the ERF open heuristics now get a short "read" error if they try to skip over more bytes than exist in the file. Change-Id: I4f73499d877c1f582e2bcf9b045034880cb09622 Reviewed-on: https://code.wireshark.org/review/17974 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-11-09Call the dumper routine to finish write a file the "finish" routine.Guy Harris1-2/+2
It doesn't actually *close* any handle, so it's best called a "finish" routine rather than a "close" routine. In libwiretap modules, don't bother setting the finish routine pointer to null - it's already initialized to null (it's probably best not to require modules to set it). Change-Id: I19554f3fb826db495f17b36600ae36222cbc21b0 Reviewed-on: https://code.wireshark.org/review/11659 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-04-30Fix some cases where we're shifting a signed 1 left.Guy Harris1-1/+1
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>
2015-01-03Remove unnecessary includes from wiretap folderMartin Mathieson1-2/+0
Change-Id: I10d3057801673bc1c8ea78f144215869cc4b1851 Reviewed-on: https://code.wireshark.org/review/6217 Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com> Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
2015-01-02Add "Editor modelines"; Adjust whitespace as needed.Bill Meier1-35/+48
Change-Id: Ic5a5acb0f36d3aa144edbfb1ae71097b18426db4 Reviewed-on: https://code.wireshark.org/review/6216 Reviewed-by: Bill Meier <wmeier@newsguy.com>
2014-12-18Rename WTAP_ERR_REC_TYPE_UNSUPPORTED to WTAP_ERR_UNWRITABLE_REC_TYPE.Guy Harris1-1/+1
That indicates that it's a problem specific to *writing* capture files; we've already converted some errors to that style, and added a new one in that style. Change-Id: I8268316fd8b1a9e301bf09ae970b4b1fbcb35c9d Reviewed-on: https://code.wireshark.org/review/5826 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-18Handle "I can't map this for that file format" better.Guy Harris1-1/+1
For cases where record (meta)data is something that can't be written out in a particular file format, return WTAP_ERR_UNWRITABLE_REC_DATA along with an err_info string. Report (and free) that err_info string in cases where WTAP_ERR_UNWRITABLE_REC_DATA is returned. Clean up some other error reporting cases, and flag with an XXX some cases where we aren't reporting errors at all, while we're at it. Change-Id: I91d02093af0d42c24ec4634c2c773b30f3d39ab3 Reviewed-on: https://code.wireshark.org/review/5823 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-17Rename WTAP_ERR_UNSUPPORTED_ENCAP to WTAP_ERR_UNWRITABLE_ENCAP.Guy Harris1-1/+1
That makes it clearer what the problem is, and that it should only be returned by the dump code path, not by the read code path. Change-Id: Icc5c9cff43be6c073f0467607555fa7138c5d074 Reviewed-on: https://code.wireshark.org/review/5797 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-08Use correct expression in a "length too short" message.Guy Harris1-1/+1
Doesn't change the behavior of the code, but makes it more consistent. Change-Id: I6f07fbbb4c7d14d8a46ecfd1c419d951c356fd77 Reviewed-on: https://code.wireshark.org/review/5672 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-07Add checks for non-null-terminated strings.Guy Harris1-6/+14
Change-Id: Iaad2d2f76e5d554800ba2c79d5c01f4b9da6fa0b Reviewed-on: https://code.wireshark.org/review/5660 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-06Don't go past the end of the "extra data".Guy Harris1-69/+69
The "extra data", according to the RF5 API manual I have, is "hardware parameters", so change some names. Report an error if the variable parts of the configuration event record run past the record length. Report an error if the hardware parameters are too short. For the purportedly DS0 hardware parameters, don't assume they'll be long enough for the mask; they might not be. Change-Id: Ib63d042e4ede32216fb474c4ecdba84db1387abc Reviewed-on: https://code.wireshark.org/review/5638 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-12-05Fix some copy-and-pasteos in error messages.Guy Harris1-3/+3
Change-Id: I1fe3434e69a08aae3d7413067275b3d7ee1552f5 Reviewed-on: https://code.wireshark.org/review/5634 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-17Get rid of unused includes of <ctype.h>.Guy Harris1-1/+0
Change-Id: Iab9eaeb0f5765748b2582177396264e4e69bc6d1 Reviewed-on: https://code.wireshark.org/review/4786 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-11Use the count-of-records fields to figure out how many records to read.Guy Harris1-98/+134
Fetch the count of records from one of the locations where it appears to be, and, currently, require that it be equal to the count at the other location where it appears to be; if they ever differ, we'll need the file in order to reverse-engineer some more. Fix the way we *write* .rf5 files - it turns out that we were 1) not writing the full file size; 2) not writing the packet count in the right location. Detect files written by the old code, and get the packet count from the right location for those files. Change-Id: I7ce83afbc9dbbd300c81c96ef8f7785a0aeefa7a Reviewed-on: https://code.wireshark.org/review/4608 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-09Use an enum for the open-routine return value, as per Evan Huus's suggestion.Guy Harris1-17/+17
Clean up some things we ran across while making those changes. Change-Id: Ic0d8943d36e6e120d7af0a6148fad98015d1e83e Reviewed-on: https://code.wireshark.org/review/4581 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07Close some memory leaks for bad K12 RF5 files.Guy Harris1-0/+13
Change-Id: Ic4272a5637463fdb4d23f80d81341a0e6ea33de3 Reviewed-on: https://code.wireshark.org/review/4538 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07Make the code a bit more like the pre-new-APIs code.Guy Harris1-1/+2
Change-Id: I40282d8825936d24480c9b77e2e7d9374b1de6b5 Reviewed-on: https://code.wireshark.org/review/4534 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07Whitespace cleanups.Guy Harris1-5/+5
Change-Id: I92f983b2e04defab30eb31c14c484b9f0f582413 Reviewed-on: https://code.wireshark.org/review/4513 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07Add some higher-level file-read APIs and use them.Guy Harris1-9/+7
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an error number pointer, and an error string pointer as arguments, and that treats a short read of any sort, including a read that returns 0 bytes, as a WTAP_ERR_SHORT_READ error, and that returns the error number and string through its last two arguments. Add wtap_read_bytes_or_eof(), which is similar, but that treats a read that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF indication. Use those in file readers; that simplifies the code and makes it less likely that somebody will fail to supply the error number and error string on a file read error. Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210 Reviewed-on: https://code.wireshark.org/review/4512 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-05Read the record length in common code.Guy Harris1-61/+52
Instead of reading the 16-byte blob and record length at the same time, just read the 16-byte blob, and then fall through to the record-length reading code. Change-Id: Ib2819a2d654e2670233821882bac79d7cd656b12 Reviewed-on: https://code.wireshark.org/review/4480 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-05Fix a comment.Guy Harris1-1/+1
Change-Id: I875888753859488ed810cedb5656bd870bee7122 Reviewed-on: https://code.wireshark.org/review/4471 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-05Improve comments, and add some #defines, to make it clearer what the code does.Guy Harris1-47/+110
Change-Id: I2cd8973bdce171053664cf4ed06a37bdd9b30353 Reviewed-on: https://code.wireshark.org/review/4470 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-09-28Make the time stamp resolution per-packet.Guy Harris1-1/+1
Pcap-ng files don't have a per-file time stamp resolution, they have a per-interface time stamp resolution. Add new time stamp resolution types of "unknown" and "per-packet", add the time stamp resolution to struct wtap_pkthdr, have the libwiretap core initialize it to the per-file time stamp resolution, and have pcap-ng do the same thing with the resolution that it does with the packet encapsulation. Get rid of the TS_PREC_AUTO_XXX values; just have TS_PREC_AUTO, which means "use the packet's resolution to determine how many significant digits to display". Rename all the WTAP_FILE_TSPREC_XXX values to WTAP_TSPREC_XXX, as they're also used for per-packet values. Change-Id: If9fd8f799b19836a5104aaa0870a951498886c69 Reviewed-on: https://code.wireshark.org/review/4349 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-08-02Rename buffer_ routines to ws_buffer_ to avoid name collisions.Guy Harris1-7/+7
In particular, epan/wslua/lrexlib.c has its own buffer_ routines, causing some linker warnings on some platforms, as reported in bug 10332. (Not to be backported to 1.12, as that would change the API and ABI of libwsutil and libwiretap. We should also make the buffer_ routines in epan/wslua/lrexlib.c static, which should also address this problem, but the name change avoids other potential namespace collisions.) Change-Id: I1d42c7d1778c7e4c019deb2608d476c52001ce28 Reviewed-on: https://code.wireshark.org/review/3351 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-07-15Only one buffer.c, please.Guy Harris1-1/+1
Otherwise, if you link with both libwiretap and libfiletap, it's anybody's guess which one you get. That means you're wasting memory with two copies of its routines if they're identical, and means surprising behavior if they're not (which showed up when I was debugging a double-free crash - fixing libwiretap's buffer_free() didn't fix the problem, because Wireshark happened to be calling libfiletap' unfixed buffer_free()). There's nothing *tap-specific about Buffers, anyway, so it really belongs in wsutil. Change-Id: I91537e46917e91277981f8f3365a2c0873152870 Reviewed-on: https://code.wireshark.org/review/3066 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-24Allow wtap_read() and wtap_seek_read() to return records other than packets.Guy Harris1-0/+7
Add a "record type" field to "struct wtap_pkthdr"; currently, it can be REC_TYPE_PACKET, for a record containing a packet, or REC_TYPE_FILE_TYPE_SPECIFIC, for records containing file-type-specific data. Modify code that reads packets to be able to handle non-packet records, even if that just means ignoring them. Rename some routines to indicate that they handle more than just packets. We don't yet have any libwiretap code that supplies records other than REC_TYPE_PACKET or that supporting writing records other than REC_TYPE_PACKET, or any code to support plugins for handling REC_TYPE_FILE_TYPE_SPECIFIC records; this is just the first step for bug 8590. Change-Id: Idb40b78f17c2c3aea72031bcd252abf9bc11c813 Reviewed-on: https://code.wireshark.org/review/1773 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-23Get rid of trailing blank lines.Guy Harris1-2/+0
Change-Id: I53c560557d70e2a1cb78de37aad17d92a714ce2a Reviewed-on: https://code.wireshark.org/review/1751 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-23Revert "Allow wtap_read() and wtap_seek_read() to return non-packet records."Guy Harris1-10/+10
This reverts commit c0c480d08c175eed4524ea9e73ec86298f468cf4. A better way to do this is to have the record type be part of struct wtap_pkthdr; that keeps the metadata for the record together and requires fewer API changes. That is in-progress. Change-Id: Ic558f163a48e2c6d0df7f55e81a35a5e24b53bc6 Reviewed-on: https://code.wireshark.org/review/1741 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-23Allow wtap_read() and wtap_seek_read() to return non-packet records.Guy Harris1-10/+10
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>
2014-05-13isprint() -> g_ascii_isprint()AndersBroman1-1/+1
Change-Id: Ia586ef8ce500d5fc7578c52014206fa7a7eaea41 Reviewed-on: https://code.wireshark.org/review/1624 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-09Revert "Refactor Wiretap"Guy Harris1-43/+40
This reverts commit 1abeb277f5e6bd27fbaebfecc8184e37ba9d008a. 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>
2014-05-09Refactor WiretapMichael Mann1-40/+43
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>
2014-03-04Remove all $Id$ from top of fileAlexis La Goutte1-2/+0
(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>
2014-01-22Don't write out packets that have a "captured length" bigger than we'reGuy Harris1-3/+3
willing to read or that's bigger than will fit in the file format; instead, report an error. For the "I can't write a packet of that type in that file type" error, report the file type in question. svn path=/trunk/; revision=54882
2014-01-02No seek-read routines use the length argument, so eliminate it fromGuy Harris1-1/+1
wtap_seek_read(). svn path=/trunk/; revision=54570
2013-12-21isascii(x) && isprint(x) -> g_ascii_isprint(x)Jakub Zawadzki1-1/+1
svn path=/trunk/; revision=54328
2013-12-03wiretap: start using <wsutil/pint.h>Jakub Zawadzki1-22/+22
svn path=/trunk/; revision=53764
2013-11-20Add support for a new type of frame data record seen in a k18 file, andGuy Harris1-10/+34
handle that file not ending with a 2-byte 0xffff end-of-file record. This fixes bug 9455, although it doesn't add support for reading an "index" file for a capture that's in multiple .rf5 files, which is a separate issue noted in that bug. It also doesn't attempt to figure out what the data in the new record type following the data that appears to be the same as that in the other data record format but preceding the actual packet data is. svn path=/trunk/; revision=53452
2013-11-20Add code to dump part of a record as ASCII, and use it to dump stringsGuy Harris1-27/+236
in a source description record, including the stack. Dump some other fields in those records as well. Attach separate sequential and random read buffers to the private data structure, rather than allocating them in various routines (and not always freeing them) and, in at least one case, allocating a single *common* buffer for all wth's to use. Fix some comments (the DS0 mask is 32 bytes long, but gets turned into a bitmask). Put in a description of what a "stack file"'s contents look like. Much of it may be useless to us (for example, we have the notion that TCP has protocol number 6 built-in...), but the RELATION entries that map from "BASE" to a protocol could obviate the need to have the user specify a map from stack file names to starting protocols, and we might be able to use, for example, entries that map TCP/UDP/SCTP port numbers to protocols to obviate the need for the user to explicitly use Decode As or otherwise configure port-to-protocol mappings themselves. Add a bunch of record length checks before we fetch data from records. svn path=/trunk/; revision=53450
2013-11-19Update URL for the Tektronix manual, and fix a typo in the same comment.Guy Harris1-20/+27
Dump the raw contents of records as hex and ASCII, not just hex. Sort the record types, and add a new one for a type we've seen in a k18 file and about which we know nothing. For unknown record types, print the type in hex. svn path=/trunk/; revision=53441
2013-11-19Fix some problems with the debugging code.Guy Harris1-4/+5
svn path=/trunk/; revision=53438
2013-11-08(Trivial) whitespace cleanup (mostly trailing whitespace).Bill Meier1-2/+2
svn path=/trunk/; revision=53172
2013-11-08The "file types" we have are actually combinations of types andGuy Harris1-1/+1
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
2013-06-16Have the seek-read routines take a Buffer rather than a guint8 pointerGuy Harris1-24/+17
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
2013-05-17Pull some functions that fill in a struct wtap_pkthdr into common code,Guy Harris1-139/+83
and use it in both the read and seek-read routines. svn path=/trunk/; revision=49377
2013-03-17From beroset:Anders Broman1-9/+5
implemented wtap_dump_file_seek() and _tell() implemented the previously declared but unimplemented wtap_dump_file_seek() and wtap_dump_file_tell() functions and used them in the seven files that had previously used a plain ftell or fseek and added error checking as appropriate. I also added a new error WTAP_ERR_CANT_SEEK_COMPRESSED and put it next to WTAP_ERR_CANT_SEEK causing renumbering of two of the existing error codes. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416 svn path=/trunk/; revision=48348
2012-12-27Do not call wtap_file_read_unknown_bytes() orGuy Harris1-1/+1
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