- It accepts the "/" character in interface names
- It accepts EOF as delimiter for the last packet (when there is no more emptyline)
svn path=/trunk/; revision=22765
Use G_GINT64_CONSTANT() to make a 64-bit integral constant; not all
compilers we use support LL as a suffix for that (MSVC++ 6, for one).
svn path=/trunk/; revision=22580
This patch adds support for the Juniper NetScreen snoop output format.
It takes a text-dump op the captured packets and parses the headers
and hex-data. Since the snoop files on a Junpiper NetScreen can be saved
to a tftp-server, this patch makes it quite easy to use the snoop
function of the Juniper NetScreen firewalls.
/* XXX TODO:
*
* o Create a wiki-page with instruction on how to make tracefiles
* on Juniper NetScreen devices. Also put a few examples up
* on the wiki (Done: wiki-page added 2007-08-03)
*
* o Use the interface names to properly detect the encapsulation
* type (ie adsl packets are now not properly dissected)
* (Done: adsl packets are now correctly seen as PPP, 2007-08-03)
*
* o Pass the interface names and the traffic direction to either
* the frame-structure, a pseudo-header or use PPI. This needs
* to be discussed on the dev-list first
* (Posted a message to wireshark-dev abou this 2007-08-03)
*
*/
svn path=/trunk/; revision=22533
1) "-e" isn't supported by good old /bin/sh, so we use "-r"
instead;
2) "The algorithm for determining the precedence of the
operators and the return value that will be generated is
based on the number of arguments presented to test", so we
explicitly parenthesize.
svn path=/trunk/; revision=22448
such as the fact that Flex strips all but the last component of the "-o"
argument, and that it doesn't generate a header file to declare routines
the generated lexical analyzer defines. Use that script when building
lexical analyzers, and, for each lexical analyzer, include the generated
header file in the generated analyzer.
svn path=/trunk/; revision=22446
Makefile.nmake files; currently, it has the (F)lex-to-C rule and a
.SUFFIXES pseudo-rule to add .l to the list of suffixes. Have
Makefile.nmake files with .l.c rules include Makefile.nmake.inc to get
that rule.
The names Makefile.am.inc and Makefile.nmake.inc aren't necessarily the
right names for the files in question.
Use $(PACKAGE) in the Mate plugin's Makefile, rather than "mate".
svn path=/trunk/; revision=22437
Makefile.am files; currently, it has the (F)lex-to-C rule. Have
Makefile.am files with .l.c rules include Makefile.am.inc to get that
rule.
svn path=/trunk/; revision=22436
Move the %options to the beginning if they weren't already there, and
put them in the same order in all files.
Add "prefix=" options to .l files that don't already have them, so we
don't have to pass a "-P" option.
Add "never-interactive" and "noyywrap" options to our lexical analyzers,
to remove extra isatty() checks and to eliminate the need for yywrap()
from the Flex library.
Get rid of %option nostdinit - that's the default.
Add .l.c: rules to Makefile.am files, replacing the rules for specific
.l files. Have those rules all check that $(LEX) is set.
Update the address for the FSF.
svn path=/trunk/; revision=22424
a source release tarball without having Flex (think of a source release
tarball being as much a platform-independent distribution format for
people *not* interested in development, and who are on platforms for
which there aren't binary packages, as a way of getting the source to do
development). Don't check Flex's capabilities in the configure script
(handling reentrant scanners would have to be done differently).
svn path=/trunk/; revision=22414
Its argument, however, needs to be cast to "guchar", so that if the
high-order bit is set, it doesn't get sign-extended.
svn path=/trunk/; revision=22303
The encap_table_base in wcap.c is missing an entry.
This causes e.g. "dumpcap -i usb3 -L" to output:
Data link types (use option -y to set):
USB_LINUX
(MPEG)
svn path=/trunk/; revision=22292
The code for reading ERF files has not been significantly
updated since 2004. This patch brings it up to date with a
number of changes.
1) Increase number of decodable ERF types from 7 to 12. This
covers newer DAG card models and firmware updates.
2) Fix timestamp conversion. Was calculating only microsecond
precision, now displaying with nanosecond resolution. Hardware
precision is 7.5 to 30 ns depending on model.
3) Allow the user to specify HDLC encapsulation as 'chdlc',
'ppp_serial', 'frelay' or 'mtp2'. This is needed because the
ERF HDLC capture formats do not include information on what
protocol is used at the next level. This is currently done via
an environment variable 'ERF_HDLC_ENCAP' and is analagous to the
existing 'ERF_ATM_ENCAP' variable.
If the user does not specify an HDLC encapsulation it tries to
guess, and falls back to MTP2 for backwards compatibility with
Florent's existing behaviour.
I know environment variables are ugly, suggestions are welcome.
4) When reading HDLC captures as MTP2, use
WTAP_ENCAP_MTP2_WITH_PHDR rather than WTAP_ENCAP_MTP2. This
allows us to put the 'Multi-Channel ERF' record 'channel
number' field into the MTP2 pseudo header > 'link_number'
field. This is then displayed in Frame information, and can
be filtered on. (Would be nice if it could be made a display
column?)
Because the ERF record does not specify whether Annex A is used
or not, we pass MTP2_ANNEX_A_USED_UNKNOWN and allow the existing
user preference to decide.
Move the MTP2_ANNEX_A_ definitions into Wiretap, make the annex_a_used
field a guint8, and change MTP2_ANNEX_A_USED_UNKNOWN to 2 so it fits in
a guint8. (This means that if you can save an ERF MTP2 file as a
libpcap file, the pseudo-header will have MTP2_ANNEX_A_USED_UNKNOWN in
it.)
svn path=/trunk/; revision=22067
network type; there's no "presumably" about it.
Suggest that "realtick" might have the right time stamp in other cases
(if not, a comment should explicitly indicate that, so that in all cases
where we either know that realtick is wrong or have a lot of evidence to
show that it's right, we note that fact).
svn path=/trunk/; revision=21996
Fix compilation failures when building wireshark-0.99.6-SVN-21916 on an
x86_64-unknown-linux-gnu target with gcc version 4.1.2 20070403 (Red Hat
4.1.2-8).
The failures fall into two categories:
(1) Casts between pointers and 32-bit integers without an intermediary cast
via 'long' or 'unsigned long'. This results in a compiler warning complaining
about casts between a pointer and an integer of a different size.
(2) Passing values to "%lld" or similar printf-style format options that the
compiler thinks are a different size. Such values need to be cast to 'long
long' or 'unsigned long long'.
svn path=/trunk/; revision=21975
possibly-unaligned pointers, and turn on -Wcast-align so at least some
future code that does that will fail to compile.
svn path=/trunk/; revision=21968
what the complete set of warnings we should either try to fix or, for
cases where it can't be fixed, turn off or or avoid -Werror for. I'll
revert this change as soon as a complete set of buildbot builds start
with it.
svn path=/trunk/; revision=21917
libraries. A single library is generated with the lex code without the barrier
"stop on warning". An other library is generated from the remaining source
files with the "stop on warning" barrier.
svn path=/trunk/; revision=21817
Since wiretap.h is not autogenerated, just make wtap-plugins.h include
the top level config.h to pull in the defines for HAVE_DIRENT which was
checked at top level
svn path=/trunk/; revision=21707
So far I've done only regression testing (the new functionality and what's in wtap-plugins.c has not yet being tested).
it is a first step in the way to have lua opening files.
svn path=/trunk/; revision=21686
--enable-warnings-as-errors (if any tests enabled by
--enable-extra-gcc-checks are safe to treat as errors, they're safe to
turn on by default).
svn path=/trunk/; revision=21515
on some platforms due to unfixable problems (e.g., crappy vendor
headers), we can move them back to the "extra" list.
Put those warnings in the order in which they appear in the GCC man page
on my machine.
If we turn on -pedantic, try turning on -Wno-long-long as well, so that
it's not *so* pedantic that it rejects the 64-bit integral data types
that we explicitly require.
svn path=/trunk/; revision=21514
Add -Wpointer-arith to the GCC -W flags by default.
Make "extra-gcc-checks" and "warnings-as-errors" --enable flags rather
than --with flags - autoconf's model is that --enable is for turning
features on or off, --with is for enabling or disabling the use of
external packages (libpcap, Net-SNMP, GNU ADNS, etc.).
When testing whether the compiler is GCC, use the same style all the
time - check whether "x$GCC" equals "xyes". (The "x" might be overkill
- if you don't quote the arguments, it avoids a missing argument to
"test"/"[", but if you do, it might not be needed.)
svn path=/trunk/; revision=21492
Check for a case where, conceivably, the on-the-wire packet length (from
the IP header) could be shorter than the captured data length (due to
Ethernet padding), and handle it by making sure the on-the-wire length
is always >= the captured data length.
svn path=/trunk/; revision=21490
Ulf Lamping