[Wireshark-dev] Recommended QT version to build Wireshark Master ?

[Bill Meier]

I'm finally getting around to building Wireshark (Windows 7 32 bit) again.

What version of QT should be used ?

WSDG sec 2.2.4  doesn't really say (although shows 5.5 in the example).
WSDG sec 2.2.10 (which I just happened to see) says 5.6.1
The Master buildbot seems to be using 5.3

Also: wdsg sec 2.2.4 implies that the "OpenGL" version should be used.
Is this correct ?

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Recommended QT version to build Wireshark Master ?

[Bill Meier]

On 9/12/2016 3:11 PM, Bill Meier wrote:

I'm finally getting around to building Wireshark (Windows 7 32 bit) again.

What version of QT should be used ?

WSDG sec 2.2.4  doesn't really say (although shows 5.5 in the example).
WSDG sec 2.2.10 (which I just happened to see) says 5.6.1
The Master buildbot seems to be using 5.3

Also: wdsg sec 2.2.4 implies that the "OpenGL" version should be used.
Is this correct ?



Update: I now see that master is actually using QT 5.6 so I'll use that 
version. (I was wrongly looking at a Wireshark 2.2 builder).


Still not sure about Open-GL vs not Open-GL ?
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Enable extcap by default or not

[Bill Meier]

On 9/9/2016 1:42 AM, Roland Knall wrote:

Hello List

There is currently a discussion going on
in https://code.wireshark.org/review/#/c/17498 in regard to enabling
extcap features by default or not.

There are basically two sides to the argument:

Cons - extcap interfaces are advanced features, which will not be used
by a majority of users. As more and more of those interfaces emerge, it
clutters up the list. Therefore disabling them by default and enabling
them when needed is ok.

Pros - There are users out there, who use Wireshark solely together with
extcap interfaces. Lots of those users are not very familiar with
Wireshark in general. extcap was intended to bring capture device
support to Wireshark where otherwise it would not be present or very
complicated to do so. For those users to enable the support before using
it seems like an unnecessary hassle.

I just wanted to get the meaning of the list, on how we should proceed
here, and if three are other arguments for or against enabling extcap by
default.

To clarify, I am a Pro guy as I fear 3rd party users will not understand
this and this will lead to support cases which will generate the opinion
"Wireshark is overly complicated, let's use something else".

regards
Roland




Does "enabling extcap features by default" mean that additional programs 
("extcaps" ?) are automatically loaded and started when wireshaark is 
started ?


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Some planned cleanups of the 802.11 dissector

[Bill Meier]

On 6/26/2016 6:07 PM, Joerg Mayer wrote:

Hello,

I plan to do some cleanups to
- somewhat improve the readability of the code
  1) Get rid of reduntant author entries and code comments, see
 https://code.wireshark.org/review/16154



  2) Get rid of those fixed field functions that only add one of two items.
 Call the remaining functions directly (without the indirection of
 add_fixed_field()).


+2


- make the use of filters more straight forward: We currently register the
  following top level filters within the file:
  wlan_aggregate
  wlan
  wlan_mgt
  wlan_rsna_eapol
  I'd like to merge at least wlan_mgt into wlan. I don't see the gain in the
  separation and it definitely confuses me:
  a) wlan_mgt is not only managemnt frames but also control frames while
 data frames are just wlan.
  b) The addresses inside wlan_mgt frames are addressed via wlan.xxx

Let me know what you think about these things.

Thanks
   Jörg



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 802.11ac support version

[Bill Meier]

On 4/6/2016 12:11 PM, Alexis La Goutte wrote:

Hi,

It is already supported on Wireshark from some major release

But it is possible some stuff don't decode by Wireshark

Cheers



Looks to me like the initial (partial) 11ac support was added in 
Wireshark-1.10 (released in 2013).


It should be noted that additional dissections and fixes were added in 
later versions.


Also: As noted by Alexis, there are "not yet supported" comments
in the commit log.

Q: why do you ask as to when dissection was added ?

   Given that additional dissections and fixes were added later, I
   suggest you might want to use the latest version of Wireshark for
   the best dissection.




On Wed, Apr 6, 2016 at 2:16 PM, Vikrampal > wrote:

Hi,

__ __

Could somebody please let me know as to when was 802.11ac dissecting
support added to Wireshark?

__ __

Regards,

Vikrampal



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] build with vs2015

[Bill Meier]

On 12/31/2015 10:45 AM, Anders Broman wrote:

 >

I got it building at one point without qt, but I haven't tried for a
while so it's possible some new errors have creapt in. What are the
warnings/errors and you are building from top of trunk?
Regards
Anders



The last time I built GTK Wireshark (about 2 weeks ago) with VS2015 on 
Win7 there were no errors.


Bill



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] config.h differences when generated by Autofoo vs CMake

[Bill Meier]

Differences re #define statements for autofoo vs cmake generated
config.h files on Linux.

Notes:
1. "Used"/"Not used" for the #define'd symbols as shown below is based
   upon a simple grep though all the Wireshark *.h, *.c, *.cpp source
   files.
2. The comparison between the config.h files was somewhat Q+D so there
   may very well be inaccuracies.
3. I've not done the further research to determine if the config.h
   differences for any of the "Used" #defines are significant
   (and unfortunately will not have the time to do so in the upcoming
   week).
4. I did remove a few instances of differences which I deemed not
   relevant; E,G., DATAFILE_DIR).

"-" = Defined only in autofoo config.h
"+" = Defined only In cmake config.h

--- config-h-defines-auto.txt   2015-11-15 17:43:21.247791425 -0500
+++ config-h-defines-cmake.txt  2015-11-15 17:39:16.980102683 -0500
-#define _FILE_OFFSET_BITS 64  // Not used
+#define HAVE_DLADDR 1 // Used in wsutil/filesystem.c
-#define HAVE_FLOORL 1 // Used in ui/time_shift.c,
   //  wsutil/floorl.c
+#define HAVE_GETADDRINFO 1// Used in epan/addr_resolv.c,
   //  dissectors/packet-kerberos.c
+#define HAVE_GETHOSTBYNAME 1  // Used in epan/addr_resolv.c
+#define HAVE_GETHOSTBYNAME2 1 // Used in epan/addr_resolvc.c
-#define HAVE_GRESOURCE 1  // Used in mucho gtk stuff:
   //  No #define/#undef in cmake
   //  config.h
-#define HAVE_INET_ATON 0  // Used (#ifn?def) in
   //  epan/addr_resolv.c,
   //  and lbmr, dcom, aeron, lbtrm
   //  dissectors, text2pcap
-#define HAVE_MEMORY_H 1   // Not used
-#define HAVE_STDLIB_H 1   // Not Used
-#define HAVE_STRING_H 1   // Not Used;
   //  No #define/#undef in cmake
   //  config.h
-#define HAVE_STRINGS_H 1  // Not Used
+#define HAVE_TZNAME 1 // Used in epan/to_str.c
-#define HAVE_XDG_OPEN 1   // Used in ui/gtk/webbrowser.c

-#define HTML_VIEWER "xdg-open"// Used in epan/prefs.h
+#define HTML_VIEWER "/bin/xdg-open"

// Not used
-#define PACKAGE_BUGREPORT "http://bugs.wireshark.org/;
-#define PACKAGE_NAME "wireshark"
-#define PACKAGE_STRING "wireshark 2.1.0"
-#define PACKAGE_TARNAME "wireshark"
-#define PACKAGE_URL "http://www.wireshark.org/;
-#define PACKAGE_VERSION "2.1.0"   // no #undef in cmake config.h
//

-#define STDC_HEADERS 1// Not used
+#define VERSION_EXTRA ""  // Not used
-#define YYTEXT_POINTER 1  // Not used ?


==

#undefs which do not have a corresponding #define/#undef in
 the other config.h for Linux only.
Each instance may or may not be relevant; In some cases #defines
 would be generated on specific platforms as needed ?
 In other cases the symbols aren't used so the #undef is redundant.

"-" = #undef only in autofoo config.h
"+" = #undef only In cmake config.h

--- config-h-undefs-auto.txt2015-11-16 02:41:51.477567865 -0500
+++ config-h-undefs-cmake.txt   2015-11-16 02:42:16.454039402 -0500
-/* #undef AC_APPLE_UNIVERSAL_BUILD */
-/* #undef HAVE_ECHLD */
-/* #undef HAVE_GTKOSXAPPLICATION */// Used in various GTK
//  source files.
//  OK since MAC only ?
-/* #undef HAVE_IGE_MAC_INTEGRATION */  // Used in various GTK
//  source files
//  OK since MAC only ?
-/* #undef HAVE_KEYTYPE_ARCFOUR_56 */
-/* #undef HAVE_LAUXLIB_H */
-/* #undef HAVE_LUALIB_H */
+/* #undef HAVE_MMAP */
+/* #undef HAVE_MPROTECT */
+/* #undef HAVE_NTDDNDIS_H */  // Used in
   // gtk/capture_if_details_dlg_win32.c
   //  OK since used on Windows only ?
+/* #undef HAVE_SOFTWARE_UPDATE */ // Used in gtk/main_menubar.c,
   //  gtk/software_update.c
   //  OK since used only on Windows ?
+/* #undef HAVE_WINSOCK2_H */  // OK since used only on Windows ?
+/* #undef _LARGEFILE64_SOURCE */
+/* #undef _LARGEFILE_SOURCE */

+/* #undef PACKAGE */

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] CMake: Disable building with QT ?

[Bill Meier]

How do I disable building QT Wireshark when using CMake ?

Thanks

Bill

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] CMake: Disable building with QT ?

[Bill Meier]

On 11/12/2015 1:13 PM, Bill Meier wrote:

How do I disable building QT Wireshark when using CMake ?

Thanks

Bill



Answering my own question:

cmake -DBUILD_wireshark=OFF ...




___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] GCC GTK3 Wireshark build warnings ?

[Bill Meier]

When building GTK3 Wireshark on my Fedora system (after not having done 
so for a while), I'm getting many warnings similar to the following:



 CC   libgtkui_a-about_dlg.o
In file included from /usr/include/gtk-3.0/gtk/gtk.h:263:0,
 from about_dlg.c:28:
/usr/include/gtk-3.0/gtk/deprecated/gtkstyle.h:454:43: error: identifier 
"and" is a special operator name in C++ [-Werror=c++-compat]

 GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_background)
   ^

[versions: Fedora 23; GCC 5.1.1; GTK3 3.18.2]

-Wc++-compat seems to have been added in March 2013 (g557df88), so I 
don't know why I'm now getting the warnings (although it's been some 
number of months since I've built GTK3 Wireshark with GCC);

 Warnings didn't show with previous versions of GCC compiler ?
 GTK changes ??
 ???


I note that configure.ac has the following code to default to build with 
GTK3 in certain cases:


#
# No GUI toolkits were explicitly specified; pick Qt
# and GTK+ 3.
#
with_qt=yes
with_gtk3=yes
elif test "x$with_gtk2" = "xunspecified" -a \
  "x$with_gtk3" = "xunspecified" -a \
  "x$with_qt" = "xno"; then
#
# Qt was explicitly disabled, and neither GTK+ 2 nor
# GTK+ 3 were explicitly specified; pick GTK+ 3.
#
with_gtk3=yes
fi

So: it seems we want to continue to support GTK3 ?

and thus it seems that the -Wc++-compat compile flag would need to be 
removed when building GTK stuff or ??


(I do note that there's been a submission in Gerritt to fix a GDK/GTK 
deprecation; Is this the only deprecation which needs to be fixed so 
that GDK/GTK DISABLE_DEPRECATED can be usued again?


Fromconfigure.ac:

CPPFLAGS="-DGDK_DISABLE_DEPRECATED $CPPFLAGS"
	if test \( $gtk_config_major_version -eq 3 -a $gtk_config_minor_version 
-ge 10 \) ; then

## Allow use of deprecated & disable deprecated warnings if Gtk 
>= 3.10;
##  The deprecations in Gtk 3.10 will not be fixed ...
CPPFLAGS="-DGDK_DISABLE_DEPRECATION_WARNINGS $CPPFLAGS"
else
CPPFLAGS="-DGTK_DISABLE_DEPRECATED $CPPFLAGS"
fi


Comments ?

Bill
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GCC GTK3 Wireshark build warnings ?

[Bill Meier]

On 11/11/2015 9:57 PM, Bill Meier wrote:

On 11/11/2015 1:24 PM, Bálint Réczey wrote:

It looks like Balint already sent a patch to Gtk:

https://www.wireshark.org/lists/wireshark-dev/201403/msg00042.html

It seems to be a new breakage, I have to check it.



Yep: from the gtk 3.18 repository: gtkstyle.h commit

2015-05-14Amend deprecation warnings for GtkStyle APIEmmanuele
Bassi1-28/+28


diff --git a/gtk/deprecated/gtkstyle.h b/gtk/deprecated/gtkstyle.h
index dbe83df..55b6934 100644
--- a/gtk/deprecated/gtkstyle.h
+++ b/gtk/deprecated/gtkstyle.h
@@ -451,7 +451,7 @@ GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext)
  void  gtk_style_set_background   (GtkStyle *style,
GdkWindow*window,
GtkStateType  state_type);
-GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext)
+GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_background)
  void  gtk_style_apply_default_background (GtkStyle *style,
cairo_t  *cr,
GdkWindow*window,



I note that in the previous case the patch was to replace 'AND' with '&'



gtkstyle.h appears to be the only file in .../deprecated/*.h with problems.

grep ...

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_background)

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and a style class)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and a style class)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_icon)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_line)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_line)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_background)

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_arrow)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_icon)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_frame)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_background)

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_check)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_option)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_background)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_extension)

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_focus)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_focus)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_handle)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_render_expander)

gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_layout)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_handle)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_icon)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_style_context_get_property)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_style_context_get_property)
gtkstyle.h:GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and 
gtk_style_context_get_property)


___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GCC GTK3 Wireshark build warnings ?

[Bill Meier]

On 11/11/2015 1:24 PM, Bálint Réczey wrote:

It looks like Balint already sent a patch to Gtk:

https://www.wireshark.org/lists/wireshark-dev/201403/msg00042.html

It seems to be a new breakage, I have to check it.



Yep: from the gtk 3.18 repository: gtkstyle.h commit

2015-05-14	Amend deprecation warnings for GtkStyle API	Emmanuele 
Bassi	1	-28/+28



diff --git a/gtk/deprecated/gtkstyle.h b/gtk/deprecated/gtkstyle.h
index dbe83df..55b6934 100644
--- a/gtk/deprecated/gtkstyle.h
+++ b/gtk/deprecated/gtkstyle.h
@@ -451,7 +451,7 @@ GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext)
 void  gtk_style_set_background   (GtkStyle *style,
   GdkWindow*window,
   GtkStateType  state_type);
-GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext)
+GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_background)
 void  gtk_style_apply_default_background (GtkStyle *style,
   cairo_t  *cr,
   GdkWindow*window,



I note that in the previous case the patch was to replace 'AND' with '&' 




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Dissect using val_to_str from external file

[Bill Meier]

On 11/9/2015 10:49 AM, Jo wrote:

Hello,

In my protocol, one TLV is called "proto" and contains the IANA number
of a well-known protocol. How can I display the value together with the
string and using the available data from , for example?

I know how to do it via val_to_str() but I am failing on importing the
existing definitions.



See epan/dissectors/packet-rohc for 2 examples of how to access 
ipproto_val_ext from your dissector. ( from an hf[] array entry or using 
val_to_str_ext()).




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] The ieee802.11 dissector is a steaming pile of ordure

[Bill Meier]

On 9/9/2015 11:23 AM, Richard Sharpe wrote:

Take a look at epan/dissectors/packet-ieee80211.c!

Specifically, add_tagged_field.

That function is approximately 2,300 lines long and it consists of one
big switch statement with every arm containing open-coded statements
to add things to the proto tree.



It's even worse:

add_fixed_field() given a "fixed field number" does a linear search thru 
a (large) table to to find the number (and the associated function 
address) and then calls the function ...


One side effect: there are functions which aren't used but since they're 
in the table, they're not flagged as unused by the compiler.


In several cases there is (or was) duplicate code elsewhere doing a 
dissection similar to the unused "fixed field functions".


(I was working to fix all this but got a bit bored because I had to 
spend time delving thru the 802211 spec trying to understand the code.
I guess I should at least do that work (unless you have a broader 
solution in mind to handle both tagged and fixed fields ?)



Who does that?



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] The ieee802.11 dissector is a steaming pile of ordure

[Bill Meier]

On 9/9/2015 12:03 PM, Bill Meier wrote:

On 9/9/2015 11:23 AM, Richard Sharpe wrote:

Take a look at epan/dissectors/packet-ieee80211.c!

Specifically, add_tagged_field.

That function is approximately 2,300 lines long and it consists of one
big switch statement with every arm containing open-coded statements
to add things to the proto tree.



It's even worse:

add_fixed_field() given a "fixed field number" does a linear search thru
a (large) table to to find the number (and the associated function
address) and then calls the function ...

One side effect: there are functions which aren't used but since they're
in the table, they're not flagged as unused by the compiler.

In several cases there is (or was) duplicate code elsewhere doing a
dissection similar to the unused "fixed field functions".

(I was working to fix all this but got a bit bored because I had to
spend time delving thru the 802211 spec trying to understand the code.
I guess I should at least do that work (unless you have a broader
solution in mind to handle both tagged and fixed fields ?)




Actually, I guess add_tagged_field and add_fixed_field are sort of doing 
the same thing (just in different ways) with respect to the lookup.




___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Bill Meier]

On 8/31/2015 4:24 AM, Pascal Quantin wrote:

 > May be directly move to GeoIP 2 ?
 > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10658
 >
 >
 >
 > I think the code is available from here:
 >
 > https://github.com/maxmind/libmaxminddb

Hi all,

I propose to do it in 2 steps as changing the library is more work than
upgrading the current one:
- first recompile version 1.6.6 and see if it solves the build issue
with MSVC2015 (I'm gonna cross compile it as I have the environment). I
will send an email once it is ready for testing (as I did for Lua).
- then eventually change the library (and keep backward compatibility
with the older one?).




According to https://github.com/maxmind/libmaxminddb, the license is 
Apache V2.



From: http://www.apache.org/licenses/GPL-compatibility.html

"Despite our best efforts, the FSF has never considered the Apache 
License to be compatible with GPL version 2, citing the patent 
termination and indemnification provisions as restrictions not present 
in the older GPL license. The Apache Software Foundation believes that 
you should always try to obey the constraints expressed by the copyright 
holder when redistributing their work."


So: It would seem that doing an upgrade to use libmaxminddb may not be OK.

(I did the license chack after noticing that the Fedora22 repository 
does not contain libmaxminddb).




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Bill Meier]

On 8/12/2015 12:21 PM, Bill Meier wrote:


2. I had to disable building with geoip because:

#error:  Macro definition of snprintf conflicts with Stan
dard Library function declaration (compiling source file packet-ip.c)





A little digging finds that the Windows Wireshark version of the GeoIP 
library(1.5.2) is a bit old; The current version (on GitHub [1]) is 
1.6.6 and has had various fixes made since 1.5.2.


I also note that the 1.6.6 GeoIP.h no longer has the macro definition 
for snprintf so the MSVC2015 GeoIP compile problem obviously won't occur 
using the latest version.


I don't really know to create the GeoIP libraries (and couldn't easily 
do a 64 bit version anyway) so I'll leave this as a ToDo for others 
(Gerald ?).


(Obviously there's no urgency for this).

[1] https://github.com/maxmind/geoip-api-c

Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Bill Meier]

[Resend]

I see that several people (Anders, ...) been building with MSVC-2015 
(VC14) and have fixed a number of issues.


So: I decided to download VC14 and give it a try (using NMake).

A few questions:

Are you using CMake or NMake ?

If using NMake, I assume that you've updated config.nmake  etc. Is 
there some reason you've not committed the changes ?


If not, I've made what I think are the required changes for NMake. Do 
you think it's Ok to commit them ?




Have you been able to do a complete build ?

So far:

1. Compiling packet-pdc.c gets:

[...]\packet-pdc.c(205) : fatal error C1001: An internal error has 
occurred in the compiler.

(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)
 To work around this problem, try simplifying or changing the program 
near the locations listed above.

Please choose the Technical Support command on the Visual C++
 Help menu, or open the Technical Support help file for more information

INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual Studio 
14.0\VC\BIN\cl.exe'

Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

I've figured out what to change to fix this.
(I've also extracted a much smaller test file which causes the error and 
will submit the file to Microsoft).




2. I had to disable building with geoip because:

C:\Program Files\Windows 
Kits\10\include\10.0.10150.0\ucrt\stdio.h(1925): warning C4005: 
'snprintf': macro redefinition (compiling source file packet-

ip.c)
[...]\GeoIP-1.5.1-2-win32ws\include\GeoIP.h(36): note: see previous 
definition of 'snprintf' (compili

ng source file packet-ip.c)
C:\Program Files\Windows 
Kits\10\include\10.0.10150.0\ucrt\stdio.h(1927): fatal error C1189: 
#error:  Macro definition of snprintf conflicts with Stan

dard Library function declaration (compiling source file packet-ip.c)


3. I disabled building with LUA because there's apparently yet no LUA 
library (dll) for use with VC14.



After addressing #1, #2  #3 above (as well as an issue in 
packet-lwres.c), I got a complete working build (based upon a quick test).



4. When compiling with code-analysis enabled, I'm getting a boatload of 
the following warning message:


c:\program files\windows kits\10\include\10.0.10150.0
\ucrt\string.h(130) : warning C28252: Inconsistent annotation for
'strcpy': _Param_(1) has 'SAL_w
ritableTo(elementCount(_String_length_(__formal(1,parameter1))+1))' on
the prior instance. See no file(0).


This makes using analysis with vc14 kind of difficult.


Bill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Bill Meier]

I used nmake



 If using NMake, I assume that you've updated config.nmake  etc.
Is there some reason you've not committed the changes ?





Oops: I hadn't checked for and noticed change #8683.  I would have saved 
myself a lot of effort.  I'll try it out.






 So far:

 1. Compiling packet-pdc.c gets:



I didn't encounter that problem...



I'll see if I get the error with your change #8683 (and if not try to 
see what the difference is).



Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Bill Meier]

On 8/12/2015 3:17 PM, Bill Meier wrote:


I used nmake



Oops: I hadn't checked for and noticed change #8683.  I would have saved
myself a lot of effort.  I'll try it out.



Ok: There are a few additional changes needed to config.nmake when 
building on a 32-bit Windows system.  I'll upload a revised patch to 
change #8683 shortly.







 So far:

 1. Compiling packet-pdc.c gets:



I didn't encounter that problem...



I'll see if I get the error with your change #8683 (and if not try to
see what the difference is).


I still get the failure. I'm now guessing that the issue is something 
related to building on a 32 bit system.





Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Gtk2 xor Gtk3

[Bill Meier]

Seen on gtk-l...@gnome.org

From eba...@gmail.com

snip

Having said that, I must also warn you: do not try to support GTK+ 2
and GTK+ 3 in the same code base. It was doable back when GTK+ 3 was
new, four years ago, but the code base, requirement, assumptions, and
API have been diverging to the point of being a massive waste of time
— for you, for packagers, for users, and for people answering your
questions.

Either stick with GTK+ 2.24, or port to GTK+ 3.

Ciao,
 Emmanuele.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Google deprecating OpenID 2.0

[Bill Meier]

On 2/22/2015 9:16 AM, Evan Huus wrote:

From the looks of it [1] Gerrit upstream is planning to just drop

support for logging in with Google.

[1] https://code.google.com/p/gerrit/issues/detail?id=2715



From the link given above:

* You are already registered and you are using Google OpenID provider: 
You need to move to a new provider before April 20, 2015.


Migrating away from Google OpenID and linking multiple OpenIDs

When you already registered with Google, you need to link your existing 
Gerrit account to another OpenID provider to be able to log in to Gerrit 
after April 20, 2015.


Note: if you don't use Google as your OpenID provider, (or use say 
Fedoraproject, Launchpad, ...), you don't need to take any action.


The exact steps how to link another identity to an existing account 
(please re-read twice before taking any action):


* Login with the existing account
* Select menu Settings → Identities
* Click the 'Link Another Identity' button
* Select the OpenID provider for the other identity
* Authenticate with the other identity
* Log in using the other identity can only be performed after the 
linking is successful


*Warning I*

Users wishing to link an alternative identity should *NOT* log in 
separately with that identity. Doing so will result in a new account 
being created, and subsequent attempts to link that account with the 
existing account will fail. In cases where this happens, the 
administrator will need to manually merge the accounts.


*Warning II*

You must link another identity before April 20, 2015. Otherwise you 
wouldn't be able to log in to your existing Gerrit account.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How do you start a petri-dish review in the review page?

[Bill Meier]

On 2/15/2015 8:46 PM, Richard Sharpe wrote:

Hi folks,

How can I start a petri-dish build etc? Can't seem to figure it out.



On the review page, you should have sections
Code-Review
Verified
Petri-Dish

Click +1 Test under Petri-Dish

and then click Publish Comments


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Mailing List Discussions for Patches

[Bill Meier]

On 2/9/2015 5:29 PM, Kevin Grigorenko wrote:

Hi there. I wrote a patch to add a Sum column to the Service Response
Time window which I've found useful in some customer work. I've reviewed
§ 3.9 Contribute your changes in the Developer's Guide and I didn't
find any notes about whether or not mailing list discussion is required,
which is common in other projects. Does there need to be a discussion on
this mailing list before or after submitting a patch to Gerrit? I've
received internal IBM legal approval to contribute to Wireshark.




Feel free to submit the patch to Gerrit.

Mailing list discussions re a patch are not normally needed.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] lua_bitop.c: MSVC2013 Code Analysis Warning

[Bill Meier]

Hadriel:

MSVC2013 Code Analysis is giving the following warning:


...\ws-git\epan\wslua\lua_bitop.c(116) : warning C6297: Arithmetic 
overflow:  32-bit value is shifted, then cast to 64-bit value.  Results 
might not be an expected value.


After quick look at the code, my reaction:
  Uh Oh... Twisty maze of passages

So I'm going to punt.

Can you take a look (or redirect upstream) or whatever ?

Thanks

Bill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] where to put the Bug: line for bugzilla integration

[Bill Meier]

On 1/15/2015 10:44 AM, Jeff Morriss wrote:

On 01/15/15 10:21, Evan Huus wrote:

Public service announcement, since I've gotten a few emails from
people confused why bugzilla integration seems flaky:

The bugzilla integration will not automatically pick up on the Bug:
 line unless it is part of the footer (i.e. not separated by blank
lines from the rest of the Change-Id: lines and similar). The
following message will work:


Make some change

Bug: 1234
Change-Id: Iblahblahblah


But this one won't:


Make some change
Bug: 1234

Change-Id: Iblahblahblah


... And this means that when you're doing a commit (which does not yet
include the Change-Id--since that's automatically added later) you need
to put the Bug: line immediately prior to the comments, like:


Test commit

Bug: 1234
# Please enter the commit message for your changes. Lines starting




Unfortunately this doesn't work on Windows Git (at least on mine).

Even after doing the above, the commit message ends up with an empty 
line between the Bug .. line and the Change-Id: line.


You have to do a 'git commit --amend' to fix up the commit message to 
remove the empty line.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master b0e6fbf: umts_fp: Replace se_new0(...) by wmem_new0(wmem_file_scope(), ...)

[Bill Meier]

On 12/31/2014 11:31 AM, Evan Huus wrote:

This is an init routine, which can be called when no file is in scope,
so wmem_file_scope() is incorrect (and se_* was also incorrect).

I'm actually not sure what this routine is doing, since it deals with
conversations but there will never be any conversations e.g. on
startup when the init routine is actually called...



I realized (after I did the commit) that there must be a reason why a 
just a few ep/se calls remained (all to related to the use of UATs ?).   :)


This thing looks like it's setting up conversations based upon UAT info 
prior to dissection (presumably so that any subsequent dissection will 
be able to take advantage of info stored in the conversation structs).


Taking a quick look at things I see that in packet.c the init-routines 
are called after setting up file scope and initializing the conversation 
stuff, so it would seem that using file_scope might be OK.


se_free_all();
wmem_enter_file_scope();
...
epan_conversation_init();
...
g_slist_foreach(init_routines, call_init_routine, NULL);

Am I missing something ?

Are there other cases where the init routines are called out of file scope ?

A problem I do see: if the UAT is changed while a file is open, there's 
no update of the conversation table from the UAT. I don't know if 
there's something in the UAT info which might change the dissection.


Maybe this is why the code checks to see if there'san existing 
conversation (altho currently there can't be any since the code is only 
exec'd as an init.



Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master b0e6fbf: umts_fp: Replace se_new0(...) by wmem_new0(wmem_file_scope(), ...)

[Bill Meier]

On 12/31/2014 12:52 PM, Bill Meier wrote:

On 12/31/2014 11:31 AM, Evan Huus wrote:

This is an init routine, which can be called when no file is in scope,
so wmem_file_scope() is incorrect (and se_* was also incorrect).

I'm actually not sure what this routine is doing, since it deals with
conversations but there will never be any conversations e.g. on
startup when the init routine is actually called...



I realized (after I did the commit) that there must be a reason why a
just a few ep/se calls remained (all to related to the use of UATs ?).   :)

This thing looks like it's setting up conversations based upon UAT info
prior to dissection (presumably so that any subsequent dissection will
be able to take advantage of info stored in the conversation structs).

Taking a quick look at things I see that in packet.c the init-routines
are called after setting up file scope and initializing the conversation
stuff, so it would seem that using file_scope might be OK.

 se_free_all();
 wmem_enter_file_scope();
 ...
 epan_conversation_init();
 ...
 g_slist_foreach(init_routines, call_init_routine, NULL);

Am I missing something ?

Are there other cases where the init routines are called out of file
scope ?

A problem I do see: if the UAT is changed while a file is open, there's
no update of the conversation table from the UAT. I don't know if
there's something in the UAT info which might change the dissection.

Maybe this is why the code checks to see if there'san existing
conversation (altho currently there can't be any since the code is only
exec'd as an init.




Oops: I see that cleanup_dissection() also calls the init routines 
(after doing conversation_cleanup()), so I guess that trying to add info 
to the conversation structures at this point might not work too well.


I'll have to dig a little deeper to see what really happens now and what 
might be done for all of this.


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Change in wireshark[master]: Remove unneeded #includes from epan/dissectors

[Bill Meier]

On 12/19/2014 11:28 PM, Bill Meier wrote:


I will make the changes (for packet.h  related) to the epan/dissector
.c files and upload the changes to Gerrit in the next day or so.

Bill




Done (committed) ...

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Change in wireshark[master]: [WIP] Add .mailmap: fix duplicate/wrong e-mail or name in co...

[Bill Meier]

On 12/18/2014 4:19 PM, Alexis La Goutte (Code Review) wrote:


[WIP] Add .mailmap: fix duplicate/wrong e-mail or name in commit log

It will be reused form generate AUTHORS file



If the AUTHORS file is to be autogenerated:

I vaguely remember that there may have been cases where someone 
explicitly requested that they not be included in the AUTHORS file.


Does anyone have any remembrance of this (or anything similar) ?

Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Change in wireshark[master]: Remove unneeded #includes from epan/dissectors

[Bill Meier]

On 12/19/2014 12:05 PM, Martin Mathieson (Code Review) wrote:


Change subject: Remove unneeded #includes from epan/dissectors
..

Remove unneeded #includes from epan/dissectors



Martin:

Obviously, #includes usage in dissectors is a bit of a mish-mosh

There's one thing I would think worthwhile to do to try to keep the 
#includes a bit under control and somewhat consistent before going 
through the dissectors to remove unneeded #includes.


That is, I would change the dissectors as needed to
have '#include epan/packet.h' as the first #include (after config.h 
and any system includes).


If this is done, the #includes (direct and indirect) in packet.h can 
then be immediately removed from the dissectors.



Of the ~1130 non-generated .c files in epan/dissectors, there's about 
350 which don't have '#include epan/packet.h' at all and maybe another 
50 which don't have the include as the first wireshark include.



If you and others are Ok with this suggestion, I'd be happy to do that 
work (altho it might take me a day or three).


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Change in wireshark[master]: Remove unneeded #includes from epan/dissectors

[Bill Meier]

On 12/19/2014 4:19 PM, Bill Meier wrote:

On 12/19/2014 12:05 PM, Martin Mathieson (Code Review) wrote:


Change subject: Remove unneeded #includes from epan/dissectors
..

Remove unneeded #includes from epan/dissectors



Martin:

Obviously, #includes usage in dissectors is a bit of a mish-mosh


Of the ~1130 non-generated .c files in epan/dissectors, there's about
350 which don't have '#include epan/packet.h' at all and maybe another
50 which don't have the include as the first wireshark include.




Update: My analysis above was incorrect. It was done on the dissector 
files *after* the remove unneeded #includes patch was applied.


The correct numbers (based upon the current epan/dissectors/ files).

 1127 non-generated epan/dissectors/*.c files:

   44 w/o packet.h at all
   58 with packet.h not first before other wireshark includes
 1025 appear OK

So: I conclude:

1. The current remove unneeded #includes patch ends up removing
   a number of 'include epan/packet.h' which I think is the not the
   best way to go.

2. There's only ~ 100 non-generated files in epan/dissectors which need
   to be changed so that packet.h is included first before other
   Wireshark includes.

I will make the changes (for packet.h  related) to the epan/dissector 
.c files and upload the changes to Gerrit in the next day or so.


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

[Bill Meier]

On 12/13/2014 4:56 PM, Evan Huus wrote:

I didn't think single-byte fields could really have an endianess, so I
thought ENC_NA was appropriate for them?

Evan



Using ENC_NA is certainly reasonable (and makes logical sense) for 
fetching single-byte fields.


That being said, the convention (certainly not enforced) seems to be to 
use ENC_..._ENDIAN for fetching all integral types.


Looking at the current (non-generated) dissector source before I started 
making changes, I noted that the usage for singe-byte fetches (for 
proto_tree_add_item(), etc) was more or less as follows:


ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN:~12.5K
ENC_NA   ~ 2.7K

I also noted that the ASN.1 generated dissectors appear to be using the 
ENC_..._ENDIAN convention as well when fetching single-byte fields.


--

If there's a consensus that ENC_NA should be used when fetching 
single-byte fields, it might be a bit of work, but probably fairly 
simple to do a wholesale change


Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bugzilla permissions

[Bill Meier]

On 12/12/2014 8:11 AM, Alexis La Goutte wrote:

On Fri, Dec 12, 2014 at 8:47 AM, Michael Oed michael@gmail.com wrote:

Hello,


Hi Mike,


it's some time ago, i was active in the wireshark project. But I'm back and
will spend some more time to develop in the community. :-)

Re-Welcome !

Now my problem:
There is still a problem with my Bugzilla-Account. I'm not be able to take
a bug, because I haven't such link, when I display bug details.
Have somebody any idea, what can I do?



It is no longer need (if you ask about Assigned-to with the e-mail...)
You need only to add comment about you work on this bug...




A convention is to mark the bug as in progress.

ISTR a reason the assigned to is left unchanged is something about 
email notices about the bug need to go to the administrator or something.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] removed functions fast way to find substitutes?

[Bill Meier]

On 11/21/2014 9:29 AM, Pascal Quantin wrote:



2014-11-21 14:06 GMT+01:00 Semjon se...@web.de mailto:se...@web.de:




Am 21.11.2014 um 10:06 schrieb Guy Harris:
 
  On Nov 21, 2014, at 12:48 AM, Semjon
semgo-S0/gaf8t...@public.gmane.org
mailto:gaf8t...@public.gmane.org wrote:
 
  One of my current problems is with
 
  tvb_get_faked_unicode(...)
 
  which isn't available anymore.
  In my Protocol I have some Ascii-encoded String but which comes
as two
  bytes per character. Example:
  {0x0031, 0x0032, 0x0033, 0x0034, 0x} in tvb should display in
  GUI/Tree/PacketList as 1234
 
  If that's truly ASCII-encoded, that would be a significant waste
of bytes - you could just use one byte per character for ASCII; if
the second byte is always zero, that byte serves no useful purpose.
 
  So I'll assume it's a *superset* of ASCII, and that you mean
either UTF-16 encoded string or UCS-2 encoded string rather than
ASCII-encoded string which comes as two bytes per character.
 
  So:
 
  I used to call:
 
  tvb_get_faked_unicode(NULL,tvb, 20,
((tvb_length(tvb)-20)/2),ENC_BIG_ENDIAN)
 
  and display result as %s in col_append_fstr() or as FT_STRING in
  proto_tree_add_string().
 
  So could anyone give me a hint, is there a function still
available for
  this type of encoding
 
tvb_get_string_enc(tvb, {offset}, {length of string},
ENC_UTF_16|ENC_BIG_ENDIAN)
 
  or
 
tvb_get_string_enc(tvb, {offset}, {length of string},
ENC_UCS_2|ENC_BIG_ENDIAN)
 
  depending on whether it's UTF-16 (with surrogate pairs to handle
Unicode characters that don't fit in 16 bits) or UCS-2 (supporting
only characters in the Unicode Basic Multilingual Plane, without
surrogate pairs).
 
  Note that tvb_get_string_enc() returns a UTF-8-encoded string;
octet sequences that can't be mapped to UTF-8 strings will be
replaced by the Unicode replacement character.
 
  In general is there a fast/convenient way - other than manually
looking
  through the sources after functions that might do what i want -
to check
  if this function X is now replaced by function Y.
 
  No.  You could check doc/README.developer, etc. to see if
anything is mentioned.
 
  Other examples I need to replace are:
  abs_time_to_ep_str()
 
abs_time_to_str({wmem scope}, ...)
 
  The old ephemeral and session memory mechanisms are
deprecated in favor of the new wmem mechanisms.  The scope that's
equivalent to ephemeral scope is, I think, packet scope (right,
Evan?), so you'd want
 
abs_time_to_str(wmem_packet_scope(), ...)
 
  nstime_delta()
 
  Its replacement is called nstime_delta() and has the exact same
arguments. :-)
 
  However, you need to include wsutil/nstime.h to get it declared.
 

Well thanks a lot everybody for helping. I could resolve almost all of
my Problems with Your help. In fact the ASCII encoded 2-byte-string is
a Unicode String shame on me :-)

Unfortunately no luck with nstime_delta().

I already had included  wsutil/nstime.h

My call looks like this:

 proto_item *it;
 nstime_t ns;

 it=proto_tree_add_uint(xyz_tree, hf_xyz_response_to, tvb, 0, 0,
xyz_trans-req_frame);
 PROTO_ITEM_SET_GENERATED(it);

 nstime_delta(ns, pinfo-fd-abs_ts, xyz_trans-req_time);
 it=proto_tree_add_time(xyz_tree, hf_xyz_response_time, tvb, 0,
0, ns);
 PROTO_ITEM_SET_GENERATED(it);

It always generates errors LNK2019/LNK1120 ... unresolved external
symbol __imp__nstime_delta in function ...

Hope You have an idea here. I'm not really good in finding the necessary
functions/files to include in such a big project and my search on the
www on this was not successful.


Hi,

assuming that your proprietary dissector is a plugin, ensure that your
makefile indicates the path to libwsutil. I guess you are on Windows, so
your Makefile.nmake file should contain:

!IFDEF ENABLE_LIBWIRESHARK
LINK_PLUGIN_WITH= ..\..\wsutil\libwsutil.lib
CFLAGS=$(CFLAGS)





See plugins\ethercat for a dissector which uses nstime_delta()  [in 
packet-esl.c].


Also: proto.h (#included by packet.h) #includes nstime.h so you need not 
explicitly include same.




___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RoCE and CM dissector fixes

[Bill Meier]

On 10/10/2014 4:43 PM, Tim (Thanh) Nguyen wrote:

Hi Alexis,

Sorry, I'm not familiar with Gerrit, and right now my normal work
doesn't leave me any cycles to learn it for this purpose. If someone
else would like to take this patch and properly submit it ,then feel free.

Tim.


See:

https://code.wireshark.org/review/#/c/4614/

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bugzilla / Gerrit hook not working anymore?

[Bill Meier]

On 9/25/2014 5:16 PM, Pascal Quantin wrote:

Hi,

it looks like the hook updating Bugzilla with the changes pushed to
Gerrit does not work (my last 2 changes did not update the corresponding
bugs).

Cheers,
Pascal.



It hasn't been working for me for a while with Windows Git, but I noted 
that it still seemed to be working for others so I thought it must be 
something about my environment or the way I'm doing things


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Gerrit patches with trailing whitespace

[Bill Meier]

On 8/25/2014 1:48 PM, Alexis La Goutte wrote:

Should we add some info then to the Dev Guide as to where to get the hook,


It's already in http://wiki.wireshark.org/Development/SubmittingPatches#Setup

We keep running into this problem - should the wiki page and the dev
guide be consolidated?


and also run a server-side hook to reject the push?


+1 if we can figure out how to return a nice error message explanation
and not just Your change was rejected by the remote server.

-1
or only trailing whitespace check for the moment... ;-)


I agree with Alexis.

The hook needs work, which I started to do, but then I guess I lost 
interest when the work got to be bigger than a breadbox and then 
didn't announce that I was no longer working on making changes to the

hook.



Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Adding trace to buildbot for fuzz testing

[Bill Meier]

On 8/25/2014 3:37 PM, Stalley, Sean wrote:

Hello All,

I have a trace that I would like to add to the buildbot for regression
testing. I uploaded it here:

https://bugs.wireshark.org/bugzilla/attachment.cgi?id=13015action=edit

Is there a way I can add this trace to the list of traces that the
buildbot runs?

Thanks,

Sean





The MAUSB dissector does not register for a TCP port (i.e., the default 
port is 0).


So: MAUSB TCP captures read by Wireshark (default configuration) won't 
be dissected.


Unfortunately, we don't currently have a solution for that (altho ISTR 
that there's been suggestions to somehow include Wireshark configuration 
information in PCAPNG files).


(The MAUSB SNAP capture files will be dissected and thus at least those 
will exercise the dissector during buildbot fuzz-testing).


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Expert name field in same name space as hf[] abbrev field ?

[Bill Meier]

Since both the ei_register_info 'name' field and the hf_register_info 
'abbrev' field can be used as filters I expect that they effectively are 
in the same name space and thus there should not be a matching 
'name'/'abbrev' between the ei[] entries and the hf[] entries in a 
dissector.


Is this correct ?

If so, I would have expected matching entries (ei[] 'name' vs hf[] 
'abbrev') to have been detected and rejected.


AFAIKT, matching entries ('name/abbrev') apparently aren't being 
rejected.  (See  packet-mausb.c).



Thoughts ?

Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Adding a new dissector - beginners guide

[Bill Meier]

On 8/22/2014 5:22 AM, Graham Bloice wrote:

On 22 August 2014 10:18, Thomas Wiens th.wi...@gmx.de
mailto:th.wi...@gmx.de wrote:


I've got another question to working on the comments in the review
system:

Is it good style to push every fixed comment as a single commit, or
should I work on all comments, and commit them together as once, with
multiple comments?

I've looked into older git comments in the review system, but did't
found a nice review process with commits, to look what style you prefer.


IMHO, I'd prefer to see reviewer lead changes in one lump as diffing
each patch set could be tedious.  I'm basically reviewing the final
patch as will be merged to master.  Others may have a different view.

--
Graham Bloice



+1





___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Adding a new dissector - beginners guide

[Bill Meier]

On 8/22/2014 10:15 AM, Thomas Wiens wrote:

On 22 August 2014 16:05, wrote Graham Bloice:


As I noted on the review, I think you must have removed the Change-ID: line
from the commit message that Gerrit uses to track a new patch set for an
existing change.

You should have used `git commit --amend` to commit and use the existing
commit message.  See the Amending a change section in
http://wiki.wireshark.org/Development/SubmittingPatches

To recover this, we can either consider the latest change as the primary
change and abandon the older one (which would effectively throw away Bill's
fine comments) or abandon the new change and resubmit your changes as a new
patch set to the older change.


If it's possible to abandon the new change.
What should I do?
I think, I'll have to go back to the old change-id-version, and then
apply my changes again with git commit --amend.

How do I get back to the old version?



See my comment to you on the new patch

https://code.wireshark.org/review/#/c/3794/



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 31f3187: Fix warning: no previous prototype for ... [-Wmissing-prototypes]

[Bill Meier]

On 8/18/2014 5:11 PM, Jeff Morriss wrote:

On 08/18/14 09:14, Wireshark code review wrote:

 Fix warning: no previous prototype for ... [-Wmissing-prototypes]

[...]

Actions performed:

 from  3adbd93   Fix warning: no previous prototype for ...
[-Wmissing-prototypes]
 adds  31f3187   Fix warning: no previous prototype for ...
[-Wmissing-prototypes]

Summary of changes:
  ui/cli/tap-iousers.c |1 +
  1 file changed, 1 insertion(+)


Would it be reasonable to request fewer commits with the same comment
but to different files?  E.g., rather than 9 commits covering 10 files
(as we had here) could there be 1 commit?

Having so many commits makes reading the -commits list more tiring than
[I think] it should be.




+1



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] The recent changes to proto.c appear to have broken things badly ...

[Bill Meier]

Specifically:

For some/many/all? dissectors, the protocol never appears in the 
'protocol' column', isn't in the list of protos, filters for the 
protocol don't work. etc etc


I guess something fails with respect to the
proto_tree_add_item(..., proto_..., ...) call.

Oddly enough, the actual dissection for the protocol does appear in the 
details pane.


I believe the changes (5460d7f  3da89d6) should be reverted until they 
are properly tested/fixed.


(When i reverted these two commits to proto.c, things were OK again.

Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] The recent changes to proto.c appear to have broken things badly ...

[Bill Meier]

On 8/3/2014 11:32 PM, Evan Huus wrote:

On Sun, Aug 3, 2014 at 11:20 PM, Bill Meier wme...@newsguy.com
mailto:wme...@newsguy.com wrote:

Specifically:

For some/many/all? dissectors, the protocol never appears in the
'protocol' column', isn't in the list of protos, filters for the
protocol don't work. etc etc

I guess something fails with respect to the
proto_tree_add_item(..., proto_..., ...) call.

Oddly enough, the actual dissection for the protocol does appear in
the details pane.

I believe the changes (5460d7f  3da89d6) should be reverted until
they are properly tested/fixed.

(When i reverted these two commits to proto.c, things were OK again.

Bill


OK, yes, this is very strange.

The result of that change should be only that we *don't* fake the tree
item in certain uncommon cases - it certainly shouldn't be causing wider
problems like this. My understanding is that we should be able to, e.g.
randomly not fake the tree 10% of the time without causing problems as
it is an optimization only, so I'm not sure why adding *any* extra
condition at all would break things like this.

Is TRY_TO_FAKE_THIS_ITEM ever more than an optimization? Does anyone
else know why *not* faking the tree could cause problems?




See Bug #10345.

If someone can confirm this, I do believe that the change should be 
reverted until the issue is straightened out.


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] O2 compile option makes it difficult to debug.

[Bill Meier]

Hi,
It seems like the O2 option interferes with running the debugger. Would
it be better to only use O2 on release builds?
I'm not sure how to do that, add nmake -f makefile.nmake release option?


What I've done is to alter config.nmake slightly to allow the 
specification of WIRESHARK_ENVIRONMENT_CFLAGS as an environment variable
the value of which is then added to the end of the CFLAGS (after all the 
other stuff) in config.nmake.


So: I then set WIRESHARK_ENVIRONMENT_CFLAGS to /Od

My experience has been that the last seen value for an option 
specified multiple times is the one that is used by the 'cl' command (at 
least for the options I've wanted to override).


If this is considered useful (and not harmful), I can commit the 
config.nmake change.


Bill




___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Change in wireshark[master]: Skip the NCP dissector when building on Windows without Python

[Bill Meier]

On 7/25/2014 8:52 AM, Joerg Mayer wrote:

Does it really make sense to allow Windows builds without python installed?
IMO we should by now require python to be present to be able to build on
Windows (or any other plattform).



+1


Ciao
 Jörg

PS: In my opinion this is one of the cases which need to be discussed on
   this list - too many *relevant* things ngs are gerrit only these days.



+1


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Difference between Autofoo and CMake build ?

[Bill Meier]

(For Jörg Mayer)

While reviewing the new ceph dissector [1], two issues cropped up where 
my build on Linux (using Autofoo) apparently gave different results then 
a build by Kevin Cox (the submitter of the new dissector) using CMake on 
Linux.


He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.

1. The Autofoo compile indicated an
  unused but set variable
   The CMake apparently did not.

   Different CFlags ?

2. The ceph dissector had several value_string_ext structs
   defined as 'static const ...'.

   The Wireshark built with CMake worked AOK when
   the ceph dissector used the extended value
   strings for the first time (i.e., no exceptions).

   The Wireshark built with Autofoo trapped
   when the extended value string structs were used
   for the first time (when there was an attempt to
   write to the struct).

   IOW: In one case, the structs were apparently not in a r/o section
while in the other they apparently were.

   I've no idea if this difference has anything to
   do with CMake vs Autofoo.


Thoughts ?

[1] https://code.wireshark.org/review/#/c/1889/

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Difference between Autofoo and CMake build ?

[Bill Meier]

On 7/24/2014 2:09 PM, Kevin Cox wrote:


I usually get these too.  Maybe it was a compiler bug or something.  I
will try checking out the old version and doing a clean build to see if
the warning/error shows up now.



I just did a complete rebuild and I am now getting this error under
CMake as well.  I must have messed up my CMake configure somehow.




Kevin:

Ok; thanks for taking the time to do this.

(I always like to follow thru on things to make sure
 there isn't some issue we need to address).

Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Current 'pre-commit' issues

[Bill Meier]

I've been working with the current 'pre-commit' and have noticed the 
following issues:


1.  Using the current pre-commit which calls checkAPIs, etc, it
doesn't seem possible to make changes to
certain files (e.g., wsgetopt.c) and submit them to Gerrit.

- The files fail checkAPIs.pl as called from pre-commit
  (Error: deprecated/prohibited APIs).

  'git commit --no-verify' bypasses pre-commit, but also bypasses
  commit-msg and thus the commit message doesn't
  have a Change-ID and thus is rejected by Gerrit. [**See below]

Is there a way around this (short of temporarily removing
the pre-commit script) ?
 - somehow generate a Gerrit Commit-ID manually ?
 - ???

 I note that there a a number of (non-dissector) files
 which fail the default checkAPIs. Many of the Errors could probably
 be fixed, but some look either OK or a bit tricky.

 The reason that we don't see these checkAPIs issues with
 'make checkapi' is that the checkAPIs for the files which fail
 have been commented out (thus sort of saying the Errors are OK).

2. checkhf and fix-encoding-args are being called for all files (not
   just dissectors).




1. For the above reasons, I propose that pre-commit only do checkAPIs,
   checkhf and fix-encoding-args for dissector files (to be determined
   in a rather ugly ad-hoc way by seeing if the file is named
   packet-.+\.[hc] (as is done now with 'checkAPIs -p').

   pre-commit would still do the whitespace check for all files.

   checkAPIs can be called for all .[hc] files when/if the current
   Errors are fixed.

2. In addition, I propose to add calls to checkhf and fix-encoding-args
   under the make file checkapi targets for dissector files.



Thoughts ?


Bill




[**]

The Wireshark wiki [1] states

If you must have the whitespace as it is, you can run git commit 
--no-verify to avoid the pre-commit and commit-msg hooks. Note: using 
--no-verify avoids the commit-msg hook, and thus does not add a

   Change-ID automatically to your commit.

Ok: We really don't want to accept commits which don't pass the 
whitespace test so this shouldn't be an issue when using

the default pre-commit.

However, the Wiki doesn't say what to do when we really, really
must have the whitespace except to say '--no-verify' leaves
us with a commit message with no Commit-ID.


[1] http://wiki.wireshark.org/Development/SubmittingPatches
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Current 'pre-commit' issues

[Bill Meier]

On 7/11/2014 3:09 PM, Evan Huus wrote:

On Fri, Jul 11, 2014 at 12:42 PM, Bill Meier wme...@newsguy.com

When you try and push a change to gerrit without a Commit-ID, the error
message it returns includes the Commit-ID it's expecting, so you can
manually git commit --amend and paste that into the footer.




I missed that ...

Thanks

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Backport request for proto_tree_add_subtree[_format]

[Bill Meier]

On 7/10/2014 5:32 PM, Pascal Quantin wrote:


Le 10 juil. 2014 23:19, Peter Wu pe...@lekensteyn.nl
mailto:pe...@lekensteyn.nl a écrit :
 
  Hi all,
 
  I would like to have the proto_tree_add_subtree and
  proto_tree_add_subtree_format functions backported to master-1.12.
Any objects
  to that? It is only a new addition to the API, so it should be pretty
safe.
 
  It should make backporting changes easier. (read: backport a
refactoring (WIP)
  to reduce code duplication in the SSL and DTLS dissectors.)
 

IMHO we have already waited too long to freeze 1.12 content and while
those code refactoring are nice to have, they do not seem mandatory for
the new stable branch.
We should only apply bugfixes from now and publish a new RC followed
shortly by the final 1.12.0 release. If there are blocker bugs, we
should identify them ASAP.

Just my 2 cents,
Pascal.




+1

Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Patching as per checkAPI

[Bill Meier]

On 6/18/2014 3:40 AM, Evan Huus wrote:

If they're distinct changes on a single branch (so they're related, but
make sense as individual commits in the final repo) then #2. Gerrit
might warn you, but I think it will let you do it as long as you confirm
you mean it.



One push with multiple commits should work just fine.

Each commit (with its separate Gerrit ChangeId) will create a separate 
patch in Gerrit.


I suggest that changes related to specific APIs (e.g., tvb_length() -- 
tvb_captured_length()) be grouped in commits so as to minimize the 
effort required to review and submit the patches in Gerrit.


Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] iSER dissector submission question

[Bill Meier]

On 6/16/2014 6:33 AM, Yan Burman wrote:

Hi,

I am new to wireshark development.
I have posted on gerrit a new iSER dissector. I also added a minor bug fix in 
ib_sdp dissector that I found while running fuzz tests (not part of the iSER 
patches).
I do not know whom to add as reviewers in gerrit (basically there is a small 
change to iscsi dissector, and new iSER dissector).
Is this the right way to do this, or should I post the patches on the mailing 
list instead?

Thanks,
Yan



Posting patches and new dissectors on gerrit is the right way.

The postings will be reviewed as people have time (altho there may well 
be some delay right now since many Wireshark core developers are 
attending Sharkfest this week).


(You do not need to (and should not) add reviewers yourself).



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Does _U_ get defined to something non-null on Windows?

[Bill Meier]

On 5/28/2014 7:29 PM, Richard Sharpe wrote:

Hi folks,

Does _U_ work with the Windows C/C++ compiler?

If so, how is it defined?



From windows config.h (derived from config.h.win32):

#define _U_


So: _U_ on Windows is effectively ignored.


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Use of tcp_dissect_pdus() with a protocol which has a variable length PDU length field

[Bill Meier]

To: TCP re-assembly experts:


The MQTT protocol dissected by packet-mqtt.c runs over TCP. The field 
which specifies the MQTT PDU length can be 1 to 4 bytes; the length of a 
complete MQTT PDU can be less than 4 bytes.


So: trying use tcp_dissect_pdus() won't work since the fixed length
needed to handle the maximum size of the PDU length field is larger 
than the possible minimum PDU size.


One approach is to assume that the complete length field will, with high 
probability, always be in 1 TCP segment and thus available even if 
specifying a 'fixed length' which includes only a 1 byte PDU length 
field.  (This is certainly not guaranteed).


Or, obviously, the dissector could do reassembly as described in 
README.dissector section 2.7.2 Modifying the pinfo struct.


However, digging a little deeper, I note that tcp_dissect_pdus() is 
doing something related to want_pdu_tracking (which I've never delved 
into and which is not mentioned in README.dissector).


So it occurred to me that using a modified tcp_dissect_pdus() which 
allows the get_pdu_len function to return DESEGMENT_ONE_MORE_SEGMENT 
might be a workable approach.


So: I added the following to tcp_dissect_pdus() and modified
the packet-mqtt.c get_pdu_len() function appropriately.

(added code in tcp_dissect_pdus):

 plen = (*get_pdu_len)(pinfo, tvb, offset);
+
+/* Is more data being requested before the PDU length can be
determined ?
+ *  If so, request same.
+ */
+if (plen == DESEGMENT_ONE_MORE_SEGMENT) {
+if (!proto_desegment || !pinfo-can_desegment) {
+REPORT_DISSECTOR_BUG(DESEGMENT_ONE_MORE_SEGMENT not 
allowed);

+}
+pinfo-desegment_offset = offset;
+pinfo-desegment_len = DESEGMENT_ONE_MORE_SEGMENT;
+return;
+}
+
 if (plen  fixed_len) {


My questions:

1. Is this a reasonable approach (it works AOK in my tests) ?

2. If not, and packet-mqtt should do reassembly itself, does the 
reassembly code also need to do the want_pdu_tracking stuff ?


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Failed for master-1.10: [Automatic manuf, services and enterprise-numbers update for 2014-04-27]

[Bill Meier]

On 4/28/2014 4:40 PM, Peter Wu wrote:

On Monday 28 April 2014 22:36:46 Jaap Keuter wrote:

I noticed that master and master-1.8 got their weekly updates, but
master-1.10 missed it? Can we find out why?


It probably has something to do with IANA changes, see
https://code.wireshark.org/review/c/1385/

Peter



Corrected Link:

https://code.wireshark.org/review/#/c/1385/
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building with Visual Studio Professional 2013 ...

[Bill Meier]

On 4/27/2014 6:16 PM, Richard Sharpe wrote:


Woohoo! It works!



With 1 caveat...   :)

I expect that probably trying to use Lua with Wireshark built with 
VS2013 will fail in some manner.


Currently, building with VS2013 (VC12) is configured to link with a Lua 
DLL which is linked with the VS2010 (VC10) msvcrt. I expect this  will 
cause problems.


(Fpom config.nmake)

!IF $(MSVC_VARIANT) == MSVC2012 ||  $(MSVC_VARIANT) == MSVC2012EE
LUA_DIST=-5.2.3_Win64_dll11
!ELSE
LUA_DIST=-5.2.3_Win64_dll10
!ENDIF
LUA_DIR=$(WIRESHARK_LIB_DIR)\lua5.2.3



Pascal recently did the work to use the correct Lua DLL with VS2012 
(VC11) (..dll11).  Hopefully there's a VS2013 version of the Lua DLL 
which can be used when building with VS2013 (VC12)





Bill

P.S.

As part of the process of doing a first Wireshark build with VC2013, I 
somehow managed to link with the VS2012 Lua DLL even though the 
config.nmake selects the VS2010 version. (I think this happened because 
I first built with VS2012 then did a 'clean' (without re-creating the 
win32 libraries) and then built with VS2013).



It took me a little while to realize what was going on.

I guess one has to be very careful when developing with multiple VS 
versions since what are effectively different DLL's (i.e. linked with 
different versions of msvcrt) will have the same name.


I wonder if there's a way to check at link time (or run-time) that the 
right version (linked with the right msvcrt) is being used 



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Gerrit Diff format

[Bill Meier]

(To: Gerald)

Currently the Gerrit diff shows whitespace changes.

Previously, when viewing diffs of SVN commits via the web, whitespace 
changes were not shown.


If others agree, is it possible to configure the Gerrit diff to not show 
whitespace changes ?


(Or to provide an option ?)

Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Viewing code in Gerrit

[Bill Meier]

On 3/24/2014 9:21 AM, Evan Huus wrote:


In summary: the diff is computed locally in javascript, and seems to
be worse than O(n) on the size of the underlying file; viewing the
diff for any file 1k lines may be slow, but if you just let it run it
will finish eventually. Avoid epan/enterprise-numbers and other files
with 100k+ lines, they take many minutes to finish.



IOW: The 2 versions being diff'd are downloaded in total before doing a 
local compare ?


If so, UGH 





___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Viewing code in Gerrit

[Bill Meier]

On 3/24/2014 12:03 PM, Evan Huus wrote:

IOW: The 2 versions being diff'd are downloaded in total before doing a
local compare ?


It seems so; however it doesn't appear to be the bandwidth that's the
problem, but the actual diff algorithm. The bottleneck is definitely
CPU.




For those of us who might be on a budget (bandwidth and/or total bytes) 
downloading large files to do diffs would be something to be careful about.


(Naybe this approach is needed to be able to handle adding comments, etc ?)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 04c39bb: Add Lua heuristic dissector support

[Bill Meier]

Re;


  doc/README.heuristic  |   10 +--



+ * but ONLY do this if your heuristic sits directly on top of UDP
or TCP (ie, you did heur_dissector
+ * otherwise you'll be overriding the dissector that called your
heuristic dissector.


I think this is not correct. There is at least one transport protocol 
other than TCP  UDP (i.e., DCCP) which currently has a heuristic table 
and calls 'try_conversation()' and thus heuristic sub-dissectors can use 
conversation_set_dissector().


I think, in theory, any protocol associated with the known
'port_type's [1] can establish a conversation for that port_type and 
then have heuristic sub-dissectors which can call 
conversation_set_dissector().


In actuality, only a few dissectors currently do so.


How about the something like following wording:

... but only do this if your heuristic sits directly on top of
(was called by) a dissector which established a conversation
for the protocol port type. IOW: directly over TCP, UDP, ...


Looking at the Wireshark dissectors: I see at least one
possibly problematical case:

packet-soupbintcp has heuristic sub-dissectors and uses 
try_conversation() even though it actually uses (I think) the 
conversation established bu packet-tcp.


I thinks this means that if packet-tcp has try heuristic first that 
things won't work right.


I'll have to research this further.

Bill



[1]
/* Types of port numbers Wireshark knows about. */
typedef enum {
PT_NONE,/* no port number */
PT_SCTP,/* SCTP */
PT_TCP, /* TCP */
PT_UDP, /* UDP */
PT_DCCP,/* DCCP */
PT_IPX, /* IPX sockets */
PT_NCP, /* NCP connection */
PT_EXCHG,   /* Fibre Channel exchange */
PT_DDP, /* DDP AppleTalk connection */
PT_SBCCS,   /* FICON */
PT_IDP, /* XNS IDP sockets */
PT_TIPC,/* TIPC PORT */
PT_USB, /* USB endpoint 0x means the host */
PT_I2C,
PT_IBQP,/* Infiniband QP number */
PT_BLUETOOTH
} port_type;

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GIT tutorials

[Bill Meier]

On 3/11/2014 1:47 PM, Hadriel Kaplan wrote:


On Mar 11, 2014, at 1:18 PM, Christopher Maynard 
christopher.mayn...@gtech.com wrote:


If possible, add some information/basic steps on a few more topics as well?
For example:
1) How do you undo a commit, or undo part of a commit?


You can reset the head, but I really think going there requires reading the 
book. :)




If you want to undo a (non-pushed) commit other than at HEAD, you'll 
need to search the web for a solution.


(I don't believe Pro Git covers that case).

What I found;

http://sethrobertson.github.io/GitFixUm/fixup.html


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 9817] Provide a way to clear the capture window without restarting the capture or reapplying the filter

[Bill Meier]

On 2/28/2014 2:46 PM, bugzilla-dae...@wireshark.org wrote:

*Comment # 3
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9817#c3 on bug
9817 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9817 from Guy
Harris mailto:g...@alum.mit.edu *

(In reply tocomment #2  show_bug.cgi?id=9817#c2)

It means to clear the display.


The display shows the (possibly improper) subset of captured packets that pass
the currently-active filter (if any; if none, all packets pass, hence
possibly improper).

Thus, there are two ways to clear the display, in the sense of having no
packets shown:

 1) have a filter that matches no packets;

 2) permanently discard all the captured packets.


If that means discarding all captured packets, then yes, that sounds about
right.


That's choice number 2.


Is that the same as restarting the running live capture?


If you are currently running a live capture, and want to clear the display but
continue to capture, the only conceivable way to do that would be to restart
the capture - because doing that amounts to restarting the capture, so it's not
as if it's logically possible to implement that *except* by restarting the
capture.

If you are currently running a live capture, and want to *stop* capturing and
clear the display, that would be done by stopping the capture and then closing
it.

If you're finished capturing, and want to clear the display, that would be done
by closing the capture.




How about a third choice: just clear the summary pane (or scroll down so 
that the previous last line shown is at now the top (or similar) ?




___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 9817] Provide a way to clear the capture window without restarting the capture or reapplying the filter

[Bill Meier]

On 2/28/2014 3:45 PM, Guy Harris wrote:


On Feb 28, 2014, at 11:52 AM, Bill Meier wme...@newsguy.com wrote:


How about a third choice: just clear the summary pane (or scroll
down so that the previous last line shown is at now the top (or
similar) ?


The summary pane currently shows what packets are in the capture, so
clearing the summary pane and discarding the packets in the
capture are inherently the same operation.

Are you suggesting that we change the Wireshark internal model so
that there is no longer one frame data structure for every packet in
the file, or that we, in effect, have *two* forms of filtering of the
display - filtering based on a filter expression and filtering based
on don't display any packets before this one?

If so, which packets should, for example, a Save, Save As, or Export
Specified Packets operation see?  Should it see the ones cleared
from the display?


Neither:

Upon entering some keystroke, literally just do a scroll down so that 
only the last frame (being displayed at the time the keystroke is 
entered) shows the at the top of the pane.


Can this be done (easily?) (at all?) using QT; I've no idea.

Is this worthwhile ?

Most of the time I wouldn't think this at all useful.

However, if the frames which are being displayed occur at a slow rate, 
then resetting the screen display as needed now and then might make it 
easier to notice when new frames are displayed.


Is this what the OP had in mind ? I'm not sure.

P.S. if the capture display is being done in no scroll mode, can a 
user hit page down (or something) to scroll down the screen while a 
capture is in progress ?  (I don't have time to try this right now).


If so, scroll past (or something) might be another variant.

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Sample command line workflow with git and gerrit

[Bill Meier]

On 2/25/2014 7:50 PM, Hadriel Kaplan wrote:


On Feb 25, 2014, at 7:06 PM, Joerg Mayer jma...@loplof.de wrote: gerrit


jmayer@egg:~/work/wireshark/git(master) git branch newsupdate
jmayer@egg:~/work/wireshark/git(master) git checkout newsupdate
Switched to branch 'newsupdate'


% git checkout -b newsupdate

would have created the branch and checked it out at the same time
(or 'git checkout -b newsupdate master' if you weren't in master at the time of 
issuing the command, but wanted to create the branch off of master)

-hadriel
p.s. I think this stuff really needs to go into a wiki page.



+1

It's been a bit slow  painful learning how to do things.

(I haven't yet read the latest updates to the dev docs on all this so 
maybe that covers the needed info).


Bill





___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Add a capability to disable/enable a dissector table ?

[Bill Meier]

It seems to me that it would be nice to be able to disable/enable 
specific dissector and heuristic tables.


For example, this would be useful when investigating tcp level issues
for which tcp payload dissection is not interesting.

All the different protocols which run over tcp wouldn't need to be 
disabled to just show the payloads as 'data (and not show things like 
malformed because some dissector mistakenly tries to dissect data).



Thoughts ? Am i missing something ?

(This might be a nice little project fpr me to learn QT ...).


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] what is the meaning of function proto_register_subtree_array?

[Bill Meier]

On 2/16/2014 7:44 AM, 我想不无聊 wrote:

when you register a protocol,you should do the following three steps,
1.proto_register_protocol();
2.proto_register_field_array();
3.proto_register_subtree_array()

what does the third function proto_register_subtree_array do?why ?and do
it for what reason?




Essentially: proto_register_subtree() registers variables (usually named 
ett_...) which are used to store state as to whether a particular 
sub-tree is expanded or not in the packet-details pane in the GUI.



See proto_item_add_subtree(...) in the code for pretty much any dissector.


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Feature request: show context frames for frames matching display filter

[Bill Meier]

On 2/16/2014 2:38 AM, Reinhard Nissl wrote:

Hi,

when investigating network issues with a display filter like

 frame.time_delta  0.1

it would be useful to also see the previous 10 and next 5 frames of the
matching frame for example, to get an idea what caused that delay.

This feature is comparable to the context control options of the common
utility grep: -A, -B or -C.

Feel free to ask for further information. Thanks in advance.

BTW: Wireshark (64-bit) 1.10.5 (SVN Rev 54262 from /trunk-1.10)

Bye.



Thanks for the suggestion.

Please create an enhancement request at bugs.wireshark.org.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 54983: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-bgp.c

[Bill Meier]

On 1/27/2014 12:23 PM, Evan Huus wrote:

We should maybe make tshark -G values part of the test suite? (and
maybe the other tshark -G dumps as well?)



Certainly 'tshark -G values' should be added.
(I'll do so).

A quick look suggests that crashes in most (all ?) of the other -G dumps 
would probably not occur because of bad dissector code.


Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Compilation failure on Fedora 20 - GTK3 issues

[Bill Meier]

On 12/20/2013 12:46 PM, Joerg Mayer wrote:

As Wireshark development doesn't really care about the compatibility with
future GTK versions (we are migrating to Qt) I have disabled that warning
for cmake builds.



So either apply a similar change to the autotools build



Done in SVN #54337.


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] r54005 by wmeier for packet-mq.c and packet-mq-pcf.c

[Bill Meier]

On 12/14/2013 5:30 AM, RobiOneKenobi wrote:

Yes,

if it didn't disturb too much people to have such long lines, I will prefer
that you revert this part (hf[] entries reformatting), otherwise I will
follow the majority wishses



I've restored the single line per hf[] entry format in SVN #54005.

Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] r54005 by wmeier for packet-mq.c and packet-mq-pcf.c

[Bill Meier]

On 12/18/2013 11:57 AM, Bill Meier wrote:

On 12/14/2013 5:30 AM, RobiOneKenobi wrote:

Yes,

if it didn't disturb too much people to have such long lines, I will
prefer
that you revert this part (hf[] entries reformatting), otherwise I will
follow the majority wishses



I've restored the single line per hf[] entry format in SVN #54005.




Correction: The restoration was done in SVN #54226.

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Coding style and example dissector

[Bill Meier]

On 12/18/2013 7:52 AM, Joerg Mayer wrote:

On Tue, Dec 17, 2013 at 05:55:30PM -0800, Michael Lum wrote:

Could someone please write a coding style section for the new dissectors and 
perhaps
point to the best example dissector.


doc/README.developer last sections (5. White space convention) more or less
is what we have.


Currently, many of the dissectors I have submitted are having arbitrary white 
space/style
changes made.

I completely understand changes, for bugs, API changes, and warnings missed 
because of cross-platform
builds.

But I don't understand the need to change FROM a consistent style to some other 
style.


Maybe the consistent form was not apparent to the person make these changes.
Adding a mode-line seems like a good way to prevent this sort of arbitrary
changes.

If you are the de facto maintainer of these dissectors and you don't feel
comfortable with these changes then maybe open a bug and ask for these changes
to be reverted - you have to feel comfortable with your code.
In case you can live with (more or less) any coding style as seems
to be the case for you then it's only time someone else might have spent doing
other things but no harm was done and no revert is necessary.

Ciao
   Jörg



Michael:

You are probably referring to various changes I've made.

As I make updates in dissectors, I've gotten in the habit of doing a 
once-over and making changes related, to a large extent, to whitespace 
(field alignment, consistent indentation, trailing whitespace, etc) but 
which can/do shade over into changes in style.


Looking back, (and based upon some other recent comments) I think I need 
to slow down a bit.


I'm happy to revert changes upon request.

Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Should existing use of 'LL' and 'ULL' when specifying a constant be fixed ?

[Bill Meier]

README.developer says:

 When specifying an integral constant that doesn't fit in 32 bits, don't
 use LL at the end of the constant - not all compilers use LL for
 that.  Instead, put the constant in a call to the G_GINT64_CONSTANT()
 macro, e.g.

G_GINT64_CONSTANT(11644473600U)

 rather than

11644473600ULL


I note that in current SVN there are a number of cases where ULL (or LL) 
are used.


e.g.: packet-9p.c:#define _9P_GETATTR_MODE 0x0001ULL

Should these be fixed ? (or is the README outdated ?)

If they should be fixed:

   It appears that G_GUINT64_CONSTANT can be used (since we require
   GLib 2.16 and based upon an EMail from a while back it seems that
   GLib 2.10  newer define G_GUINT64_CONSTANT).

   So: I would update README.developer and make the
   source changes.

If the README is outdated, I would remove the statement from the README.


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 53531: /trunk/ /trunk/epan/dissectors/: packet-x11.c x11-declarations.h x11-enum.h x11-extension-errors.h x11-extension-implementation.h x11-glx-render-enum

[Bill Meier]

On 11/23/2013 8:32 PM, morr...@wireshark.org wrote:

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53531

User: morriss
Date: 2013/11/24 01:32 AM

Log:
  Some patches from Peter Harris to make it possible to build the X11 dissector
  again (and some various other improvements):


When compiling X11 with dev CLang 4.8 (dev LLVM 2.4 but soon be be a 
release), the following warning message is generated:


warning: explicitly assigning a variable of type 'int' to
  itself [-Wself-assign]
n = n; /* Avoid unreferenced warning */


This is basically just to give a heads up, since this is a very minor 
nit sompared to all the stuff (warning messages) that got fixed (Thanks).


Using 'n = n + 1' does seem to kill the warning message from Clang so 
maybe this can be used until the generator ToDo related to this code 
has been completed.


Bill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] r54005 by wmeier for packet-mq.c and packet-mq-pcf.c

[Bill Meier]

On 12/13/2013 12:21 PM, RobiOneKenobi wrote:

Reformat hf[] entries ?

Why, now all seems no more aligned for me, and your reformat also
left spaces between text and comma.


You're right; I was sloppy about leaving spaces between the text and the 
comma.   :)




I do not agree with such reformat, as it seems less readable as the
one I’ve put in.



I made the change because, personally, I find the quite long lines quite
difficult to read when they when they exceed the width of my screen
(which I expect they will do on screens used by many).


I like to have some parts aligned to an ease of use for to have the
same length of displayed items.



I understand.


Are there some rules where this is described?




Not really. I do think readability is relevant; I'm not really a fan of 
the old 72 column limit but I do think there should be some limit.


The above notwithstanding, I can revert the hf[] reformatting if you 
desire.



Bill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] How about we change Filter button to say Diisplay Filter on the main Wireshark GUI page ?

[Bill Meier]

Maybe this would help to make things a bit more clear.

I'd also like to add text to the tooltip:
Something like: (To enter a capture filter see Capture/Options)


Opinions ?

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows build setup - Concept required

[Bill Meier]

Re: creating/using a standard package directory structure on Windows

 It sounds like you're suggesting that we take the
 packages as distribited and move things
 around to a standard structure. This sounds to me like the
 effort to do this it might be crazy-making ...


Also: A few questions/comments: see inline:


 1) zlib is installed as source only

 As opposed to installing DLL's from a package ?
 My understanding is that we need to build the zlib DLL
 ourselves due to ensure that the right C runtime is used.
 (cross C-runtime memory allocation issues).



2) portaudio is installed as source only


 (As in 1) above ?)


3) Every package is installed into its own subdirectory, sometimes with
its own structure



4) glib2 contains zlib headers that break windows builds

 right: it appears that the gtk2/includes dir is never
 used as an include dir so that (fortunately) the correct
 zlib includes are used. Ditto for the zlib DLL.
(It seems that the zlib DLL  includes distribdted
 with our current GTK/GLib package are for
 zlib v1.27 while we're actually building/using zlib v1.25)
 In any case, as noted, we need to build our own ...


5) glib3 contains zlib headers that break windows builds

  ditto


6) krb5 contains includes that export krb5-build internal flags and
thus cause warnings during compiles


 When building how ?


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows build setup - Concept required

[Bill Meier]

On 12/5/2013 3:02 PM, Bill Meier wrote:


I like Gerald's answers much better than mine :)


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark coding style help

[Bill Meier]

On 11/21/2013 8:05 PM, Guy Harris wrote:


On Nov 21, 2013, at 4:37 PM, Michael Lum
michael@starsolutions.com wrote:


Can someone tell me why code like this:

i++;

would have been changed to this:

i += 1;

?


If the code in question is stepping through a packet, and i is
actually offset or some such variable holding the offset into the
packet, and other code is doing offset += 2 or offset += 4,
people might have used offset += 1 to make the style more
consistent and to put the field length into all the incrementing
lines of code.



You may be referring to one  or more changes I made.  :)

As Guy suggested, for consistency I tend to change 'offset++' to 'offset 
+= 1'.


It does appear that I changed 'i++;' to 'i += 1;' in a few instances.
I must have been a bit over enthusiastic in those cases since there's no 
real reason for that change.


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Problem...

[Bill Meier]

On 11/17/2013 12:53 PM, Herb Falk h...@sisconet.com wrote:

I just got the SVN stuff to compile, but from the documentation I can’t
figure out what file is missing and where to put it…



Based upon some preliminary research, it's possible that a setup command 
will be needed.


I need to do a little further research;

How are you running the newly-built Wireshark ?

From the wireshark-gtk2 (or whatever is specified as INSTALL_DIR in 
config.nmake) sub-directory in the source tree ?


In any case, please post the output from 'wireshark -v'.


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Problem...

[Bill Meier]

On 11/17/2013 12:53 PM, Herb Falk h...@sisconet.com wrote:

I just got the SVN stuff to compile, but from the documentation I
can't figure out what file is missing and where to put it.



Based upon some preliminary research, it's possible that a setup command will 
be needed.

I need to do a little further research;

How are you running the newly-built Wireshark ?

  From the wireshark-gtk2 (or whatever is specified as INSTALL_DIR in
config.nmake) sub-directory in the source tree ?

In any case, please post the output from 'wireshark -v'.





Ok: When building wireshark with GTK3 on Windows in a dev environment, a 
file called gschemas.compiled should be set up under the INSTALL 
directory as share\glib-2.0\schemas\gschemas.compiled

(INSTALL is defined in config.nmake)


From the top-level Makefile.nmake:

...
!IFDEF GTK_SCHEMAS_DIR
if not exist $(INSTALL_DIR)\$(GTK_SCHEMAS_DIR) ^
   mkdir $(INSTALL_DIR)\$(GTK_SCHEMAS_DIR)
if not exist $(GTK_DIR)\$(GTK_SCHEMAS_DIR)\gschemas.compiled ^
   $(GTK_DIR)\bin\glib-compile-schemas ^
  $(GTK_DIR)\$(GTK_SCHEMAS_DIR)
xcopy $(GTK_DIR)\$(GTK_SCHEMAS_DIR)\gschemas.compiled ^
  $(INSTALL_DIR)\$(GTK_SCHEMAS_DIR) /d
!ENDIF
...


(Note that gschemas.compiled is created as needed using
glib-compile-schemas).

I'm not sure why this is not working in your build.

It should have just worked ...:

Is 'C:\wireshark' the directory you've defined as the INSTALL dir in 
config.nmake ??



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 1.11.0 release

[Bill Meier]

On 10/10/2013 10:56 AM, mman...@netscape.net wrote:

My vote would be to install in a central location and make it just
another step in


+1



http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html, just
like installing Visual Studio.
-Original Message-
From: Gerald Combs ger...@wireshark.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Oct 9, 2013 8:36 pm
Subject: Re: [Wireshark-dev] 1.11.0 release


For people doing development on Windows, would you rather have the Qt
SDK in a central location on yoursystem  (I've been using c:\Qt) or in
WIRESHARK_LIB_DIR with everything else (which means taking up a lot of
space if you have multiple WIRESHARK_LIB_DIRs)?

Also, should we dump the Qt ZIP archives into SVN or distribute them
separately? Or tell people to download the official version from
qt-project.org? I've signed the DLLs and executables in the archives
above with the Wireshark Foundation key. I'm not sure if Digia does the
same for the official distribution.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

[Bill Meier]

On 10/6/2013 7:27 PM, Joerg Mayer wrote:

The executables now compile and link except the gtk and qt guis.
I have not yet been able to run the executables as running the binaries
inside the build tree doesn't seem to work (unlike on linux).
Ideas how to get this to work?

Thanks
Jörg



This is undoubtedly about the fact that Makefile.nmake copies lots of 
DLLs and etc to a separate run directory.


The exe's won't run from the build dir on Windows.

See install_all: target in Makefile.nmake (top-level)

...
# install-all will copy all files needed to run Wireshark/Tshark
# to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
install-all: install-generated-files
...

Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Transport name resolution

[Bill Meier]

On 9/16/2013 4:15 PM, Dirk Jagdmann wrote:

Should we, instead, look the port number up in the tcp.port or
udp.port (or sctp.port) dissector table and, if it finds a
dissector handle, look up the short name of the protocol for that
dissector handle and use that?


I think this is more useful, since the dissector short name is typically
used as the filter prefix. It is just confusing if slightly different
strings are shown, because they come from some other list/database.



+1
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Clang build with ASAN

[Bill Meier]

On 8/13/2013 9:43 AM, Evan Huus wrote:

On Mon, Aug 12, 2013 at 11:17 AM, Alexis La Goutte
alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote:

Hi,

it is now possible to build wireshark with clang (CC=clang
./configure  make) (i fix last issue last week end).


I will try the ASAN feature (
http://clang.llvm.org/docs/AddressSanitizer.html )


I wonder if it is possible to also run include-what-you-use now?
https://code.google.com/p/include-what-you-use/



I've done a little trial of include-what-you-use (iwyu).

IMO, the output is a bit useful but most of theoutput is not .

It appears, for example, that iwyu seems wants to, in effect, expand 
.h file includes (e.g., packet.h) and then just include the actual .h 
files needed.


This (obviously) can be valid (and might reduce compile time) but I 
certainly don't think going through and substituting individual 
#includes for packet.h as suggested by iwyu is something that should be 
done.


One possible action might be to look at the remove these lines 
suggestions; individual inspection would probably be required to 
determine if an #include can be removed w/o having to add a sub-include.


Bottom line (IMO):

1. Blindly applying all the suggestions is a non-starter.

2. Manually applying certain suggested items seems like a lot of work
   for not much result.

So, I thoink there's other stuff with much higher priority.

Bill

==

[[ iwyu output for packet-netsync.c and packet-tcp.c ]]

packet-netsync.c should add these lines:
#include stddef.h // for NULL
#include ./column-utils.h // for col_set_str
#include ./ftypes/ftypes.h// for ftenum::FT_BYTES, etc
#include ./proto.h// for proto_tree_add_item, 
HFILL, etc

#include ./tvbuff.h   // for tvbuff_t, tvb_get_guint8, etc
#include ./value_string.h // for val_to_str, value_string
#include epan/column_info.h   // for ::COL_PROTOCOL
#include epan/packet_info.h   // for packet_info
#include glib/gmacros.h   // for TRUE, FALSE
#include glib/gtypes.h// for gint, guint, gboolean
#include glibconfig.h // for guint8, guint32

packet-netsync.c should remove these lines:
- #include epan/addr_resolv.h  // lines 34-34  [[[ OK: included in 
prefs.h ]]]

- #include epan/strutil.h  // lines 36-36  [[[ OK: Not needed ]]]
- #include glib.h  // lines 31-31

The full include-list for packet-netsync.c:
#include epan/packet.h// for array_length, etc
#include epan/prefs.h
#include stddef.h // for NULL
#include ./column-utils.h // for col_set_str
#include ./ftypes/ftypes.h// for ftenum::FT_BYTES, etc
#include ./proto.h// for proto_tree_add_item, 
HFILL, etc

#include ./tvbuff.h   // for tvbuff_t, tvb_get_guint8, etc
#include ./value_string.h // for val_to_str, value_string
#include config.h // for _U_
#include epan/column_info.h   // for ::COL_PROTOCOL
#include epan/packet_info.h   // for packet_info
#include glib/gmacros.h   // for TRUE, FALSE
#include glib/gtypes.h// for gint, guint, gboolean
#include glibconfig.h // for guint8, guint32
#include packet-tcp.h // for tcp_dissect_pdus
---



  CC   libdissectors_la-packet-tcp.lo

packet-tcp.h should add these lines:
#include ./address.h  // for address
#include ./proto.h// for proto_tree
#include ./tvbuff.h   // for tvbuff_t
#include epan/conversation.h  // for __CONVERSATION_H__, etc
#include epan/packet.h// for dissector_t
#include epan/packet_info.h   // for packet_info
#include epan/wmem/wmem_tree.h// for wmem_tree_t
#include glib/gtypes.h// for gboolean, gchar, guint
#include glibconfig.h // for guint32, guint16, gint32, etc
#include wsutil/nstime.h  // for nstime_t

packet-tcp.h should remove these lines:
- #include epan/wmem/wmem.h  // lines 37-37

The full include-list for packet-tcp.h:
#include ./address.h  // for address
#include ./proto.h// for proto_tree
#include ./tvbuff.h   // for tvbuff_t
#include epan/conversation.h  // for __CONVERSATION_H__, etc
#include epan/packet.h// for dissector_t
#include epan/packet_info.h   // for packet_info
#include epan/wmem/wmem_tree.h// for wmem_tree_t
#include glib/gtypes.h// for gboolean, gchar, guint
#include glibconfig.h // for guint32, guint16, gint32, etc
#include ws_symbol_export.h   // for WS_DLL_PUBLIC
#include wsutil/nstime.h  // for nstime_t
---

packet-tcp.c should add these lines:
#include ./column-utils.h // for 

Re: [Wireshark-dev] [Wireshark-commits] rev 48652: /trunk/ui/gtk/ /trunk/ui/gtk/: capture_dlg.c

[Bill Meier]

On 3/30/2013 7:57 AM, j...@wireshark.org wrote:

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=48652

User: jake
Date: 2013/03/30 04:57 AM

Log:
  Have 'Capture file' and 'Stop after' extries left aligned in GTK+ 3 as well.

Directory: /trunk/ui/gtk/
   ChangesPath Action
   +49 -23capture_dlg.cModified



The fix was to use ws_gtk_grid_attach_extended()
with just GTK_FILL as the X  Y options in various places.

My understanding of the normal expected semantics of GTK_FILL is that it 
only takes effect when GTK_EXPAND is used.


So: I'll have to look at the way I implemented 
ws_gtk_grid_attach_extended() using halign and valign for GTK3 to see if 
it's OK or if I should change something (and thus if I need to change 
the fix in SVN #48652 and possibly change other calls to ws_gtk_grid...).


Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 48555: /trunk/epan/ /trunk/epan/: value_string.c

[Bill Meier]

On 3/25/2013 8:37 PM, g...@wireshark.org wrote:

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=48555

User: guy
Date: 2013/03/25 05:37 PM




Guy;

I'm curious why you added the following test in the recent 
value_string.c patch


  if (first_value  vs_p[i].value) {
g_warning(Extended value string %s forced to fall back to 
linear search: entry %u, value %u  first entry, value %u,

  vse-_vs_name, i, vs_p[i].value, first_value);
type = VS_SEARCH;
break;
  }


Do you feel that the special case described in the comments (see 
extract below) should be dis-allowed (maybe because it's a bit of a hack) ?


If so, ISTR there are some value string arrays which will need to be 
re-ordered.


Bill




/* Note: The value_string 'value' is *unsigned*.
 *
 *   Special case:
 *{ -3, -2, -1, 0, 1, 2 }  will be treated as ascending ordered
   (altho not really such)
 * thus allowing as a 'direct' search.
 *
 *   Note:
 *{ -3, -2, 0, 1, 2 } and { -3, -2, -1, 0, 2 } will both be
considered as out-of-order with gaps
 *  thus requiring a 'linear' search.
 *{ 0, 1, 2, -3, -2 } and { 0, 2, -3, -2, -1 } will be considered
ascending ordered with gaps
 *  thus allowing a 'binary' search.
 */



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 48555: /trunk/epan/ /trunk/epan/: value_string.c

[Bill Meier]

On 3/26/2013 1:29 PM, Guy Harris wrote:


On Mar 26, 2013, at 5:40 AM, Bill Meier wme...@newsguy.com wrote:


I'm curious why you added the following test in the recent value_string.c patch

  if (first_value  vs_p[i].value) {
g_warning(Extended value string %s forced to fall back to linear search: entry 
%u, value %u  first entry, value %u,
  vse-_vs_name, i, vs_p[i].value, first_value);
type = VS_SEARCH;
break;
  }


I don't think it's adding that test - unless I missed something, the change was 
from

if ((type == VS_BIN_TREE)  (A || B)) {
type = VS_SEARCH;
complain;
break;
}

to

if (type == VS_BIN_TREE) {
if (A) {
complain about A;
type = VS_SEARCH;
break;
}
if (B) {
complain about B;
type = VS_SEARCH;
break;
}
}

B is first_value  vs_p[i].value, so it was being tested for before my change.  
I didn't add a test, I just split one so that the warning message would report 
whether A or B was the failure case.


Do you feel that the special case described in the comments (see extract 
below) should be dis-allowed (maybe because it's a bit of a hack) ?

If so, ISTR there are some value string arrays which will need to be re-ordered.

Bill

/* Note: The value_string 'value' is *unsigned*.
*
*   Special case:
*{ -3, -2, -1, 0, 1, 2 }  will be treated as ascending ordered
   (altho not really such)
* thus allowing as a 'direct' search.


Unless I'm missing something, if that's the special case to which you're 
referring, then

vs_p[i].value != (i + first_value)

will not be true in any case - the array is

{ 0xFFFD, 0xFFFE, 0x, 0, 1, 2 }

and, given that it's 32-bit unsigned arithmetic (arithmetic mod 2^32-1), that 
test will always be false, so the loop will never fall back to VS_BIN_TREE, and 
the test that was changed will never happen.


*   Note:
*{ -3, -2, 0, 1, 2 } and { -3, -2, -1, 0, 2 } will both be
considered as out-of-order with gaps
*  thus requiring a 'linear' search.


That's

{ 0xFFFD, 0xFFFE, 0, 1, 2 }

and

vs_p[i].value != (i + first_value)

will fail for i = 2, as (0xFFFD + 2) = 0x, which is != 0.

So it'll fall back to VS_BIN_TREE; first_value is 0xFFFD, which is  0, so 
it'll fall back again to VS_SEARCH, but that'd happen in either version of the 
code.


*{ 0, 1, 2, -3, -2 } and { 0, 2, -3, -2, -1 } will be considered
ascending ordered with gaps
*  thus allowing a 'binary' search.


The first of those is

{ 0, 1, 2, 0xFFFD, 0xFFFE }

and that'll fail the

vs_p[i].value != (i + first_value)

test for i = 3, and fall back to VS_BIN_TREE, but it won't fail either of the 
tests done for VS_BIN_TREE, in either version of the code.

The second of those is

{ 0, 2, 0xFFFD, 0xFFFE, 0x }

and the same applies, except that it'll fall back to VS_BIN_TREE for i = 2.




Right you are !  I was too quick on the draw :(


Sorry for the noise 


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 48445: /trunk/ui/gtk/ /trunk/ui/gtk/: capture_dlg.c conversations_table.c gui_utils.c gui_utils.h hostlist_table.c

[Bill Meier]

On 3/20/2013 6:41 PM, ger...@wireshark.org wrote:

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=48445

User: gerald
Date: 2013/03/20 03:41 PM




Gerald:

There recently was an issue in capture_if_dlg.c where the use of 
gtk_window_get_size() and gtk_window_resize() seemed not to work well on 
some platforms.


In the end, what seemed to work well was to use 
get_widget_get_preferred_size() and then gtk_window_set_default_size().


See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8468 for all the 
gory details.


The patch attached to the bug replaced the use of get_size/resize with 
get_preferred_size/set_default_size.


(Note that gtk_widget_get_preferred_size is defined as 
gtk_widget_size_request for GTK2 which means that the 3rd arg to 
gtk_widget_get_preferred_size() is always set to NULL).


#define gtk_widget_get_preferred_size(x,y,z) \
gtk_widget_size_request(x,y)

Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Windows-XP-x86

[Bill Meier]

On 3/17/2013 10:30 AM, Evan Huus wrote:

These are still happening occasionally. I dug out my XP-32 virtualbox
instance but have not been able to reproduce.

Tangentially, running the test suite from cygwin I get the following
failure (after the test the build-bot keeps failing on):

5  Suite: Unit tests
5.1 Step: exntest
suite-unittests.sh: line 32: nmake: command not found

exntest Failed!
make ../epan/exntest failed

Which seems to imply I ought to be running the tests from the visual
studio command prompt (in order to have nmake), but of course it
doesn't interpret shell scripts. What am I missing?



Basically:

You have to setup the Windows cmd environment so that MSVC can be 
invoked from the command line. (nmake, etc)


(When you then run cygwin bash to run the test scripts nmake  etc will 
be available).


For instance: in my Windows cmd line setup cmd file I have:

call C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\vcvars32

It's been a long time since I did this so I don't remember al the 
details. I'm sure the Wireshark Developers Guide has info.


(Can you do the setup directly from the bash cmd line ? I don't remember).


Bill



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Windows-XP-x86

[Bill Meier]

On 3/17/2013 11:00 AM, Bill Meier wrote:


Basically:

You have to setup the Windows cmd environment so that MSVC can be
invoked from the command line. (nmake, etc)

(When you then run cygwin bash to run the test scripts nmake  etc will
be available).

For instance: in my Windows cmd line setup cmd file I have:

call C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\vcvars32



(I'm actually using a .cmd file to do Windows builds which first sets up 
the env as above and then does the nmake).


Doing C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\vcvars32
directly from the Windows command line should be fine.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Windows-XP-x86

[Bill Meier]

On 3/17/2013 12:09 PM, Evan Huus wrote:

I'm still not having any luck (and I've reread
https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html to
no avail). I have two shells available: cygwin's bash and windows'
cmd.exe.

If I run cmd.exe and then run the vcvars32 script, I can build
Wireshark correctly using nmake. This seems to be working fine.

I I run cygwin then I do not have nmake available. Running the
vcvars32 script from cygwin does not seem to change this (should it)?

I cannot run test.sh from cmd.exe since cmd.exe will not interpret
unix shell scripts. I cannot run test.sh from cygwin since it requires
nmake, which I cannot get cygwin to recognize.



Are you starting bash from the Windows cmd env from which you executed 
the vcvars script ?



The following works for me



cmd C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\vcvars32

cmd bash

bash$ nmake /f

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1061: /F option requires a filename

bash$ cd test

bash$ rm -f ../epan/*.exe

bash$ l ../epan/*.exe
ls: cannot access ../epan/*.exe: No such file or directory

bash$ ./test.sh -c
--

### Test suite: All ###

Subitems:
-
1  Suite: Prerequisites (2 subitems)
2  Suite: Command line options (10 subitems)
3  Suite: File I/O (1 subitems)
4  Suite: Capture (3 subitems)
5  Suite: Unit tests (3 subitems)
6  Suite: File formats (1 subitems)
7  Suite: Decryption (1 subitems)

1-7  : Select item
Enter: Test All
Q: Quit

--

### Test suite: Unit tests ###

Subitems:
-
1 Step: exntest
2 Step: reassemble_test
3 Step: tvbtest

1-3  : Select item
Enter: Test All
U: Up
Q: Quit


--

### Unit tests ###
1 Step: exntest OK
2 Step: reassemble_test OK
3 Step: tvbtest OK

### Test suite results ###
OK: 3
Failed: 0
Skipped: 0
--

bash$ l ../epan/*.exe
-rwx--+ 1 13824 03-17-13 13:30:26  ../epan/exntest.exe
-rwx--+ 1 90624 03-17-13 13:30:27  ../epan/reassemble_test.exe
-rwx--+ 1 89600 03-17-13 13:30:29  ../epan/tvbtest.exe

bash$





___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Fun with window resizing in GTK3

[Bill Meier]

On 3/13/2013 5:49 PM, Guy Harris wrote:


On Mar 13, 2013, at 1:04 PM, wme...@wireshark.org wrote:


(This stuff in GTK3 about parents inheriting expand/fill properties from 
children
is driving me crazy).


Presumably the GTK+ developers thought that this was a Good Idea.
Have we just not been Doing It Right, and if we'd been Doing It Right
windows would just Do The Right Thing when their size is changed, or
did the GTK+ developers just Get It Badly Wrong here?



I don't think the GTK+ developers got it badly wrong.

It's proably more a matter of me (who only does GTK programming every so 
often) understanding the interactions.



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] -Wmissing-prototypes ??

[Bill Meier]

Anders:

Just out of curiosity, why are the prototypes in the following change 
needed ?



Or: maybe the real question is: why is -Wmissing_prototypes needed ?

We already catch any .h files which are missing prototypes of global 
functions because we use -Wimplicit-function-declaration (part of -Wall).


So: what am i missing ?

Bill




 User: etxrab
 Date: 2013/03/12 04:09 PM

 Log:
   - [-Wmissing-prototypes]

--- packet-aodv.c   (revision 48273)
+++ packet-aodv.c   (revision 48274)
@@ -50,6 +50,8 @@
  * (both of the above two are draft-perkins-manet-aodv6-01.txt, which
  * is from November 2000)
  */
+void proto_register_aodv(void);
+void proto_reg_handoff_aodv(void);

 #define INET6_ADDRLEN  16
 #define UDP_PORT_AODV  654

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] dlg_utils.c comment completely obsolete ??

[Bill Meier]

In dlg_utils.c:

GtkWidget *
dlg_window_new(const gchar *title)
{
 ...

/*
 * XXX - if we're running in the capture child process, we can't easily
 * make this window transient for the main process's window.  We just
 * punt here.
 *
 * Perhaps the child process should only capture packets, write them to
 * a file, and somehow notify the parent process and let *it* do all
 * the GUI work.  If we can do that efficiently (so that we don't drop
 * more packets), perhaps we can also do so even when we're *not* doing
 * an Update list of packets in real time capture.  That'd let the
 * child process run set-UID on platforms where you need that in order
 * to capture, and might also simplify the job of having the GUI main
 * loop wait both for user input and packet arrival.
 */
...
}

I'm almost certain the above comment in dlg_utils.c is left over from 
the old days 


However, I'd like to get a confirmation before I remove the comment.

Guy ?


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Editcap link warnings

[Bill Meier]

Recent Windows 7 and Windows XP Buildbot builds have been giving 
locally defined symbol ... imported in ...  warnings while linking 
editcap:


(I get the same warnings on my system).

From the  Window 7 Buildbot log:

Linking editcap.exe
link @C:\Users\buildbot\AppData\Local\Temp\nm7775.tmp
   Creating library editcap.lib and object editcap.exp
LINK : warning LNK4010: invalid subsystem version number 5.00; default 
subsystem version assumed


editcap.obj : warning LNK4217: locally defined symbol nstime_delta 
imported in function main
editcap.obj : warning LNK4217: locally defined symbol nstime_is_unset 
imported in function main
editcap.obj : warning LNK4217: locally defined symbol nstime_set_unset 
imported in function main
editcap.obj : warning LNK4217: locally defined symbol init_progfile_dir 
imported in function main
editcap.obj : warning LNK4217: locally defined symbol md5_finish 
imported in function is_duplicate
editcap.obj : warning LNK4217: locally defined symbol md5_append 
imported in function is_duplicate
editcap.obj : warning LNK4217: locally defined symbol md5_init imported 
in function is_duplicate
editcap.obj : warning LNK4217: locally defined symbol nstime_cmp 
imported in function is_duplicate_rel_time


(Aside: I thought I recently fixed the  invalid subsystm error on my 
Windows 7 VS build setup; I'll have to remember what that was about).


Bill

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] finishing Cmake (Was: Simpifying exporting DLL symbols)

[Bill Meier]

On 2/27/2013 11:51 AM, Bálint Réczey wrote:

Hi,





- Add asn1 autogen target (assigned: krj)
Since the asn1 seems to be assigned already I did not want to
intervene with it. ;-)


The last commit from krj was in

r35324 | krj | 2011-01-02 03:29:33 -0500 (Sun, 02 Jan 2011)

so, I expect, someone else will probably need to do this.


Bill


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Simpifying exporting DLL symbols

[Bill Meier]

On 2/26/2013 5:11 PM, Bálint Réczey wrote:

2013/2/26 Pascal Quantin pascal.quan...@gmail.com:
...




Thank you! If no one opposes I'll commit the patch on Thursday and
then start converting the remaining libs.



It sounds like the change is significant.

if so, I suggest we consider if we should wait until after 1.10 is 
released  to make the change.


Bill




___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe