"file.c" to "packet.c"; it's not really related to file access (or to
manipulating the packet list as a whole, which much of the stuff in
"file.c" is really for), but is more related to analyzing packets, and
moving it to "packet.c" lets me build an experimental "line-mode" flavor
of Ethereal (based on Gilbert's "tethereal" experiment) - "line-mode"
means "like tcpdump or snoop" - without having to drag in "file.c" and a
pile of GUI stuff.
svn path=/trunk/; revision=1388
that you don't have to have "gtk/prefs_dlg.c" to get it defined - future
non-GTK (text mode, curses, etc.) programs wouldn't have it.
svn path=/trunk/; revision=1387
"value_string" array for OUIs.
Add the OUI for the ATM Forum to that list.
Handle the OUI for the ATM Forum in the layer 3 information for ISO TR
9577 in a Broadband Low Layer Information information element (for ATM
LANE).
Add an initial version of the dissection of TLV values in LANE LE
Control frames (I have no frames with TLV values against which to test
it, alas).
svn path=/trunk/; revision=1385
Ethereal (it didn't appear to be necessary when I tried it). It may be
necessary if you're going to do development, but the same applies to
"automake" and "autoconf" - we should document that somewhere, giving
the minimum versions required.
svn path=/trunk/; revision=1384
Make the default plugindir $(libdir)/ethereal/plugins/0.8. Ethereal now
looks for plugins in the following directories:
/usr/lib/ethereal/plugins/0.8
/usr/local/lib/ethereal/plugins/0.8
$plugindir (if different from above)
$HOME/.ethereal/plugins
svn path=/trunk/; revision=1382
currently in CVS and that we may no longer need a fancier widget for the
"About" box as we've removed the list of authors from that box.
svn path=/trunk/; revision=1380
and 9.x, "libpcap-0.4" should, in theory, do the right thing; stuff may
be different on HP-UX 11.x, and "libpcap-0.4" may not do the right
thing, obliging you to use "dlpiN" devices in Ethereal.
svn path=/trunk/; revision=1378
Don't use a global variable named "gmtime" - some versions of
NetBSD define it in <time.h> - use "_gmtime" instead, so we can
build on those NetBSD systems.
svn path=/trunk/; revision=1375
dialog box if we hadn't found any interfaces on which we could capture,
but perhaps the problem was that "gtk_combo_set_popdown_strings()"
doesn't like it if you set the list of items to a NULL list - if you
don't set it at all, you get a combo box with only one blank entry in
the list, but you don't seem to get complaints from GTK+ 1.2.6, at
least.
Pop up the "Capture:Start" dialog box even if we don't find any
interfaces on which we could capture; at least this way, they won't just
get confronted with a
There are no network interfaces that can be opened.
Please check to make sure you have sufficient permission
to capture packets.
message box and no way to give us any more information other than "it
said 'There are no network interfaces that can be opened...'" - they can
at least try the interfaces that *should* work, and report the error
messages they get, giving us a better chance at figuring out what the
problem is.
Trim white space from the entry in that combo box, and, if there isn't
anything other than possibly white space, pop up a
You didn't specify an interface on which to capture packets.
message box and leave the dialog box up so that the user can supply an
interface name.
svn path=/trunk/; revision=1373
color filter" dialog boxes do all the destruction of dialog boxes popped
up from the dialog box being destroyed; have the callbacks for "OK" and
"Cancel" just destroy the dialog box in which they appear - the
"destroy" callback will then be called and do the rest of the cleanup.
svn path=/trunk/; revision=1364
foreground or background color selection dialogs and, if we're asked to
pop one of those dialogs up and there already is such a dialog, raise it
rather than popping a new one up.
Treat "destroy window" like "Cancel" - i.e., clean up any state, and
close any dialogs popped up from the window being destroyed.
svn path=/trunk/; revision=1363
popped up from it ("Edit color filter" dialogs popped up from an "Add
colors to display" dialog box, color selection boxes popped up from an
"Edit color filter" dialog).
If the user presses "Edit" and there's already an "Edit color filter"
dialog box open for the filter in question, don't pop up another "Edit
color filter" dialog box for it, just raise the existing one.
If a color filter is deleted from the list of color filters, close any
"Edit color filter" dialog open for it.
svn path=/trunk/; revision=1362
"Colorize Display" dialog box is created, and let it be destoryed when
that dialog box is destroyed.
When moving color filters up or down, update the (order of the elements
in the) list of color filters, as well as the CList that displays them.
If we have a "Colorize Display" dialog box open, and the user selects
"Display:Colorize Display", raise the existing window, rather than
creating a new window. (Alas, GTK+ doesn't have a call to request that
the window be given the input focus, so we can't do that as well.)
Fix up some names to be more consistent and to better reflect what the
variables/routines are for.
svn path=/trunk/; revision=1361
routines, fetch the name and string from the appropriate member of the
list of color filters, rather than from the CList.
svn path=/trunk/; revision=1360
color filters check whether it's null to decide if there are any color
filters to apply.
Make "color_filter()" act on that list - there really aren't multiple
lists of color filters, there's only one list ("read_filters()" and
"write_filters()" acts only on one global list - and always has, as they
handled only one file).
svn path=/trunk/; revision=1359
responses and adds some more stuff.
I will have to decode NTcreateAndX requests and responses soon as well
as the MSRPC stuff ...
svn path=/trunk/; revision=1356
(I'm using -ko when checking in the PNGs... I hope I'm checking
these binary files into CVS correctly. I'll double check after
the commit).
svn path=/trunk/; revision=1355
Reformat some (source) paragraphs, for the benefit of those with editors
that don't wrap lines in the display.
Delete some extra "=back" directives.
Fix the description of the "Preferences" dialog (it lets you control
various preferences, not just print preferences; it's the "Print" tab
that lets you control print preferences).
svn path=/trunk/; revision=1352
option right now is the placement of the vertical scrollbars in the 3 panes.
(it's one decision; you can't have the placement of the vertical scrollbar
in the packet list pane different than the placement in the protocol tree
pane, for example).
I did this because I find it convenient to have the vertical scrollbars
on the *left* side of the text. My mouse cursor is usually expanding and
collapsing the protocol tree widgets, and once the protocol tree changes
size, I usually have to scroll. I'd rather move my mouse cursor just a few
pixels over to find the vertical scrollbar.
svn path=/trunk/; revision=1351
either need to use tools native to Windows, supply a canned version with
a distribution (and require people to update it by hand), require
people to have "grep" and "sed" handy and whip up a ".bat" file to run
them, or require them to have "grep" and "sed" *and* a Bourne-compatible
shell.
svn path=/trunk/; revision=1343
Guy Harris