Following my last submitted patch I did some further investigation on the different types of iSeries Comms Traces, although the field formats are constant, things such as page throws and line spacing vary depending on the tool used to pull the trace form the iSeries spool.
This patch should better handle the different formats and more importantly exit in a graceful manner if an unknown format is encountered.
svn path=/trunk/; revision=17699
The attached patch adds support for LAPD frames captured using vISDN thru
libpcap. The support has already been included in libpcap.
The patch adds a new wiretap encapsulation, the necessary glue to decode
SLL-encapsulated frames, and some minor change in the LAPD dissector in order
to support the remote-to-remote frames captured on the ISDN E-Channel.
Please apply ethereal-encap-table.diff before, as it fixes a misalignment in
the encapsulation names table.
svn path=/trunk/; revision=17450
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
tethereal internally converted the stdout capture filename "-" into "" which doesn't make any real sense and only complicated things.
To make things even more confusing, wiretap expected "" for dump output and "-" for offline reading ...
svn path=/trunk/; revision=16962
was that file_util.h wasn't in the distribution tarball, so it couldn't
be included - it handles including <sys/stat.h>.
svn path=/trunk/; revision=16423
argument, rather than requiring the caller to get the open() flag and
the fopen() flag in sync. That also means that if we're *not* using
libz, it can just be a wrapper around eth_fopen().
We need to include <fcntl.h>, at least on UN*X, to get open() declared
and the O_ flags defined.
svn path=/trunk/; revision=16409
to do this, I've added file_util.h to wiretap (would file_compat.h be a better name?), and provide compat_macros like eth_open() instead of open(). While at it, move other file related things there, like #include <io.h>, definition of O_BINARY and alike, so it's all in one place.
deleted related things from config.h.win32
As of these massive changes, I'm almost certain that this will break the Unix build. I'll keep an eye on the buildbot so hopefully everything is working again soon.
svn path=/trunk/; revision=16403
status field bits".
Check for "Internetwork analyzer" captures by checking the Sniffer
network type, and save that type rather than just an "ATM or not" flag
in the private data.
svn path=/trunk/; revision=16283
non-zero value - it's only set from file formats that provide it in a
per-packet header, and only the old DOS Sniffer did so, so it's zero for
all other capture types. Instead, check the actual packet data length.
Also check it against 16; 14 bytes isn't large enough for a LANE
Ethernet frame.
svn path=/trunk/; revision=16261
correct a bug in parsing Lucent/Ascend PPP dumps. Basically, blobs with "PPP-OUT" should be labelled "PPP transmit" while blobs with "PPP-IN" should be labelled "PPP receive". The current code labels them the other way around.
packet-ppp.c
- Properly decode option to enable ECRTP (it wasn't decoded).
- Use the ipv6 knob to control ipv6 decoding (previously, it
was using the ipv4 knob).
svn path=/trunk/; revision=16194
In the bssgp an IE was decoded as mobile identity and should be decoded as (p)tmsi only.
The patch is attached to this email. It also consists the new atm patch which was send yesterday.
svn path=/trunk/; revision=16146
Ethernet packets with a length field as LANE packets, and doesn't do so
for packets that appear to be LANE-encapsulated Ethernet packets with a
type field, is too weak. Back out that part of the heuristics added in
the previous checkin.
svn path=/trunk/; revision=16111
Due to the fact that 3G Signaling appears at an undefined VPI/VCI I added a heuristics (very simple) which should take care of this fact.
svn path=/trunk/; revision=16108
patch to support 4 additional juniper DLTs.
all those are wrappers for exisiting media types augmented with meta-information which gets also displayed using this patch;
svn path=/trunk/; revision=15908
currently limited to Ethereal and all the variants of libpcap filetypes only.
We might want to add output compression support to the other tools as well (tethereal, mergecap, ...).
We might also want to add support for the other filetypes, but this is only possible if the filetype functions doesn't use special output operations like fseek.
One bug is still left: if the input and output filetypes while saving are the same, Ethereal currently optimizes this by simply copy the binary file instead of using wiretap (so it will be faster but it will ignore the compress setting).
Don't know a good workaround for this, as I don't know a way to find out if the input file is currently compressed or not. One idea might be to use a heuristic on the filesize (compared to the packet size summmary). Another workaround I see is to remove this optimization, which is of course not the way I like to do it ...
svn path=/trunk/; revision=15804
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
Camel: Fix an off-by-one error. Don't alloc and free where it's not
needed. Remove an unused variable.
PPP and K12: Fix memory leaks.
svn path=/trunk/; revision=15725
The file format stays the same as the common libpcap format, only the lower part of the timestamp field uses nanoseconds instead of microseconds.
This file format uses the libpcap magic number 0xa1b23c4d.
svn path=/trunk/; revision=15623
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
G_HAVE_GINT64.
Get rid of the floating-point stuff in the Etherpeek Classic file
reading code, just use 64-bit integers. Fix up the calculation of the
nanoseconds portion of the time stamp.
svn path=/trunk/; revision=15544
