channel-type-setting capabilities, and don't build the code to set the
channel type or fetch any channel types other than "no HT".
(It *looks* as if nl80211.h defines NL80211_BAND_ATTR_HT_CAPA as a
member of an enum *and* as a #define, at least in the kernels I've
looked at, so we can test for it with #ifdef - perhaps that's *why* it's
#defined.)
svn path=/trunk/; revision=43608
Linux version of the platform-dependent 802.11 stuff should use the
NL80211_CHAN_ stuff. Map from the WS80211_CHAN_ values to the
corresponding NL80211_CHAN_ values in ws80211_set_freq(), and have the
channel_types bitset use bits indexed by WS80211_CHAN_ values rather
than NL80211_CHAN_.
This won't fix the problem of building this on Linuxes with old
nl80211.h headers that lack NL80211_CHAN_, but it narrows the set of
code that needs the NL80211_CHAN_ values, perhaps allowing the fix to be
a bit cleaner, as well as making it easier to make this work on
platforms other than Linux.
svn path=/trunk/; revision=43606
Add a new name resolution option: whether or not use the configured (in the OS)
name resolver (e.g., DNS) to resolve network names. When this option is disabled
but network name resolution is enabled then Wireshark will resolve only those
names that it can from local sources. This includes (at least, AFAIK):
- name resolutions that Wireshark picks up on from DNS packets it decodes
- the "user hosts file" (~/.wireshark/hosts on *NIX)
- what Wireshark reads out of capture file (the PCAPNG name resolution block)
This new preference defaults to "use external resolvers" for backward
compatibility (so people turning on network name resolution will get the old
behavior).
This option can be set via Edit->Preferences and on the command line; there
remain several UIs (e.g., the "open capture file" dialog, the
View->Name Resolution menu, etc.) that don't have the new option yet.
Also expand on the "description" for the name resolution preferences: these
are used not only in the tooltips but are also written to the preferences
file. The previous text didn't include enough context when written do the
preferences file.
svn path=/trunk/; revision=43605
Don't initialize GeoIP from epan_init(), as we probably haven't loaded the
preferences for it yet (thanks to it's new use of the UAT framework).
Instead, register a post_update callback with UAT and load it there. As a
bonus, this also means that applying GeoIP preferences no longer requires
restarting Wireshark - everything should Just Work with the new databases right
away.
Fixes bug 7446.
svn path=/trunk/; revision=43604
implicitly by the #define name and string they were defined to; not all
UATs neatly fit into any of the categories, so some of them were put
into categories that weren't obviously correct for them, and one - the
display filter macro UAT - wasn't put into any category at all (which
caused crashes when editing them, as the GUI code that handled UAT
changes from a dialog assumed the category field was non-null).
The category was, in practice, used only to decide, in the
aforementioned GUI code, whether the packet summary pane needed to be
updated or not. It also offered no option of "don't update the packet
summary pane *and* don't redissect anything", which is what would be
appropriate for the display filter macro UAT.
Replace the category with a set of fields indicating what the UAT
affects; we currently offer "dissection", which applies to most UATs
(any UAT in libwireshark presumably affects dissection at a minimum) and
"the set of named fields that exist". Changing any UAT that affects
dissection requires a redissection; changing any UAT that affects the
set of named fields that exist requires a redissection *and* rebuilding
the packet summary pane.
Perhaps we also need "filtering", so that if you change a display filter
macro, we re-filter, in case the display is currently filtered with a
display filter that uses a macro that changed.
svn path=/trunk/; revision=43603
There is no guarantee that uat->category is non-null, so check whether
it's null before checking whether it's UAT_CAT_FIELDS or not.
Fixes bug 7444.
#BACKPORT
svn path=/trunk/; revision=43602
Fixes Bug #7449: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7449
-----
Issue:
Building Wireshark with '-O0 -D_FORTIFY_SOURCE=2 ...' fails
The warning [error] message:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires
compiling with optimization (-O) [-Werror=cpp]`
A bit of research shows that this warning was added to a recent version of
glibc (on at least Fedora).
See: http://sourceware.org/bugzilla/show_bug.cgi?id=13979
The warning message occurs if -D_FORTIFY_SOURCE=... is used and the gcc
'optimization level' == 0 (-O0).
Unfortunately when building with -O0 this warning message:
1. Causes compiles to fail (if -Werror [stop on warning])
2. Causes ./configure to fail with an (incorrect) message
about the pcap header being older than the libpcap version.
svn path=/trunk/; revision=43601
"Find Next Mark" was duplicated in the Edit menu and "Find Previous Mark" was
missing (the 2nd "Find Next Mark" would, if selected, find the previous mark).
svn path=/trunk/; revision=43600
some warnings from GTK+.
For interior nodes in the preference module tree, we create a page even
if the module itself has no preferences, so there's *something* we can
show if the user clicks on it. (Showing the top-level protocols page is
a bit weird, and requires us to keep track of it.)
svn path=/trunk/; revision=43596
Yes, the following files can now be deleted:
\wireshark\ui\gtk\prefs_nameres.c
\wireshark\ui\gtk\prefs_nameres.h
\wireshark\ui\gtk\prefs_print.c
\wireshark\ui\gtk\prefs_print.h
\wireshark\ui\gtk\prefs_protocols.c
\wireshark\ui\gtk\prefs_protocols.h
\wireshark\ui\gtk\prefs_taps.c
\wireshark\ui\gtk\prefs_taps.h
I thought removing them was part of the patch for bug 7402, but
they still show up in the SVN (perhaps I didn't create the patch
correctly).
Make it so.
svn path=/trunk/; revision=43591
- prefs.name_resolve_concurrency is now just 'name_resolve_concurrency'
- add notes about possible (?) integer overflows.
svn path=/trunk/; revision=43586
offset returned from dissect_nfs_open_claim4, dissect_nfs_openflag4 were different
when we were building tree and where we didn't.
Fix other similar cases.
svn path=/trunk/; revision=43576
Remove refresh button from wireless toolbar
With a "refresh interfaces" menu option and device hotplug
notification in place there is no longer need for a refresh
button in the toolbar.
svn path=/trunk/; revision=43570
Refresh wireless toolbar too
The recently improved refresh interfaces code forgot the wireless
toolbar. Make sure to refresh it too.
svn path=/trunk/; revision=43568
Add checks for calls to proto_tree_add_XXX (where XXX != item and a few other
functions) with an encoding (ENC_*) argument.
Also add a comment to checkAddTextCalls() about why 3 loops are used.
svn path=/trunk/; revision=43563
https://bugs.gentoo.org/show_bug.cgi?id=423743
"The Makefile.am claims including GLIB_LIBS when linking wireshark is
unnecessary, because wireshark links to GTK_LIBS which is a superset.
It is not actually a superset: gmodule is included in GLIB_LIBS but
not in GTK_LIBS (unless accidentally on older glibs/gtks)."
so we must explicitly link with GLIB_LIBS.
Update the comment to reflect that - and to reflect that GTK+ doesn't
necessarily run atop X11 - while we're at it.
Fixes bug 7427.
#BACKPORT
svn path=/trunk/; revision=43561
- Compile the value_string only as part of packet-x11.c
- Create a value_string_ext to ref the value_string;
- packet_vnc.c: Access the value_string using the value_string_ext;
- packet-x11.c: Access the value-string using the value_string_ext
rather then building a temp GTree from the value_string.
svn path=/trunk/; revision=43558
Guy Harris