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
and "Statistics" menu items into "stat.h" and "stat.c", to separate them
from the core tapping APIs. A tap could conceivably not register as a
"-z" command-line argument or "Statistics" menu item, and a stat could
conceivably not be implemented as a tap, and dissectors that implement
tapping points don't need the UI-related stuff from "stat.h", they just
want the tap-related stuff in <epan/tap.h>.
svn path=/trunk/; revision=15427
_U_-ify some unused arguments, rather than assigning them to themselves.
Un-constify one variable that gets assigned a mallocated pointer.
Clean up indentation.
svn path=/trunk/; revision=15236
sure we're not referencing a fid when we think we're referencing an
smb_nt_transact_info_t pointer. (A fuzzed capture I have triggers
this behavior).
svn path=/trunk/; revision=14107
it's used to register a callback for a tap listener invoked if the
specified command line argument is specified to the "-z" flag.
Move it, along with routines to:
look up a "-z" argument in the table constructed by
"register_tap_listener_cmd_arg()" and either save the full
argument to "-z" and the corresponding listener if it's found or
return a failure indication if it isn't;
list the available tap listeners;
call the "init" routines for the tap listeners saved in the
table above;
and have Ethereal and Tethereal use those routines.
svn path=/trunk/; revision=13993
object code for libethereal.dll isn't generated by the
makefile in /trunk.
Having no code in /trunk linked into libethereal.dll
anymore, the definition of the macro _NEED_VAR_IMPORT_
can be moved from various source files in /trunk to /trunk/Makefile.nmake .
So do that, too.
svn path=/trunk/; revision=13389
const pointer (so that we don't get complaints when we make the
tap-specific data argument to "tap_queue_packet()" a const pointer,
allowing dissectors to hand const data to a tap without a complaint), we
should make the tap per-packet function take a const pointer as an
argument as well. Do so.
In some taps, use _U_, or actually use the argument, rather than
sticking in dummy "X = X" assignments to fake use of parameters. (This
means that the tap functions in question no longer have the notion that
they act on a particular static structure wired in.)
svn path=/trunk/; revision=12910
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
add a config.nmake option to control whether to build
libethereal.dll or not;
remove "./wiretap" from PATH to prevent problems due to
wrongly-loaded files;
build dissector.lib with MSVC;
move "print.c" and "ps.c" to the dissector helpers, as "print.c"
imports variables from packet-frame.c and packet-data.c, which
are in libethereal;
move "g711.c" out of the dissector helpers, as they're used only
by Ethereal in a tap, not in Tethereal or in any dissector;
add a .def file for libethereal;
arrange to declare global variables exported from libethereal
with "__declspec(dllimport)" when building programs that import
those variables;
update the NSIS installer.
Make the "configure" script define ETH_VAR_IMPORT as "extern".
svn path=/trunk/; revision=10834
For short packets, we might not have enough of the payload to decode
the transaction info levels and thus that data structure is NULL.
check the pointer to this struct first before we try to dereference it.
svn path=/trunk/; revision=8558
Filter dialog for the MGCP statistics tap.
Routines for building GUI table displays for statistics taps.
Use the timestats.c routines in the SMB statistics tap.
svn path=/trunk/; revision=7561
referring to a GString containing an error message on failure, and don't
have it print anything on failure.
If it fails, have its Tethereal-tap callers print an error message
before exiting, and have its Ethereal callers pop up a dialog box with
the error (except in cases where the failure is guaranteed not to be the
user's fault, and where we exit, in which case we just print an error
message before we exit). In all cases, the error message includes the
text of the GString.
Fix a scanf format string in the DCE RPC statistics Ethereal tap, so
that it properly skips the comma before the filter string.
Fix some Ethereal error messages not to say "tethereal".
svn path=/trunk/; revision=7542
registration routines, for taps with menu items (taps that can be run
from the "Tools->Statistics" menu), create the menu item for the tap.
"make-tapreg-dotc" constructs a "register_all_tap_menus()" function that
calls all the tap menu item registration routines it finds, and Ethereal
calls that routine after the main window has been constructed (so that
the main menu exists, as the menu items are added to it). (Tethereal
doesn't call it.)
Get rid of the "menu" and "menu_init" arguments to
"register_ethereal_tap"; the menu item is registered in the tap's menu
item registration routine, not in its main registration routine.
Have the RTP GUI tap register its menu item that way, rather than by
having it compiled into "gtk/menu.c". (We're not ready yet to have taps
whose menu items are under a submenu register themselves in that
fashion, as "register_tap_menu_item()" can't yet create submenus.)
svn path=/trunk/; revision=7540
Ulf Lamping