out in version 2.1 of the file format (the minimum version to support
that).
Change some data types to avoid having file offsets that are before the
beginning of the file.
Clean up some other data types and some comments.
svn path=/trunk/; revision=39898
100-nanosecond resolution, but that's still better than microsecond
resolution).
For NetMon 1.x format, only claim to support millisecond resolution, as
that's all you get.
Fix handling of negative time deltas in NetMon 2.x format.
When writing a NetMon file, trim the time of the first packet to
millisecond precision to get the capture start time, so that the start
time written to the file (which has millisecond precision) is the same
as the start time used to calculate the deltas written to the packet
headers.
svn path=/trunk/; revision=39886
routines blowing up if handed a too-large time_t.
While we're at it, also check for dates that can't be represented in DOS
format (pre-1980 dates).
svn path=/trunk/; revision=39883
link" records, including stuff that's from a G.704 PRI frame but not
from a D or H channel in that frame. Handle them (currently, we ignore
them).
The low-order bit of the flags field for "packet" records" is "network
to user" (NT->TE), not "user to network" (TE->NT).
svn path=/trunk/; revision=39663
bytes of what we thought was a version string appears to be an 8-byte
record of some sort in the captures we originally looked at, and appears
to be a non-8-byte record in another capture. If we treat that as a
record, the version string field appears to be null-padded and 41 bytes
long.
svn path=/trunk/; revision=39645
might be a record type, with 0 being a "Stop Monitor" record and 1 being
a packet. Ignore records other than packet records.
svn path=/trunk/; revision=39590
software. More work is needed:
we don't know where the capture start time is yet;
we aren't handling the "stop capture" record;
we don't know where the ISDN channel is;
there might be non-ISDN file formats;
but this at least is easier than trying to text2pcap hex dumps from that
software into pcap files.
svn path=/trunk/; revision=39588
I found a heap-based buffer overflow, when parsing ERF file format.
The overflow seems to be controlled by the values read from the file,
and hence seems exploitable to me.
svn path=/trunk/; revision=39508
This patch extends the ATM parser so as to allow GPRS NS traffic encapsulated
in ATM AAL5.
Additionally, added support for this into the 'Meta' dissector.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6447
svn path=/trunk/; revision=39394
First bug: The Network Instruments Observer file format abbreviation is
incorrect. It is "niobserverv" instead of "niobserver", which is probably a
vestige from 1.4 when the abbreviation was "niobserverv9".
Second bug: The packet header magic number field is correctly swapped the first
time when reading the entire packet header. It is incorrectly swapped yet again
when reporting an invalid value. Both swaps use GUINT_FROM_LE, which is a no-op
on little-endian platforms. But the error message that is displayed to users of
big-endian platforms will contain a byte-reversed value.
svn path=/trunk/; revision=39392
Allows the saving of packets with snapped length to ERF. Prevents the adding of
automatic CRC and rounds down to the nearest 8 bytes instead of up, adding
zeros.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6409
svn path=/trunk/; revision=39247
same.
Add to wiretap/pcap-common.c a routine to fill in the pseudo-header for
ATM (by looking at the VPI, VCI, and packet data, and guessing) and
Ethernet (setting the FCS length appropriately). Use it for both pcap
and pcap-ng files.
svn path=/trunk/; revision=38840
Set the pseudo-header when doing the sequential read as well as when
doing random reads.
When writing packets to a CommView file, use a slightly less contorted
way to get the year/month/day/hour/minute/second values.
commview_dump() uses the pseudo_header argument; don't mark it as
unused.
svn path=/trunk/; revision=38833
know it'll fit in a gint16. (alignbytes really shouldn't need to be 64
bits, as if we have 2^63-1 bytes of alignment, We Have A Problem; fixing
that may involve calculating it differently earlier in that routine.)
svn path=/trunk/; revision=38828
which we read the data to be written doesn't record the snapshot
length". A snapshot length of 0 in a pcap or pcap-ng file is not
handled well by many programs reading those files; for pcap files, we
write out WTAP_MAX_PACKET_SIZE as the snapshot length in that case, so
do so for pcap-ng files as well.
svn path=/trunk/; revision=38790
If an EnhancedPacketBlock in a pcapng file contains a comment option the
content isn't displayed. Instead "Malformed packet" is displayed with the
reason Exception occurred.
The reason for the problem is a bug in the pcapng.c, where for enhanced packet
blocks, interface description blocks and interface statistics blocks the wrong
union members are used to set the comment. This way required fields in the
structures are overwritten.
The attached patch solves the problem.
svn path=/trunk/; revision=38491
header bytes read, as we're reading the two header fields separately and
checking the byte count for each read. We *do*, however, know that the
record header is 4 bytes long, so we can just seek back 4 bytes.
svn path=/trunk/; revision=37953
Guy Harris