I have taken a look at the trace myself and calculated the TpS to be
20000000.0 for this particular trace. If I also discard the start_timestamp
like it has been done for other versions of the netxray format, then I get
the proper results.
svn path=/trunk/; revision=17869
Sniffer V2 format capture files with captyp=5, timeunit=0.
The ticks_per_sec for this case apparently is 1e6.
Bill Meier
svn path=/trunk/; revision=17019
define "timezone" as "gint16", as it can be positive (west of
UTC) or negative (east of UTC);
update comments to refer to the new names for structure members;
say the precision of the time stamps is 1 nanosecond only if the
ticks per second is > 10 million;
fix the handling of files truncated exactly on a frame boundary.
svn path=/trunk/; revision=15739
1. Use the new (good work!) 'nanosec' precision only for gig pods;
2. Rework 'struct netxray_hdr' to make it (somewhat) easier
to maintain and revise:
a. Declare known hdr fields such as 'captype' instead
of using offsets in 'xxx placeholder' fields.
d. Define 'unknown' hdr fields using placeholder names
based upon hex-offset in the netxray header record.
(This isn't perfect, but I hope it will make things
more manageable).
3. Update hdr field info (based upon examination of various
capture files):
a. Define a hdr field which appears to be 'time-zone'
[offset in hours from UTC] for the machine doing
the capture.
(Maybe this field can eventually be used for Ethereal
to display the (local) time as it was at the time
of the capture).
b. Describe certain hdr fields as being "file offsets"
(altho the exact use is still unclear).
Update some comments.
svn path=/trunk/; revision=15603
- automatic adjustment depending on file format
- manual adjustment through menu items
save the setting in the recent file
svn path=/trunk/; revision=15534
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...
What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.
As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.
Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...
As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...
svn path=/trunk/; revision=15520
traffic as well as Frame Relay traffic, and give some information about
the cruft found in the xxc field of the header for one CHDLC and one FR
capture.
svn path=/trunk/; revision=14659
FCS" bit for 802.11, just as it appears to be for Ethernet, and give
more details on the 4 bytes of junk at the end of the packet (i.e., that
we haven't yet seen an 802.11 capture where it's an FCS rather than just
junk).
svn path=/trunk/; revision=13028
specific to particular types of captures, and the same value might
correspond to more than one CAPTYPE_ definition.
Add an additional CAPTYPE_ for some non-gigabit Ethereal capture seen by
Bill Meier, and fix the range check the time stamp units value as per
his mail.
svn path=/trunk/; revision=12937
a number of Windows Sniffer captures - apparently the time stamp units
are in a field in the file header.
Add a capture type value seen in at least one ATM capture.
Update some comments, and add some comments.
Get rid of some redundant setting of "timeunit".
svn path=/trunk/; revision=12936
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
rather than requiring individual capture file type handlers to do it
(unless they're doing per-packet encapsulation, in which case we check
to make sure they didn't *leave* it as WTAP_ENCAP_PER_PACKET).
svn path=/trunk/; revision=10290
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
0 means "there is no FCS in the packet data", 4 means "there is an FCS
in the packet data", -1 means "I don't know whether there's an FCS in
the packet data, guess based on the packet size".
Assume that Ethernet encapsulated inside other protocols has no FCS, by
having the "eth" dissector assume that (and not check for an Ethernet
pseudo-header).
Have "ethertype()" take an argument giving the FCS size; pass 0 when
appropriate.
Fix up Wiretap routines to set the pseudo-header. This means we no
longer use the "generic" seek-and-read routine, so get rid of it.
svn path=/trunk/; revision=8574
the network type being 1 and the byte after it being 2; we assume, for
now, that the network type is 1 byte, and that if the byte after it is
0, the network type is an NDIS type - 1, and if it's 2, it's an NDIS type.
svn path=/trunk/; revision=7973
aren't 1/1193000.0 second; the code used to use 1/1193180.0 second, but
at least one capture appears to have units of somewhere around
1/3579540.0 second.
svn path=/trunk/; revision=7388
2 the time stamps are in units of 1/31250000 seconds rather than
nanoseconds - and, by generating Windows Sniffer captures with various
hdr.timeunit values, that for all the non-zero values he tested, the
time stamps for non-gigabit pod captures are in units of 1/1193000
second.
Instead of having a TpS array, just test for the exception value (0 for
non-gigabit pod captures, 2 for gigabit pod captures).
svn path=/trunk/; revision=7380
Add a bunch of capture types discovered by stuffing them into Windows
Sniffer captures and seeing what a Sniffer thought they were. Add
support for writing at least some of them.
svn path=/trunk/; revision=7265
it's a gigabit Ethernet capture, possibly, with special hardware, and
that time stamps have 1000 times the resolution that they have in other
captures (perhaps due to the special hardware having a higher-resolution
clock?).
svn path=/trunk/; revision=7240
that have direction information.
Support writing WTAP_ENCAP_FRELAY_WITH_PHDR and WTAP_ENCAP_PPP_WITH_PHDR
captures out in libpcap format - we throw away the direction
information, but so it goes.
When reading/writing Windows Sniffer format, read and write the
direction flag.
svn path=/trunk/; revision=7052
that flag in the ATM pseudo-header, and use it to determine whether a
frame is a raw cell or a reassembled frame, rather than using the AAL,
as you can have raw AAL5 cells in a capture.
svn path=/trunk/; revision=6889
number.
Put in some commented-out code to deal with some end-of-packet crud in
some ISDN captures - not all ISDN captures have it, so we can't
unconditionally slice it out.
svn path=/trunk/; revision=6863
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
WTAP_ENCAP_ISDN encapsulation type, which includes a pseudo-header
giving the direction (user-to-network or network-to-user) and the
channel number.
Add a new circuit type, using the ISDN channel number as the circuit ID.
Add an ISDN dissector to put the direction and channel number into the
protocol tree and to call the appropriate dissector for the payload
based on the channel (LAPD for the D channel; V.120, PPP, or data for B
channels, based on some heuristics).
svn path=/trunk/; revision=6521
unknown bytes might actually be 32-bit fields.
The field after the upper 32 bits of the time stamp of the capture start
appears to be the speed of the network, in bits/second.
Put in a field for the rest of the file header, as a bunch of 32-bit
values (most fields are 32 bits, and all of them might be, in that
header), for use when reverse-engineering.
At least in version 002.x of NetXRay-format captures, WAN captures might
be ISDN captures; treat all WAN version 002.x captures as ISDN captures
for now, until we see some captures where that's wrong (and thus stand a
chance of figuring out where in the file header it indicates what type
of capture it is).
svn path=/trunk/; revision=6519
Jaap Keuter