buttons insensitive if "Print summary" is selected, and make them
sensitive if "Print detail" is selected, as they apply only to the
"print detail" output.
svn path=/trunk/; revision=672
the "File/Print" dialog box; "Expand all levels" means that all levels
of the protocol tree should be printed, while "Print as displayed" means
that only those levels shown in the display should be printed.
Free the table of column widths once printing is done.
svn path=/trunk/; revision=671
ourselves; that means we don't have to duplicate the stuff
"dissect_data()" does (including saying "1 byte" rather than "1 bytes" -
"dissect_data()" does that, but we weren't doing that), and also means
that when you print a packet, the data gets dumped.
svn path=/trunk/; revision=670
packet-lapb.c :
check the validity of the first byte in the frame.
packet-x25.c :
- in get_x25_pkt_len() : check that we are not reading after the end of
the captured data
- in dissect_x25() : various checks to avoid reading after the end of
the captured data
- in dissect_x25() : use offset (and not 2) as the length of the
underlying protocol header.
Olivier
svn path=/trunk/; revision=669
not like #preprocessor_macros that do not start at
the first column.
So write:
#ifdef FOO
# include <dummy1.h>
# define DUMMY 1
#else
# include <dummy2.h>
# define DUMMY 2
#endif
instead of
#ifdef FOO
#include <dummy1.h>
#define DUMMY 1
#else
#include <dummy2.h>
#define DUMMY 2
#endif
svn path=/trunk/; revision=668
prints the protocol tree, and summary prints the fields in the summary
clist, with a header line at the beginning of the printout.
Print only packets selected by the current packet filter.
Just have "ARP" and "RARP" in the "Protocol" field for ARP packets;
whether it's a request or a reply can be seen in the "Info" field.
Add to the "Frame" section of the protocol tree the time between the
current packet and the previous displayed packet, and the packet number.
Have FT_RELATIVE_TIME fields be a "struct timeval", and display them as
seconds and fractional seconds (we didn't have any fields of that type,
and that type of time fits the delta time above).
Add an FT_DOUBLE field type (although we don't yet have anything using
it).
svn path=/trunk/; revision=666
now in "gtk/capture_dlg.c" - so it doesn't need to include
<sys/sockio.h> on, for example, Solaris...
...but "gtk/capture_dlg.c" does need to include it.
"gtk/capture_dlg.c" also may need to include "snprintf.h", as it uses
"snprintf()".
svn path=/trunk/; revision=655
family has a set of debug commands that allow you to log the traffic on a
WAN or dialup connection as text, e.g.
RECV-iguana:241:(task: B04E12C0, time: 1975358.50) 15 octets @ 8003D634
[0000]: FF 03 00 3D C0 06 C9 96 2D 04 C1 72 00 05 B8
Created wtap_seek_read() which parses the textual data for and Ascend
trace, and does a normal fseek() and fread() for any other file type.
The fseek()/fread() pairs in file.c were replaced with the new function.
svn path=/trunk/; revision=652
Move some defines that would be used even by a non-GTK+-based Ethereal
from "gtk/main.h" to "globals.h".
Remove the byte-order #defines from "packet.h", as they're now in
"globals.h" (having been moved there from "gtk/main.h").
Fix up some files that use those #defines to include "globals.h".
"resolv.c" doesn't use any GTK stuff, so it needn't include <gtk/gtk.h>
nor "gtk/main.h" - it only did so to get the byte-order #defines for the
benefit of "packet-ipv6.h", and "packet-ipv6.h" now includes them
itself.
svn path=/trunk/; revision=649
- that event happens if, say, you nuke the dialog box from a window
manager - and call "delete" routines for each of the preferences tabs,
so that, for preferences tabs that include list widgets, we can set a
flag on the preferences tab widget telling the selection callback for
the list widget that the buttons it would normally set the sensitivity
of, based on whether any row in the list is selected or not, have Joined
the Choir Invisible, and therefore that we shouldn't change their
sensitivity because GTK+ will whine at us if we do, just as is the case
if we press the "OK" or "Cancel" button (which also cause the window to
go away).
Can we just do this in the "window delete" handler? I.e., does that get
called if we explicitly destroy the widget? Or should we catch a
"destroy" event instead?
(There must be a better way to do this....)
svn path=/trunk/; revision=647
doesn't know about, and eliminate the check in "dissect_fddi()" where we
check if its return value was NULL and, if so, print "Unknown frame
type".
svn path=/trunk/; revision=644
is passed to col_add_str, which is then passed to strncpy, which, at least
in glibc 2.1, doesn't like NULL pointers passed to it in lieu of empty
strings.
svn path=/trunk/; revision=643
this causes "Makefile.in" to have two GPL notices - "Makefile.in" and
the "Makefile" generated from it are generated files, so maybe that's
OK).
svn path=/trunk/; revision=639
this causes "Makefile.in" to have two GPL notices - "Makefile.in" and
the "Makefile" generated from it are generated files, so maybe that's
OK).
svn path=/trunk/; revision=638
box interfaces we can't open; this filters out loopback interfaces on
e.g. Solaris (which you can't get at with a DLPI device, so you can't
capture traffic on them), and also means we don't report *any*
interfaces if you don't have permission to open any (which means you
don't have permission to capture packets).
If we don't find any interfaces, pop up a message box saying so.
Free up the interface "ioctl" buffer, and close the socket we were
using, before returning from "get_interface_list()".
If "get_interface_list()" returns a null pointer (meaning it failed),
don't pop up the "capture" dialog box.
svn path=/trunk/; revision=634
Frame protocol (that being what this dissects).
If you're cutting up something into bitfields, the bitfield dissection
returned by "dissect_bitfield_XXX()" should be the first text on the
line - if not, then if the text items that come before the various
bitfields aren't all the same length, the bits don't line up.
Cope with packets from one of Gilbert's captures, where the sender
"name" in some NBF datagrams isn't a NetBIOS name, it's 10 octets of 0
followed by a MAC address!
The "name type" in the "Data2" field of NBF frames is 0x00 for unique
names and 0x01 for group names, not a "16th character of a NetBIOS name"
name type.
Fix up various other things.
svn path=/trunk/; revision=633
(NWLink), are sufficiently different that they should be handled in
different routines.
Change the decode to match NetMon a bit more.
svn path=/trunk/; revision=631
to turn NetBIOS names into a nice printable form.
Put the description of NetBIOS name types into places where it fits;
have "packet-netbios.c" export a routine to interpret them.
svn path=/trunk/; revision=630
Guy Harris