1999-08-02 02:26:22 +00:00
|
|
|
/* radcom.c
|
|
|
|
|
*
|
|
|
|
|
* Wiretap Library
|
2001-11-13 23:55:44 +00:00
|
|
|
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
2018-02-07 11:26:45 +00:00
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later
|
1999-08-02 02:26:22 +00:00
|
|
|
*/
|
2002-03-04 00:25:35 +00:00
|
|
|
|
1999-08-02 02:26:22 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
|
2000-11-17 21:00:40 +00:00
|
|
|
#include <string.h>
|
2000-05-19 23:07:04 +00:00
|
|
|
#include "wtap-int.h"
|
2000-01-13 07:09:20 +00:00
|
|
|
#include "file_wrappers.h"
|
1999-08-02 02:26:22 +00:00
|
|
|
#include "radcom.h"
|
|
|
|
|
|
|
|
|
|
struct frame_date {
|
|
|
|
|
guint16 year;
|
|
|
|
|
guint8 month;
|
|
|
|
|
guint8 day;
|
|
|
|
|
guint32 sec; /* seconds since midnight */
|
|
|
|
|
guint32 usec;
|
|
|
|
|
};
|
|
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
struct unaligned_frame_date {
|
|
|
|
|
char year[2];
|
|
|
|
|
char month;
|
|
|
|
|
char day;
|
|
|
|
|
char sec[4]; /* seconds since midnight */
|
|
|
|
|
char usec[4];
|
|
|
|
|
};
|
|
|
|
|
|
2002-12-17 21:53:57 +00:00
|
|
|
/* Found at the beginning of the file. Bytes 2 and 3 (D2:00) seem to be
|
|
|
|
|
* different in some captures */
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 radcom_magic[8] = {
|
1999-08-02 02:26:22 +00:00
|
|
|
0x42, 0xD2, 0x00, 0x34, 0x12, 0x66, 0x22, 0x88
|
|
|
|
|
};
|
|
|
|
|
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 encap_magic[4] = {
|
2011-04-27 03:13:08 +00:00
|
|
|
0x00, 0x42, 0x43, 0x09
|
2002-12-17 21:53:57 +00:00
|
|
|
};
|
|
|
|
|
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 active_time_magic[11] = {
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
'A', 'c', 't', 'i', 'v', 'e', ' ', 'T', 'i', 'm', 'e'
|
2002-12-17 21:53:57 +00:00
|
|
|
};
|
|
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
/* RADCOM record header - followed by frame data (perhaps including FCS).
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
|
|
|
|
|
"data_length" appears to be the length of packet data following
|
|
|
|
|
the record header. It's 0 in the last record.
|
|
|
|
|
|
|
|
|
|
"length" appears to be the amount of captured packet data, and
|
|
|
|
|
"real_length" might be the actual length of the frame on the wire -
|
|
|
|
|
in some captures, it's the same as "length", and, in others,
|
|
|
|
|
it's greater than "length". In the last record, however, those
|
|
|
|
|
may have bogus values (or is that some kind of trailer record?).
|
|
|
|
|
|
|
|
|
|
"xxx" appears to be all-zero in all but the last record in one
|
|
|
|
|
capture; if so, perhaps this indicates that the last record is,
|
|
|
|
|
in fact, a trailer of some sort, and some field in the header
|
|
|
|
|
is a record type. */
|
1999-09-01 23:53:58 +00:00
|
|
|
struct radcomrec_hdr {
|
|
|
|
|
char xxx[4]; /* unknown */
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
char data_length[2]; /* packet length? */
|
1999-09-01 23:53:58 +00:00
|
|
|
char xxy[5]; /* unknown */
|
|
|
|
|
struct unaligned_frame_date date; /* date/time stamp of packet */
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
char real_length[2]; /* actual length of packet */
|
|
|
|
|
char length[2]; /* captured length of packet */
|
|
|
|
|
char xxz[2]; /* unknown */
|
1999-09-01 23:53:58 +00:00
|
|
|
char dce; /* DCE/DTE flag (and other flags?) */
|
|
|
|
|
char xxw[9]; /* unknown */
|
|
|
|
|
};
|
|
|
|
|
|
2019-04-05 01:56:27 +00:00
|
|
|
static gboolean radcom_read(wtap *wth, wtap_rec *rec, Buffer *buf,
|
|
|
|
|
int *err, gchar **err_info, gint64 *data_offset);
|
2014-05-23 10:50:02 +00:00
|
|
|
static gboolean radcom_seek_read(wtap *wth, gint64 seek_off,
|
2018-02-09 00:19:12 +00:00
|
|
|
wtap_rec *rec, Buffer *buf, int *err, gchar **err_info);
|
|
|
|
|
static gboolean radcom_read_rec(wtap *wth, FILE_T fh, wtap_rec *rec,
|
2013-06-17 21:18:47 +00:00
|
|
|
Buffer *buf, int *err, gchar **err_info);
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
static int radcom_file_type_subtype = -1;
|
|
|
|
|
|
|
|
|
|
void register_radcom(void);
|
|
|
|
|
|
2014-10-09 23:44:15 +00:00
|
|
|
wtap_open_return_val radcom_open(wtap *wth, int *err, gchar **err_info)
|
1999-08-02 02:26:22 +00:00
|
|
|
{
|
2002-12-17 21:53:57 +00:00
|
|
|
guint8 r_magic[8], t_magic[11], search_encap[7];
|
1999-08-02 02:26:22 +00:00
|
|
|
struct frame_date start_date;
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
1999-08-31 00:25:19 +00:00
|
|
|
guint32 sec;
|
1999-08-02 02:26:22 +00:00
|
|
|
struct tm tm;
|
2011-04-27 03:13:08 +00:00
|
|
|
#endif
|
1999-08-02 02:26:22 +00:00
|
|
|
|
1999-08-20 08:00:24 +00:00
|
|
|
/* Read in the string that should be at the start of a RADCOM file */
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, r_magic, 8, err, err_info)) {
|
|
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
/* XXX: bytes 2 and 3 of the "magic" header seem to be different in some
|
|
|
|
|
* captures. We force them to our standard value so that the test
|
|
|
|
|
* succeeds (until we find if they have a special meaning, perhaps a
|
|
|
|
|
* version number ?) */
|
|
|
|
|
r_magic[1] = 0xD2;
|
|
|
|
|
r_magic[2] = 0x00;
|
2002-12-17 21:53:57 +00:00
|
|
|
if (memcmp(r_magic, radcom_magic, 8) != 0) {
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
/* Look for the "Active Time" string. The "frame_date" structure should
|
|
|
|
|
* be located 32 bytes before the beginning of this string */
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, t_magic, 11, err, err_info)) {
|
2014-10-07 19:49:14 +00:00
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
2011-04-27 03:13:08 +00:00
|
|
|
while (memcmp(t_magic, active_time_magic, 11) != 0)
|
|
|
|
|
{
|
2014-05-09 05:18:49 +00:00
|
|
|
if (file_seek(wth->fh, -10, SEEK_CUR, err) == -1)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, t_magic, 11, err, err_info)) {
|
2014-10-07 19:49:14 +00:00
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
2011-04-27 03:13:08 +00:00
|
|
|
}
|
|
|
|
|
}
|
2014-10-09 23:44:15 +00:00
|
|
|
if (file_seek(wth->fh, -43, SEEK_CUR, err) == -1)
|
|
|
|
|
return WTAP_OPEN_ERROR;
|
1999-08-02 02:26:22 +00:00
|
|
|
|
|
|
|
|
/* Get capture start time */
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, &start_date, sizeof(struct frame_date),
|
|
|
|
|
err, err_info)) {
|
2014-10-07 19:49:14 +00:00
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
}
|
|
|
|
|
|
2016-09-29 04:35:12 +00:00
|
|
|
/* So what time is this? */
|
|
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, sizeof(struct frame_date),
|
|
|
|
|
err, err_info)) {
|
|
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
|
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
|
|
|
|
}
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
if (!wtap_read_bytes(wth->fh, search_encap, 4,
|
|
|
|
|
err, err_info)) {
|
2014-10-07 19:49:14 +00:00
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (memcmp(encap_magic, search_encap, 4) == 0)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* OK, that's not it, go forward 1 byte - reading
|
|
|
|
|
* the magic moved us forward 4 bytes, so seeking
|
|
|
|
|
* backward 3 bytes moves forward 1 byte - and
|
|
|
|
|
* try the 4 bytes at that offset.
|
|
|
|
|
*/
|
|
|
|
|
if (file_seek(wth->fh, -3, SEEK_CUR, err) == -1)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
}
|
2016-09-29 04:35:12 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, 12, err, err_info)) {
|
|
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
|
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
|
|
|
|
}
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, search_encap, 4, err, err_info)) {
|
2014-10-07 19:49:14 +00:00
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
/* This is a radcom file */
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
wth->file_type_subtype = radcom_file_type_subtype;
|
2014-05-09 05:18:49 +00:00
|
|
|
wth->subtype_read = radcom_read;
|
|
|
|
|
wth->subtype_seek_read = radcom_seek_read;
|
|
|
|
|
wth->snapshot_length = 0; /* not available in header, only in frame */
|
2014-09-28 18:37:06 +00:00
|
|
|
wth->file_tsprec = WTAP_TSPREC_USEC;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
2013-12-03 20:35:50 +00:00
|
|
|
tm.tm_year = pletoh16(&start_date.year)-1900;
|
1999-08-02 02:26:22 +00:00
|
|
|
tm.tm_mon = start_date.month-1;
|
|
|
|
|
tm.tm_mday = start_date.day;
|
2013-12-03 20:35:50 +00:00
|
|
|
sec = pletoh32(&start_date.sec);
|
1999-08-31 00:25:19 +00:00
|
|
|
tm.tm_hour = sec/3600;
|
|
|
|
|
tm.tm_min = (sec%3600)/60;
|
|
|
|
|
tm.tm_sec = sec%60;
|
1999-08-02 02:26:22 +00:00
|
|
|
tm.tm_isdst = -1;
|
2011-04-27 03:13:08 +00:00
|
|
|
#endif
|
1999-08-02 02:26:22 +00:00
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
if (memcmp(search_encap, "LAPB", 4) == 0)
|
2014-05-09 05:18:49 +00:00
|
|
|
wth->file_encap = WTAP_ENCAP_LAPB;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
else if (memcmp(search_encap, "Ethe", 4) == 0)
|
2014-05-09 05:18:49 +00:00
|
|
|
wth->file_encap = WTAP_ENCAP_ETHERNET;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
else if (memcmp(search_encap, "ATM/", 4) == 0)
|
2014-05-09 05:18:49 +00:00
|
|
|
wth->file_encap = WTAP_ENCAP_ATM_RFC1483;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
else {
|
2014-12-17 06:22:29 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("radcom: network type \"%.4s\" unknown", search_encap);
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, &next_date, sizeof(struct frame_date),
|
|
|
|
|
err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
1999-08-02 02:26:22 +00:00
|
|
|
|
|
|
|
|
while (memcmp(&start_date, &next_date, 4)) {
|
2014-05-09 05:18:49 +00:00
|
|
|
if (file_seek(wth->fh, 1-sizeof(struct frame_date), SEEK_CUR, err) == -1)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, &next_date, sizeof(struct frame_date),
|
|
|
|
|
err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2011-04-27 03:13:08 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_ETHERNET) {
|
2016-09-29 04:35:12 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, 294, err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2014-05-09 05:18:49 +00:00
|
|
|
} else if (wth->file_encap == WTAP_ENCAP_LAPB) {
|
2016-09-29 04:35:12 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, 297, err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2014-05-09 05:18:49 +00:00
|
|
|
} else if (wth->file_encap == WTAP_ENCAP_ATM_RFC1483) {
|
2016-09-29 04:35:12 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, 504, err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
1999-08-28 01:19:45 +00:00
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2020-07-29 08:30:54 +00:00
|
|
|
/*
|
|
|
|
|
* Add an IDB; we don't know how many interfaces were involved,
|
|
|
|
|
* so we just say one interface, about which we only know
|
|
|
|
|
* the link-layer type, snapshot length, and time stamp
|
|
|
|
|
* resolution.
|
|
|
|
|
*/
|
|
|
|
|
wtap_add_generated_idb(wth);
|
|
|
|
|
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_MINE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Read the next packet */
|
2019-04-05 01:56:27 +00:00
|
|
|
static gboolean radcom_read(wtap *wth, wtap_rec *rec, Buffer *buf,
|
|
|
|
|
int *err, gchar **err_info, gint64 *data_offset)
|
1999-08-02 02:26:22 +00:00
|
|
|
{
|
1999-09-01 23:53:58 +00:00
|
|
|
char fcs[2];
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
*data_offset = file_tell(wth->fh);
|
2013-06-17 21:18:47 +00:00
|
|
|
|
2014-05-23 18:07:31 +00:00
|
|
|
/* Read record. */
|
2019-04-05 01:56:27 +00:00
|
|
|
if (!radcom_read_rec(wth, wth->fh, rec, buf, err, err_info)) {
|
2000-05-18 09:09:50 +00:00
|
|
|
/* Read error or EOF */
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_LAPB) {
|
1999-09-01 23:53:58 +00:00
|
|
|
/* Read the FCS.
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
XXX - should we have some way of indicating the
|
|
|
|
|
presence and size of an FCS to our caller?
|
|
|
|
|
That'd let us handle other file types as well. */
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, &fcs, sizeof fcs, err, err_info))
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
1999-08-28 01:19:45 +00:00
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2014-05-23 10:50:02 +00:00
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-23 10:50:02 +00:00
|
|
|
static gboolean
|
2014-05-09 05:18:49 +00:00
|
|
|
radcom_seek_read(wtap *wth, gint64 seek_off,
|
2018-02-09 00:19:12 +00:00
|
|
|
wtap_rec *rec, Buffer *buf,
|
2011-04-27 03:13:08 +00:00
|
|
|
int *err, gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
2014-05-09 05:18:49 +00:00
|
|
|
if (file_seek(wth->random_fh, seek_off, SEEK_SET, err) == -1)
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
|
2013-06-17 21:18:47 +00:00
|
|
|
/* Read record. */
|
2018-02-09 00:19:12 +00:00
|
|
|
if (!radcom_read_rec(wth, wth->random_fh, rec, buf, err,
|
2013-06-17 21:18:47 +00:00
|
|
|
err_info)) {
|
2000-05-18 09:09:50 +00:00
|
|
|
/* Read error or EOF */
|
2013-06-17 21:18:47 +00:00
|
|
|
if (*err == 0) {
|
2002-03-05 05:58:41 +00:00
|
|
|
/* EOF means "short read" in random-access mode */
|
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
|
}
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
2014-05-23 10:50:02 +00:00
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-17 21:18:47 +00:00
|
|
|
static gboolean
|
2018-02-09 00:19:12 +00:00
|
|
|
radcom_read_rec(wtap *wth, FILE_T fh, wtap_rec *rec, Buffer *buf,
|
2013-06-17 21:18:47 +00:00
|
|
|
int *err, gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
2013-06-14 23:59:04 +00:00
|
|
|
struct radcomrec_hdr hdr;
|
|
|
|
|
guint16 data_length, real_length, length;
|
|
|
|
|
guint32 sec;
|
|
|
|
|
struct tm tm;
|
|
|
|
|
guint8 atmhdr[8];
|
2000-05-18 09:09:50 +00:00
|
|
|
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes_or_eof(fh, &hdr, sizeof hdr, err, err_info))
|
2013-06-17 21:18:47 +00:00
|
|
|
return FALSE;
|
2013-06-14 23:59:04 +00:00
|
|
|
|
2013-12-03 20:35:50 +00:00
|
|
|
data_length = pletoh16(&hdr.data_length);
|
2013-06-14 23:59:04 +00:00
|
|
|
if (data_length == 0) {
|
|
|
|
|
/*
|
|
|
|
|
* The last record appears to have 0 in its "data_length"
|
|
|
|
|
* field, but non-zero values in other fields, so we
|
|
|
|
|
* check for that and treat it as an EOF indication.
|
|
|
|
|
*/
|
|
|
|
|
*err = 0;
|
2013-06-17 21:18:47 +00:00
|
|
|
return FALSE;
|
2013-06-14 23:59:04 +00:00
|
|
|
}
|
2013-12-03 20:35:50 +00:00
|
|
|
length = pletoh16(&hdr.length);
|
|
|
|
|
real_length = pletoh16(&hdr.real_length);
|
2016-04-30 02:04:17 +00:00
|
|
|
/*
|
|
|
|
|
* The maximum value of length is 65535, which is less than
|
Allow bigger snapshot lengths for D-Bus captures.
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-06-05 01:58:40 +00:00
|
|
|
* WTAP_MAX_PACKET_SIZE_STANDARD will ever be, so we don't need to check
|
2016-04-30 02:04:17 +00:00
|
|
|
* it.
|
|
|
|
|
*/
|
2013-06-14 23:59:04 +00:00
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_type = REC_TYPE_PACKET;
|
2021-08-30 02:12:13 +00:00
|
|
|
rec->block = wtap_block_create(WTAP_BLOCK_PACKET);
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->presence_flags = WTAP_HAS_TS|WTAP_HAS_CAP_LEN;
|
2013-06-14 23:59:04 +00:00
|
|
|
|
2013-12-03 20:35:50 +00:00
|
|
|
tm.tm_year = pletoh16(&hdr.date.year)-1900;
|
2013-06-14 23:59:04 +00:00
|
|
|
tm.tm_mon = (hdr.date.month&0x0f)-1;
|
|
|
|
|
tm.tm_mday = hdr.date.day;
|
2013-12-03 20:35:50 +00:00
|
|
|
sec = pletoh32(&hdr.date.sec);
|
2013-06-14 23:59:04 +00:00
|
|
|
tm.tm_hour = sec/3600;
|
|
|
|
|
tm.tm_min = (sec%3600)/60;
|
|
|
|
|
tm.tm_sec = sec%60;
|
|
|
|
|
tm.tm_isdst = -1;
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->ts.secs = mktime(&tm);
|
|
|
|
|
rec->ts.nsecs = pletoh32(&hdr.date.usec) * 1000;
|
2013-06-14 23:59:04 +00:00
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
switch (wth->file_encap) {
|
2013-06-14 23:59:04 +00:00
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ETHERNET:
|
|
|
|
|
/* XXX - is there an FCS? */
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_header.packet_header.pseudo_header.eth.fcs_len = -1;
|
2013-06-14 23:59:04 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case WTAP_ENCAP_LAPB:
|
2018-09-26 00:12:43 +00:00
|
|
|
rec->rec_header.packet_header.pseudo_header.dte_dce.flags = (hdr.dce & 0x1) ?
|
2013-06-14 23:59:04 +00:00
|
|
|
0x00 : FROM_DCE;
|
|
|
|
|
length -= 2; /* FCS */
|
|
|
|
|
real_length -= 2;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_RFC1483:
|
|
|
|
|
/*
|
|
|
|
|
* XXX - is this stuff a pseudo-header?
|
|
|
|
|
* The direction appears to be in the "hdr.dce" field.
|
|
|
|
|
*/
|
Add some higher-level file-read APIs and use them.
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-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(fh, atmhdr, sizeof atmhdr, err,
|
2013-06-14 23:59:04 +00:00
|
|
|
err_info))
|
2013-06-17 21:18:47 +00:00
|
|
|
return FALSE; /* Read error */
|
2013-06-14 23:59:04 +00:00
|
|
|
length -= 8;
|
|
|
|
|
real_length -= 8;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_header.packet_header.len = real_length;
|
|
|
|
|
rec->rec_header.packet_header.caplen = length;
|
2013-06-14 23:59:04 +00:00
|
|
|
|
2013-06-17 21:18:47 +00:00
|
|
|
/*
|
|
|
|
|
* Read the packet data.
|
|
|
|
|
*/
|
|
|
|
|
if (!wtap_read_packet_bytes(fh, buf, length, err, err_info))
|
|
|
|
|
return FALSE; /* Read error */
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
2015-01-02 00:45:22 +00:00
|
|
|
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
static const struct supported_block_type radcom_blocks_supported[] = {
|
|
|
|
|
/*
|
|
|
|
|
* We support packet blocks, with no comments or other options.
|
|
|
|
|
*/
|
|
|
|
|
{ WTAP_BLOCK_PACKET, MULTIPLE_BLOCKS_SUPPORTED, NO_OPTIONS_SUPPORTED }
|
|
|
|
|
};
|
|
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
static const struct file_type_subtype_info radcom_info = {
|
|
|
|
|
"RADCOM WAN/LAN analyzer", "radcom", NULL, NULL,
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
FALSE, BLOCKS_SUPPORTED(radcom_blocks_supported),
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
NULL, NULL, NULL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void register_radcom(void)
|
|
|
|
|
{
|
2021-02-24 03:10:35 +00:00
|
|
|
radcom_file_type_subtype = wtap_register_file_type_subtype(&radcom_info);
|
wiretap: more work on file type/subtypes.
Provide a wiretap routine to get an array of all savable file
type/subtypes, sorted with pcap and pcapng at the top, followed by the
other types, sorted either by the name or the description.
Use that routine to list options for the -F flag for various commands
Rename wtap_get_savable_file_types_subtypes() to
wtap_get_savable_file_types_subtypes_for_file(), to indicate that it
provides an array of all file type/subtypes in which a given file can be
saved. Have it sort all types, other than the default type/subtype and,
if there is one, the "other" type (both of which are put at the top), by
the name or the description.
Don't allow wtap_register_file_type_subtypes() to override any existing
registrations; have them always register a new type. In that routine,
if there are any emply slots in the table, due to an entry being
unregistered, use it rather than allocating a new slot.
Don't allow unregistration of built-in types.
Rename the "dump open table" to the "file type/subtype table", as it has
entries for all types/subtypes, even if we can't write them.
Initialize that table in a routine that pre-allocates the GArray before
filling it with built-in types/subtypes, so it doesn't keep getting
reallocated.
Get rid of wtap_num_file_types_subtypes - it's just a copy of the size
of the GArray.
Don't have wtap_file_type_subtype_description() crash if handed an
file type/subtype that isn't a valid array index - just return NULL, as
we do with wtap_file_type_subtype_name().
In wtap_name_to_file_type_subtype(), don't use WTAP_FILE_TYPE_SUBTYPE_
names for the backwards-compatibility names - map those names to the
current names, and then look them up. This reduces the number of
uses of hardwired WTAP_FILE_TYPE_SUBTYPE_ values.
Clean up the type of wtap_module_count - it has no need to be a gulong.
Have built-in wiretap file handlers register names to be used for their
file type/subtypes, rather than building the table in init.lua.
Add a new Lua C function get_wtap_filetypes() to construct the
wtap_filetypes table, based on the registered names, and use it in
init.lua.
Add a #define WSLUA_INTERNAL_FUNCTION to register functions intended
only for internal use in init.lua, so they can be made available from
Lua without being documented.
Get rid of WTAP_NUM_FILE_TYPES_SUBTYPES - most code has no need to use
it, as it can just request arrays of types, and the space of
type/subtype codes can be sparse due to registration in any case, so
code has to be careful using it.
wtap_get_num_file_types_subtypes() is no longer used, so remove it. It
returns the number of elements in the file type/subtype array, which is
not necessarily the name of known file type/subtypes, as there may have
been some deregistered types, and those types do *not* get removed from
the array, they just get cleared so that they're available for future
allocation (we don't want the indices of any registered types to changes
if another type is deregistered, as those indicates are the type/subtype
values, so we can't shrink the array).
Clean up white space and remove some comments that shouldn't have been
added.
2021-02-17 06:24:47 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Register name for backwards compatibility with the
|
|
|
|
|
* wtap_filetypes table in Lua.
|
|
|
|
|
*/
|
|
|
|
|
wtap_register_backwards_compatibility_lua_name("RADCOM",
|
|
|
|
|
radcom_file_type_subtype);
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-02 00:45:22 +00:00
|
|
|
/*
|
2019-07-26 18:43:17 +00:00
|
|
|
* Editor modelines - https://www.wireshark.org/tools/modelines.html
|
2015-01-02 00:45:22 +00:00
|
|
|
*
|
|
|
|
|
* Local variables:
|
|
|
|
|
* c-basic-offset: 8
|
|
|
|
|
* tab-width: 8
|
|
|
|
|
* indent-tabs-mode: t
|
|
|
|
|
* End:
|
|
|
|
|
*
|
|
|
|
|
* vi: set shiftwidth=8 tabstop=8 noexpandtab:
|
|
|
|
|
* :indentSize=8:tabSize=8:noTabs=false:
|
|
|
|
|
*/
|