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

[Kaul]

Doesn't happen on a fully updated Fedora 19, just on my Fedora 20:
  CC   libgtkui_a-addr_resolution_dlg.o
In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0,
 from /usr/include/gtk-3.0/gtk/gtkwindow.h:33,
 from /usr/include/gtk-3.0/gtk/gtkdialog.h:33,
 from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
 from /usr/include/gtk-3.0/gtk/gtk.h:31,
 from about_dlg.c:30:
/usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier and is a
special operator name in C++ [-Werror=c++-compat]
 GDK_DEPRECATED_IN_3_0_FOR(gtk_widget_get_preferred_width and
gtk_widget_get_preferred_height)
  ^
In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0,
 from /usr/include/gtk-3.0/gtk/gtkwindow.h:33,
 from /usr/include/gtk-3.0/gtk/gtkdialog.h:33,
 from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
 from /usr/include/gtk-3.0/gtk/gtk.h:31,
 from addr_resolution_dlg.c:31:
/usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier and is a
special operator name in C++ [-Werror=c++-compat]
 GDK_DEPRECATED_IN_3_0_FOR(gtk_widget_get_preferred_width and
gtk_widget_get_preferred_height)
  ^
about_dlg.c: In function ‘about_wireshark_cb’:
about_dlg.c:580:29: error: ‘GTK_STOCK_OK’ undeclared (first use in this
function)
   bbox = dlg_button_row_new(GTK_STOCK_OK, NULL);
 ^
about_dlg.c:580:29: note: each undeclared identifier is reported only once
for each function it appears in
cc1: all warnings being treated as errors
make[2]: *** [libgtkui_a-about_dlg.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from addr_resolution_dlg.c:49:0:
../../ui/gtk/addr_resolution_dlg.h:28:27: error: unknown type name
‘GtkAction’
 void addr_resolution_dlg (GtkAction *action, gpointer data);
   ^
addr_resolution_dlg.c:290:22: error: unknown type name ‘GtkAction’
 addr_resolution_dlg (GtkAction *action _U_, gpointer data _U_)
  ^
addr_resolution_dlg.c:52:19: error: ‘addr_resolution_dlg_w’ defined but not
used [-Werror=unused-variable]
 static GtkWidget *addr_resolution_dlg_w = NULL;
   ^
addr_resolution_dlg.c:201:1: error: ‘addres_resolution_to_texbuff’ defined
but not used [-Werror=unused-function]
 addres_resolution_to_texbuff(GtkTextBuffer *buffer)
 ^
cc1: all warnings being treated as errors
___
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

[Kaul]

wireshark-qt compiled fine and looks great. Bubye GTK.
Thanks,
Y.


On Fri, Dec 20, 2013 at 7:46 PM, Joerg Mayer jma...@loplof.de 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
 or use cmake to build (see README.cmake).

 Ciao
  Jöarg

 On Fri, Dec 20, 2013 at 01:20:37PM +0200, Kaul wrote:
  Doesn't happen on a fully updated Fedora 19, just on my Fedora 20:
CC   libgtkui_a-addr_resolution_dlg.o
  In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0,
   from /usr/include/gtk-3.0/gtk/gtkwindow.h:33,
   from /usr/include/gtk-3.0/gtk/gtkdialog.h:33,
   from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
   from /usr/include/gtk-3.0/gtk/gtk.h:31,
   from about_dlg.c:30:
  /usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier and is a
  special operator name in C++ [-Werror=c++-compat]
   GDK_DEPRECATED_IN_3_0_FOR(gtk_widget_get_preferred_width and
  gtk_widget_get_preferred_height)
^
  In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0,
   from /usr/include/gtk-3.0/gtk/gtkwindow.h:33,
   from /usr/include/gtk-3.0/gtk/gtkdialog.h:33,
   from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
   from /usr/include/gtk-3.0/gtk/gtk.h:31,
   from addr_resolution_dlg.c:31:
  /usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier and is a
  special operator name in C++ [-Werror=c++-compat]
   GDK_DEPRECATED_IN_3_0_FOR(gtk_widget_get_preferred_width and
  gtk_widget_get_preferred_height)
^
  about_dlg.c: In function ‘about_wireshark_cb’:
  about_dlg.c:580:29: error: ‘GTK_STOCK_OK’ undeclared (first use in this
  function)
 bbox = dlg_button_row_new(GTK_STOCK_OK, NULL);
   ^
  about_dlg.c:580:29: note: each undeclared identifier is reported only
 once
  for each function it appears in
  cc1: all warnings being treated as errors
  make[2]: *** [libgtkui_a-about_dlg.o] Error 1
  make[2]: *** Waiting for unfinished jobs
  In file included from addr_resolution_dlg.c:49:0:
  ../../ui/gtk/addr_resolution_dlg.h:28:27: error: unknown type name
  ‘GtkAction’
   void addr_resolution_dlg (GtkAction *action, gpointer data);
 ^
  addr_resolution_dlg.c:290:22: error: unknown type name ‘GtkAction’
   addr_resolution_dlg (GtkAction *action _U_, gpointer data _U_)
^
  addr_resolution_dlg.c:52:19: error: ‘addr_resolution_dlg_w’ defined but
 not
  used [-Werror=unused-variable]
   static GtkWidget *addr_resolution_dlg_w = NULL;
 ^
  addr_resolution_dlg.c:201:1: error: ‘addres_resolution_to_texbuff’
 defined
  but not used [-Werror=unused-function]
   addres_resolution_to_texbuff(GtkTextBuffer *buffer)
   ^
  cc1: all warnings being treated as errors

 
 ___
  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


 --
 Joerg Mayer   jma...@loplof.de
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 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] [Wireshark-commits] rev 54161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-pdcp-lte.c

[Kaul]

Still no go:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9568 : Compilation
failure: packet-pdcp-lte.c:1211:12: error: variable 'key' set but not used
[-Werror=unused-but-set-variable]

Build Information:r54164
http://anonsvn.wireshark.org/viewvc?view=revisionrevision=54164
--
packet-pdcp-lte.c: In function 'decipher_payload':
packet-pdcp-lte.c:1211:12: error: variable 'key' set but not used
[-Werror=unused-but-set-variable]
 guint8 key[16];
^
packet-pdcp-lte.c: In function 'dissect_pdcp_lte':
packet-pdcp-lte.c:1255:15: error: variable 'payload_tvb' set but not
used [-Werror=unused-but-set-variable]
 tvbuff_t *payload_tvb;
   ^
cc1: all warnings being treated as errors



On Tue, Dec 17, 2013 at 1:16 AM, Martin Mathieson 
martin.r.mathie...@googlemail.com wrote:

 Thanks for fixing this up, Guy, you just beat me to it.  That was one
 commit too far before I left work.
 Martin


 On Mon, Dec 16, 2013 at 11:08 PM, g...@wireshark.org wrote:

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

 User: guy
 Date: 2013/12/16 11:08 PM

 Log:
  Fix compiler warnings.

 Directory: /trunk/epan/dissectors/
   ChangesPath Action
   +10 -10packet-pdcp-lte.cModified


 ___
 Sent via:Wireshark-commits mailing list 
 wireshark-comm...@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-commits
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
  mailto:wireshark-commits-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

___
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] Build instability

[Kaul]

And the above has been fixed.
Regretfully, replaced by another compilation failure:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9543

Y.


On Tue, Dec 10, 2013 at 8:19 AM, Kaul myk...@gmail.com wrote:

 Above compilation failure has been fixed.
 Regretfully, only to be replaced by another compilation failure:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9538


 On Mon, Dec 9, 2013 at 2:49 PM, Kaul myk...@gmail.com wrote:

 Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the
 issue.


 On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki darkjames...@darkjames.pl
  wrote:

 On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
  Thanks for the automated build links - I guess I'll watch them more
 closely
  and only sync when my platform passes.
 
  Interesting - I'm pulling from trunk and still fail on that. Perhaps it
  wasn't fixed entirely, or I have to do some cleanup?

 I agree, it isn't fixed, from_hex() is defined inside:
   #if defined(HAVE_LIBGNUTLS)  defined(HAVE_LIBGCRYPT)

 but it's used outside this #ifdef.


 Kuba.

 
 
  On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de
 wrote:
 
   On 12/08/2013 04:30 PM, Kaul wrote:
Hi all,
   
I've been trying to enhance a specific dissector for two weeks now.
Since I'm afraid of diverging the code (although I'm working on a
specific dissector), I update my code base often (~ once a day).
Regretfully, 5 times (in 2 weeks!) this has resulted in compilation
   failure.
I'm pretty sure (subjectively) this hasn't happened in the past.
 Any
measures we can put (continuous build system?) in place to prevent
 this?
   
Today's failure (2nd failure only today btw):
make[5]: Entering directory
 `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) !=
(ssl_session-session_id.data[i]  4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
   
Thanks,
Y.
  
   Hi,
  
   There are automated build, they are described here:
  
 http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html
  
   The last build results are here:
   http://buildbot.wireshark.org/trunk/one_line_per_build
  
   The problem you current have was already fixed in current trunk some
   hours ago.
  
   Hauke
  

 
 ___
  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




___
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] Build instability

[Kaul]

Also fixed, now epan/dissectors/packet-smpp.c is completely broken.
This should fix it:
svn diff epan/dissectors/packet-smpp.c
Index: epan/dissectors/packet-smpp.c
===
--- epan/dissectors/packet-smpp.c   (revision 53918)
+++ epan/dissectors/packet-smpp.c   (working copy)
@@ -85,7 +85,7 @@

 /* Forward declarations */
 void proto_register_smpp(void);
-void proto_reg_handoff_smpp(void)
+void proto_reg_handoff_smpp(void);
 static int dissect_smpp(tvbuff_t *tvb, packet_info *pinfo, proto_tree
*tree, void* data);
 static guint get_smpp_pdu_len(packet_info *pinfo, tvbuff_t *tvb, int
offset);
 static int dissect_smpp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree
*tree, void* data _U_);



On Tue, Dec 10, 2013 at 10:59 PM, Kaul myk...@gmail.com wrote:

 And the above has been fixed.
 Regretfully, replaced by another compilation failure:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9543

 Y.


 On Tue, Dec 10, 2013 at 8:19 AM, Kaul myk...@gmail.com wrote:

 Above compilation failure has been fixed.
 Regretfully, only to be replaced by another compilation failure:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9538


 On Mon, Dec 9, 2013 at 2:49 PM, Kaul myk...@gmail.com wrote:

 Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the
 issue.


 On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki 
 darkjames...@darkjames.pl wrote:

 On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
  Thanks for the automated build links - I guess I'll watch them more
 closely
  and only sync when my platform passes.
 
  Interesting - I'm pulling from trunk and still fail on that. Perhaps
 it
  wasn't fixed entirely, or I have to do some cleanup?

 I agree, it isn't fixed, from_hex() is defined inside:
   #if defined(HAVE_LIBGNUTLS)  defined(HAVE_LIBGCRYPT)

 but it's used outside this #ifdef.


 Kuba.

 
 
  On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de
 wrote:
 
   On 12/08/2013 04:30 PM, Kaul wrote:
Hi all,
   
I've been trying to enhance a specific dissector for two weeks
 now.
Since I'm afraid of diverging the code (although I'm working on a
specific dissector), I update my code base often (~ once a day).
Regretfully, 5 times (in 2 weeks!) this has resulted in
 compilation
   failure.
I'm pretty sure (subjectively) this hasn't happened in the past.
 Any
measures we can put (continuous build system?) in place to
 prevent this?
   
Today's failure (2nd failure only today btw):
make[5]: Entering directory
 `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) !=
(ssl_session-session_id.data[i]  4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
   
Thanks,
Y.
  
   Hi,
  
   There are automated build, they are described here:
  
 http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html
  
   The last build results are here:
   http://buildbot.wireshark.org/trunk/one_line_per_build
  
   The problem you current have was already fixed in current trunk some
   hours ago.
  
   Hauke
  

 
 ___
  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





___
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] Build instability

[Kaul]

+ another failure that's fixed now - and I've managed to get Wireshark to
compile!
Woohoo! and thanks for the fixes.

Y.


On Tue, Dec 10, 2013 at 11:44 PM, Kaul myk...@gmail.com wrote:

 Also fixed, now epan/dissectors/packet-smpp.c is completely broken.
 This should fix it:
 svn diff epan/dissectors/packet-smpp.c
 Index: epan/dissectors/packet-smpp.c
 ===
 --- epan/dissectors/packet-smpp.c   (revision 53918)
 +++ epan/dissectors/packet-smpp.c   (working copy)
 @@ -85,7 +85,7 @@

  /* Forward declarations */
  void proto_register_smpp(void);
 -void proto_reg_handoff_smpp(void)
 +void proto_reg_handoff_smpp(void);
  static int dissect_smpp(tvbuff_t *tvb, packet_info *pinfo, proto_tree
 *tree, void* data);
  static guint get_smpp_pdu_len(packet_info *pinfo, tvbuff_t *tvb, int
 offset);
  static int dissect_smpp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree
 *tree, void* data _U_);



 On Tue, Dec 10, 2013 at 10:59 PM, Kaul myk...@gmail.com wrote:

 And the above has been fixed.
 Regretfully, replaced by another compilation failure:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9543

 Y.


 On Tue, Dec 10, 2013 at 8:19 AM, Kaul myk...@gmail.com wrote:

 Above compilation failure has been fixed.
 Regretfully, only to be replaced by another compilation failure:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9538


 On Mon, Dec 9, 2013 at 2:49 PM, Kaul myk...@gmail.com wrote:

 Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the
 issue.


 On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki 
 darkjames...@darkjames.pl wrote:

 On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
  Thanks for the automated build links - I guess I'll watch them more
 closely
  and only sync when my platform passes.
 
  Interesting - I'm pulling from trunk and still fail on that. Perhaps
 it
  wasn't fixed entirely, or I have to do some cleanup?

 I agree, it isn't fixed, from_hex() is defined inside:
   #if defined(HAVE_LIBGNUTLS)  defined(HAVE_LIBGCRYPT)

 but it's used outside this #ifdef.


 Kuba.

 
 
  On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de
 wrote:
 
   On 12/08/2013 04:30 PM, Kaul wrote:
Hi all,
   
I've been trying to enhance a specific dissector for two weeks
 now.
Since I'm afraid of diverging the code (although I'm working on a
specific dissector), I update my code base often (~ once a day).
Regretfully, 5 times (in 2 weeks!) this has resulted in
 compilation
   failure.
I'm pretty sure (subjectively) this hasn't happened in the past.
 Any
measures we can put (continuous build system?) in place to
 prevent this?
   
Today's failure (2nd failure only today btw):
make[5]: Entering directory
 `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of
 function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) !=
(ssl_session-session_id.data[i]  4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of
 function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
   
Thanks,
Y.
  
   Hi,
  
   There are automated build, they are described here:
  
 http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html
  
   The last build results are here:
   http://buildbot.wireshark.org/trunk/one_line_per_build
  
   The problem you current have was already fixed in current trunk
 some
   hours ago.
  
   Hauke
  

 
 ___
  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






___
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] Build instability

[Kaul]

Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the
issue.


On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki darkjames...@darkjames.plwrote:

 On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
  Thanks for the automated build links - I guess I'll watch them more
 closely
  and only sync when my platform passes.
 
  Interesting - I'm pulling from trunk and still fail on that. Perhaps it
  wasn't fixed entirely, or I have to do some cleanup?

 I agree, it isn't fixed, from_hex() is defined inside:
   #if defined(HAVE_LIBGNUTLS)  defined(HAVE_LIBGCRYPT)

 but it's used outside this #ifdef.


 Kuba.

 
 
  On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de wrote:
 
   On 12/08/2013 04:30 PM, Kaul wrote:
Hi all,
   
I've been trying to enhance a specific dissector for two weeks now.
Since I'm afraid of diverging the code (although I'm working on a
specific dissector), I update my code base often (~ once a day).
Regretfully, 5 times (in 2 weeks!) this has resulted in compilation
   failure.
I'm pretty sure (subjectively) this hasn't happened in the past. Any
measures we can put (continuous build system?) in place to prevent
 this?
   
Today's failure (2nd failure only today btw):
make[5]: Entering directory `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) !=
(ssl_session-session_id.data[i]  4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
   
Thanks,
Y.
  
   Hi,
  
   There are automated build, they are described here:
   http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html
  
   The last build results are here:
   http://buildbot.wireshark.org/trunk/one_line_per_build
  
   The problem you current have was already fixed in current trunk some
   hours ago.
  
   Hauke
  

 
 ___
  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

___
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] To display reserved fields or not display reserved fields, that is the question...

[Kaul]

Makes sense, done.


On Mon, Dec 9, 2013 at 2:34 AM, Edwin Groothuis 
edwin.grooth...@riverbed.com wrote:

  Hello,



 Display it. You are writing a dissector which describes the data seen on
 the wire, not one which goes “You are not interested in this”.



 Also, if there is something on the screen which says “Reserved” or a
 number of bits which say “Not in use” and there is a value in it, then you
 know that there has been some update in the protocol and that you need to
 update your dissector.



 Edwin



 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul
 *Sent:* Monday, 9 December 2013 02:54

 *To:* Developer support list for Wireshark
 *Subject:* [Wireshark-dev] To display reserved fields or not display
 reserved fields, that is the question...



 Should I:



 proto_tree_add_text(seg_param_tree, tvb, offset, 2, reserved);

 offset += 2;



 or:

 offset += 2; /* reserved */



 What is better? (Regretully I'm working on SCSI, whose creators LOVED
 sprinkling reserved bytes everywhere!).





 Do we have a standard? (perhaps worth having a global param for it?!).

 Y.

 ___
 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] Build instability

[Kaul]

Above compilation failure has been fixed.
Regretfully, only to be replaced by another compilation failure:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9538


On Mon, Dec 9, 2013 at 2:49 PM, Kaul myk...@gmail.com wrote:

 Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the
 issue.


 On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki 
 darkjames...@darkjames.plwrote:

 On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
  Thanks for the automated build links - I guess I'll watch them more
 closely
  and only sync when my platform passes.
 
  Interesting - I'm pulling from trunk and still fail on that. Perhaps it
  wasn't fixed entirely, or I have to do some cleanup?

 I agree, it isn't fixed, from_hex() is defined inside:
   #if defined(HAVE_LIBGNUTLS)  defined(HAVE_LIBGCRYPT)

 but it's used outside this #ifdef.


 Kuba.

 
 
  On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de
 wrote:
 
   On 12/08/2013 04:30 PM, Kaul wrote:
Hi all,
   
I've been trying to enhance a specific dissector for two weeks now.
Since I'm afraid of diverging the code (although I'm working on a
specific dissector), I update my code base often (~ once a day).
Regretfully, 5 times (in 2 weeks!) this has resulted in compilation
   failure.
I'm pretty sure (subjectively) this hasn't happened in the past. Any
measures we can put (continuous build system?) in place to prevent
 this?
   
Today's failure (2nd failure only today btw):
make[5]: Entering directory `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) !=
(ssl_session-session_id.data[i]  4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
   
Thanks,
Y.
  
   Hi,
  
   There are automated build, they are described here:
   http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html
  
   The last build results are here:
   http://buildbot.wireshark.org/trunk/one_line_per_build
  
   The problem you current have was already fixed in current trunk some
   hours ago.
  
   Hauke
  

 
 ___
  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



___
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] Build instability

[Kaul]

Hi all,

I've been trying to enhance a specific dissector for two weeks now.
Since I'm afraid of diverging the code (although I'm working on a specific
dissector), I update my code base often (~ once a day). Regretfully, 5
times (in 2 weeks!) this has resulted in compilation failure.
I'm pretty sure (subjectively) this hasn't happened in the past. Any
measures we can put (continuous build system?) in place to prevent this?

Today's failure (2nd failure only today btw):
make[5]: Entering directory `/home/yanivk/wireshark/epan/dissectors'
  CC   libdissectors_la-packet-ssl-utils.lo
packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
packet-ssl-utils.c:4201:9: error: implicit declaration of function
'from_hex_char' [-Werror=implicit-function-declaration]
 if (from_hex_char(line[2*i]) != (ssl_session-session_id.data[i]
 4) ||
 ^
packet-ssl-utils.c:4218:5: error: implicit declaration of function
'from_hex' [-Werror=implicit-function-declaration]
 if (!from_hex(ssl_session-master_secret, line, len))
 ^
cc1: all warnings being treated as errors
make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1

Thanks,
Y.
___
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] To display reserved fields or not display reserved fields, that is the question...

[Kaul]

Should I:

proto_tree_add_text(seg_param_tree, tvb, offset, 2, reserved);
offset += 2;

or:
offset += 2; /* reserved */

What is better? (Regretully I'm working on SCSI, whose creators LOVED
sprinkling reserved bytes everywhere!).


Do we have a standard? (perhaps worth having a global param for it?!).
Y.
___
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] Build instability

[Kaul]

Thanks for the automated build links - I guess I'll watch them more closely
and only sync when my platform passes.

Interesting - I'm pulling from trunk and still fail on that. Perhaps it
wasn't fixed entirely, or I have to do some cleanup?


On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens ha...@hauke-m.de wrote:

 On 12/08/2013 04:30 PM, Kaul wrote:
  Hi all,
 
  I've been trying to enhance a specific dissector for two weeks now.
  Since I'm afraid of diverging the code (although I'm working on a
  specific dissector), I update my code base often (~ once a day).
  Regretfully, 5 times (in 2 weeks!) this has resulted in compilation
 failure.
  I'm pretty sure (subjectively) this hasn't happened in the past. Any
  measures we can put (continuous build system?) in place to prevent this?
 
  Today's failure (2nd failure only today btw):
  make[5]: Entering directory `/home/yanivk/wireshark/epan/dissectors'
CC   libdissectors_la-packet-ssl-utils.lo
  packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id':
  packet-ssl-utils.c:4201:9: error: implicit declaration of function
  'from_hex_char' [-Werror=implicit-function-declaration]
   if (from_hex_char(line[2*i]) !=
  (ssl_session-session_id.data[i]  4) ||
   ^
  packet-ssl-utils.c:4218:5: error: implicit declaration of function
  'from_hex' [-Werror=implicit-function-declaration]
   if (!from_hex(ssl_session-master_secret, line, len))
   ^
  cc1: all warnings being treated as errors
  make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1
 
  Thanks,
  Y.

 Hi,

 There are automated build, they are described here:
 http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html

 The last build results are here:
 http://buildbot.wireshark.org/trunk/one_line_per_build

 The problem you current have was already fixed in current trunk some
 hours ago.

 Hauke

___
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] Compilation failure - privileges.c: In function 'relinquish_special_privs_perm' - ignoring return value of 'setresgid', declared with attribute warn_unused_result [-Werror=unused-resul

[Kaul]

Recently (~2 days or so ago?), I've failed to compile wireshark, on F17/x64:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -DINET6
-DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE
-DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES
-D_U_=__attribute__((unused)) -D_FORTIFY_SOURCE=2 -I/usr/local/include
-DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.9.0\ -Werror -g -O2
-Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels
-Wpointer-arith -Wno-pointer-sign -Warray-bounds -Wcast-align
-Wformat-security -Wold-style-definition -Wno-error=unused-but-set-variable
-fexcess-precision=fast -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15
-MT privileges.lo -MD -MP -MF .deps/privileges.Tpo -c privileges.c  -fPIC
-DPIC -o .libs/privileges.o
privileges.c: In function 'relinquish_special_privs_perm':
privileges.c:275:12: error: ignoring return value of 'setresgid', declared
with attribute warn_unused_result [-Werror=unused-result]
privileges.c:282:12: error: ignoring return value of 'setresuid', declared
with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors



If it were git, I'm sure I could easily use 'git bisect' and find the issue.
Without it, I'm really unsure - as the last change to this file took place
some time ago.

TIA,
Y.
___
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 - privileges.c: In function 'relinquish_special_privs_perm' - ignoring return value of 'setresgid', declared with attribute warn_unused_result [-Werror=unused-r

[Kaul]

On Mon, Aug 20, 2012 at 11:11 PM, Evan Huus eapa...@gmail.com wrote:

 On Mon, Aug 20, 2012 at 3:49 PM, Kaul myk...@gmail.com wrote:
  Recently (~2 days or so ago?), I've failed to compile wireshark, on
 F17/x64:
 
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -DINET6
  -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE
  -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES
  -D_U_=__attribute__((unused)) -D_FORTIFY_SOURCE=2 -I/usr/local/include
  -DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.9.0\ -Werror -g -O2
 -Wall
  -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
  -Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security
  -Wold-style-definition -Wno-error=unused-but-set-variable
  -fexcess-precision=fast -pthread -I/usr/include/gtk-2.0
  -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
  -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
  -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
  -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15
 -MT
  privileges.lo -MD -MP -MF .deps/privileges.Tpo -c privileges.c  -fPIC
 -DPIC
  -o .libs/privileges.o
  privileges.c: In function 'relinquish_special_privs_perm':
  privileges.c:275:12: error: ignoring return value of 'setresgid',
 declared
  with attribute warn_unused_result [-Werror=unused-result]
  privileges.c:282:12: error: ignoring return value of 'setresuid',
 declared
  with attribute warn_unused_result [-Werror=unused-result]
  cc1: all warnings being treated as errors
 
 
 
  If it were git, I'm sure I could easily use 'git bisect' and find the
 issue.
  Without it, I'm really unsure - as the last change to this file took
 place
  some time ago.

 We do have a read-only git mirror at [1].


OK, might switch to it. Is it reliable?



 If the last change to the file happened a while ago (presumably long
 before the issue started appearing) then it's likely your toolchain
 changed recently. Did you install a gcc or libc update in the last
 couple of days?


Perhaps -
Aug 16 12:42:10 Updated: glibc-common-2.15-54.fc17.x86_64
Aug 16 12:42:12 Updated: glibc-2.15-54.fc17.x86_64
Aug 16 12:42:13 Updated: glibc-headers-2.15-54.fc17.x86_64
Aug 16 12:42:14 Updated: glibc-devel-2.15-54.fc17.x86_64
Aug 16 12:42:18 Updated: glibc-2.15-54.fc17.i686
Aug 19 08:39:11 Updated: glibc-2.15-56.fc17.x86_64
Aug 19 08:39:35 Updated: glibc-common-2.15-56.fc17.x86_64
Aug 19 08:39:47 Updated: glibc-headers-2.15-56.fc17.x86_64
Aug 19 08:41:05 Updated: glibc-devel-2.15-56.fc17.x86_64
Aug 19 08:41:20 Updated: glibc-2.15-56.fc17.i686


 Not that it isn't our fault (assuming the warning isn't a false
 positive), it's just likely that only the most recent gcc/libc
 toolchain will warn on the problem.


As a workaround, added  --disable-warnings-as-errors to my config options.

Thanks,
Y.


 Thanks for the report,
 Evan

 [1] http://code.wireshark.org/git/wireshark
 ___
 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] Some questions on RPC dissectors (for a new Gluster dissector)

[Kaul]

On Fri, Apr 20, 2012 at 6:08 PM, Niels de Vos nde...@redhat.com wrote:

 Hi all,

 Bug 5773 was opened as an RFE for implementing a dissector for Gluster.
 The Gluster 'protocol' consists out of several RPC-programs, each with
 their own set of procedures.

 There are some questions I would like to ask:

 1)
 I am not sure what the best practice is to group these related
 RPC-programs. At the moment, I have a packet-gluster.c file (and a header)
 that registers proto_gluster with proto_register_protocol().

 Each dissector for an RPC-program registers its header-field-array with
 this proto_gluster handle. Some of the RPC-programs have their own file, to
 the proto_gluster handle is made non-static and exported in the
 packet-gluster.h file.

 Is this something that I should rather not do, and create complete
 separate dissectors for each RPC-program? There are some header-fields that
 are the same for several RPC-programs, should these just be duplicated?
 (Currently these are non-static as well, and listed in the header file too.)



You can have a packet-gluster-common.{c|h} file(s).



 If I can keep using this structure, how can I guarantee that the
 proto_gluster handle has been initialized when other dissectors try to use
 it with proto_register_field_array()?

 2)
 The Gluster protocols use RPC-credentials with number 5. This number is
 currently not dissected in packet-rpc.c, but I also doubt IANA assigned
 this number to the Gluster protocols. What would be the best way to add an
 implementation to dissect the credentials in the RPC-header?

 a) just dissect any number 5 flavour as Gluster-credentials


Google around to see if others may have (ab)used this number as well. If
not, I'd just dissect it as Gluster's - with a comment in the code
explaining it is non registered to Gluster (and worth shooting an email to
the gluster dev list asking if they intend to register it).

Y.

b) add a preference-option to the RPC-dissector
 c) detect the credential-flavour based on flavour+program number
 d) something else, please specify


 That's it for now. I'm happy to provide more details if that would clarify
 my questions.

 Many thanks,
 Niels
 __**__**
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:
 http://www.wireshark.org/**lists/wireshark-devhttp://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: 
 https://wireshark.org/mailman/**options/wireshark-devhttps://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-request@**wireshark.orgwireshark-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

[Wireshark-dev] Keyboard scan codes

[Kaul]

Hi,

I was wondering if there is somewhere in Wireshark code definition for
keyboard scan codes. I was hoping to re-use if such exists. I'm looking for
101/102 AT keyboard scan codes, specifically (was hoping RDP or VNC would
have them, but did not find it, neither did Telnet). I don't think what X11
uses would suite me.

TIA,
Y.
___
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] Wireshark crashes on tvb_get_const_stringz()

[Kaul]

I might have used tvb_get_const_stringz() incorrectly, yet I don't think
Wireshark should crash:
Program received signal SIGSEGV, Segmentation fault.
tvb_get_const_stringz (tvb=0x1c01b60, offset=10, lengthp=0x9) at
tvbuff.c:2548
2548 *lengthp = size;


I'm not entirely sure why it crashes yet or why I am using it incorrectly.
I'll look into it.
Using r41685.
Thanks,
Y.
___
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 crashes on tvb_get_const_stringz()

[Kaul]

On Tue, Mar 20, 2012 at 3:19 PM, Jakub Zawadzki
darkjames...@darkjames.plwrote:

 On Tue, Mar 20, 2012 at 03:04:23PM +0200, Kaul wrote:
  I might have used tvb_get_const_stringz() incorrectly, yet I don't think
  Wireshark should crash:
  Program received signal SIGSEGV, Segmentation fault.
  tvb_get_const_stringz (tvb=0x1c01b60, offset=10, lengthp=0x9) at
  tvbuff.c:2548
  2548 *lengthp = size;
 
  I'm not entirely sure why it crashes yet or why I am using it
 incorrectly.

 Last argument of tvb_get_const_stringz() takes pointer to integer (not
 value!)
 and stores length of string in it.

 If you want to get next N chars (not NUL terminated), and store it as
 C-string you
 can use tvb_get_ephemeral_string() instead.


Yep, discovered that. My fault. Sorry for the noise.
Y.


 ___
 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

[Wireshark-dev] Incomplete SSL dissection (when not on standard port)

[Kaul]

I sniff traffic on port 8443, which is SSL based.
Unless I add to HTTP dissector that port, as SSL based, de-segmentation of
SSL records fails (meaning, if it began from the middle of one TCP packet
and ends in another, it is not dissected properly).
'Decode As' is what I've used before trying the trick to add to the HTTP
dissector prefs the SSL port - any idea why it doesn't work?
I have a hunch that the HTTP method calls 'ssl_dissector_add()', while
'decode as' will call dissect_ssl(), which probably misses registering the
dissector to that port, but perhaps I'm missing something else.

Any ideas? (I can open a bug about this of course).
TIA,
Y
___
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] SASL layer dissection - generic dissector?

[Kaul]

Is there some ideas for dissecting SASL based authentication generically?
I've seen some in LDAP, but I'm sure others can benefit it as well.
I couldn't even understand if there is such a thing as 'generic SASL', as it
appears most of it is left to the protocol implementation, but still...
Otherwise, I'll have to do it for my protocol, which is a bit of an
annoyance.

TIA,
Y.
___
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] Correct and efficient way of displaying bit fields?

[Kaul]

I'm struggling for some time now with displaying bitfields, I'm sure there
must be something I'm overlooking, or it's just a bit difficult to do in
Wireshark.

I have a 32bit, little endian field, which I'd like to parse the bits (as
set/not set):
Example:
05 00 00 00

1 0 0 0  Feature A - set
0 0 0 0 ... Feature B - not set
0 0 1 0 ... Feature C - Set


1. Do I really have to create a hf_xxx for each? And use something like
proto_tree_add_bits_item() ? I was hoping to do it in a single
proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...)
which will describe all the attributes.
2. How do I take into consideration the endianess?

Best I could do so far, it works but it's ugly and not maintainable, is:
proto_tree_add_bits_item(tree, hf_common_cap_auth_select, tvb, (offset * 8)
+ 7, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_spice, tvb, (offset * 8) +
6, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_sasl, tvb, (offset * 8) +
5, 4, ENC_NA);

...

{ hf_common_cap_auth_select,
  { Auth Selection, spice.common_cap_auth_select,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_spice,
  { Auth Spice, spice.common_cap_auth_spice,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_sasl,
  { Auth SASL, spice.common_cap_auth_sasl,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},


If I look at how it's done in packet-tcp.c, then it's again quite a bit of
manual labour, this time with proto_tree_add_boolean() - per each single
bit!
Is there a better way?

TIA,
Y.
___
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] core dump on starting wireshark (latest SVN update 39266?)

[Kaul]

It was actually the ~/.wireshark/recent_common that caused this - and when
you'll look at it, it's obvious why - though I have no clue how I got to
this situation.
Y.

On Wed, Oct 5, 2011 at 10:23 PM, Stephen Fisher st...@stephen-fisher.comwrote:

 On Wed, Oct 05, 2011 at 10:07:36PM +0200, Kaul wrote:

  I'm on #39276. Something tells me that until I delete the prefs., it's
  not going to go away :(

 Do a mv ~/.wireshark/preferences ~/.wireshark/preferences.old and see
 if it works fine after that.  If so, sharing your preferences.old file
 with us may allow us to repliate the problem.
 ___
 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



recent_common.old
Description: Binary data
___
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] core dump on starting wireshark (latest SVN update 39266?)

[Kaul]

(gdb) bt
#0  0x00316b8482a0 in g_markup_escape_text () from
/lib64/libglib-2.0.so.0
#1  0x004629b6 in welcome_filename_link_new (menu_item=0x1a04d30,
label=read_sleb128: Corrupted DWARF expression.
) at main_welcome.c:626
#2  main_welcome_add_recent_capture_file (widget_cf_name=0x185e900
/home/ykaul/wireshark/\212\340\001, menu_item=0x1a04d30) at
main_welcome.c:706
#3  0x004550c4 in add_recent_items (merge_id=5,
ui_manager=0x17abb20) at main_menubar.c:3927
#4  0x004575a4 in add_menu_recent_capture_file (cf_name=optimized
out) at main_menubar.c:4122
#5  0x0047c575 in read_set_recent_pair_dynamic (key=optimized out,
value=0x1a00f50 \212\340\001, private_data=optimized out,
return_range_errors=optimized out)
at recent.c:740
#6  0x75732a96 in read_prefs_file (pf_path=0x880b80
/home/ykaul/.wireshark/recent_common, pf=0x1a05800,
pref_set_pair_fct=0x47c500 read_set_recent_pair_dynamic,
private_data=0x0) at prefs.c:1531
#7  0x0047e12e in recent_read_dynamic
(rf_path_return=0x7fffe078, rf_errno_return=0x7fffe0b4) at
recent.c:945
#8  0x0042d7e4 in main (argc=0, argv=0x7fffe1e0) at main.c:2875

It worked before the massive updates of last night (which I'm not sure
unrelated). It's a bit more difficult to dissect in SVN, so hopefully
someone has a clue what went wrong.
Y.
___
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] core dump on starting wireshark (latest SVN update 39266?)

[Kaul]

On Wed, Oct 5, 2011 at 4:25 PM, Bill Meier wme...@newsguy.com wrote:

 On 10/5/2011 4:57 AM, Kaul wrote:


 It worked before the massive updates of last night (which I'm not sure
 unrelated). It's a bit more difficult to dissect in SVN, so hopefully
 someone has a clue what went wrong.
 Y.


 Wireshark (SVN #39269) works OK on my Windows and Fedora 32-bit systems.


 Are you still having problems ??


Yes, I do. 'svn update' followed by 'make clean ; make distclean ; my
config script ; make' did not help.
This morning I was on Fedora 15/64b, now on Fedora16beta/64b.
I'm on #39276. Something tells me that until I delete the prefs., it's not
going to go away :(
Y.




 __**__**
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:
 http://www.wireshark.org/**lists/wireshark-devhttp://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: 
 https://wireshark.org/mailman/**options/wireshark-devhttps://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-request@**wireshark.orgwireshark-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

[Wireshark-dev] Display multiple frames (of multiple TCP segments) in COL_INFO

[Kaul]

Hi,

I've tried to mimic what the SSL dissector does, which is able to display
multiple PDUs information in the COL_INFO ('Application Data, Application
Data, Application Data' for example).
It only partially works:
If I have a packet which has:
1. The last part of a PDU which started in previous packets
2. More PDUs

It'll only display PDU 1 from the PDUs - as it is indeed the only PDU in the
frame.

It appears I need to do this check per frame - although my dissector is
called per conversation. Any ideas?

TIA,
Y.
___
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] Latest SVN (r38309) doesn't compile (packet-6lowpan.c)

[Kaul]

Fedora15/x64, r38309:

packet-6lowpan.c: In function 'dissect_6lowpan_frag_first':
packet-6lowpan.c:2125:25: error: 'save_fragmented' undeclared (first use in
this function)
packet-6lowpan.c:2125:25: note: each undeclared identifier is reported only
once for each function it appears in
packet-6lowpan.c: In function 'dissect_6lowpan_frag_middle':
packet-6lowpan.c:2221:25: error: 'save_fragmented' undeclared (first use in
this function)
___
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] Latest SVN (r38309) doesn't compile (packet-6lowpan.c)

[Kaul]

Strange indeed. I don't recall ever touching that dissector.
Sorry for the noise.
Y.

On Tue, Aug 2, 2011 at 4:42 PM, Bill Meier wme...@newsguy.com wrote:

 On 8/2/2011 6:47 AM, Kaul wrote:

 Fedora15/x64, r38309:

 packet-6lowpan.c: In function 'dissect_6lowpan_frag_first':
 packet-6lowpan.c:2125:25: error: 'save_fragmented' undeclared (first use
 in
 this function)
 packet-6lowpan.c:2125:25: note: each undeclared identifier is reported
 only
 once for each function it appears in
 packet-6lowpan.c: In function 'dissect_6lowpan_frag_middle':
 packet-6lowpan.c:2221:25: error: 'save_fragmented' undeclared (first use
 in
 this function)



 Strange:

 The code (SVN) looks Ok  the buildbots aren't complaining.

 Also: the line numbers above don't quite match the packet-6lowpan.c source
 in SVN.

 Does your copy match SVN ??


 Bill

 __**__**
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:
 http://www.wireshark.org/**lists/wireshark-devhttp://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: 
 https://wireshark.org/mailman/**options/wireshark-devhttps://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-request@**wireshark.orgwireshark-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] New GCC, new option required?

[Kaul]

- I've also tried to provide fixes for some (until I got both tired and
unable to fix those that result from the ASN.1 definitions) in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5858.
- CLANG static analyzer was also quite helpful in finding issues. It just
takes hours to compile wireshark with it.
- First time I've heard of ptvcursors. Nice.

Y.


On Thu, Jul 14, 2011 at 5:51 AM, Bill Meier wme...@newsguy.com wrote:

 On 7/13/2011 7:38 PM, Guy Harris wrote:


 Haven't you (and maybe others) been fixing the same issues already,
 as  a result of Coverity warnings about the same thing?

 And how many of those are

 static void
 dissect_whatever(...)
 {

...

proto_tree_add_item(tree, hf_foo, tvb, offset, len_foo, encoding);
offset += len_foo;
proto_tree_add_item(tree, hf_bar, tvb, offset, len_bar, encoding);
offset += len_bar;
 }

 and how many of those ultimately represent dissectors that should be
 converted to use ptvcursors, in which case the offset += stuff will
 disappear into the ptvcursor code and not get whined about by dataflow
 analyzers?


 I'd have to go back and look but I guess that some of the Coverity
 [unused] defects for the dissectors were related to the pattern as shown
 above:
 {
...
offset += ...;
 }



 However, ISTR that many more were related to the following pattern:
 {
...
foo = proto_tree_add_item(...);
offset += ...;
foo = proto_tree_add_item(...);
...
 }

 Others were real bugs (such doing 'foo=proto_item_add_subtree()' and then
 failing to use the returned value in following 'proto_tree_add_item()'
 calls.

 At some point I stopped fixing Coverity [unused] even though ISTR that
 were (at least a few) more unused defects yet to be fixed.

 Some time later I started working on the GCC 4.6 set-but-unused warnings.

 I now see (after doing a little research) that it appears that the unused
 defects found by Coverity were only a subset of the unused-but-set cases
 found by GCC 4.6.

 I don't know what the pattern is for things not found by Coverity but I do
 note that many cases like the following weren't found by Coverity:

 {
...
int foo;
...
foo = ...;
...
 }


 In any case: Since much of the Coverity [unused dissector cases have
 already been fixed, much of the remaining (non-generated) dissector
 set-but-not-used cases seem to be for stuff not found by Coverity
 [unused].

 (See SVN #37716 for many examples of this type of fix).



 __**__**
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:
 http://www.wireshark.org/**lists/wireshark-devhttp://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: 
 https://wireshark.org/mailman/**options/wireshark-devhttps://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-request@**wireshark.orgwireshark-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

[Wireshark-dev] Crash in capture_dlg.c:1890 (latest SVN)

[Kaul]

When trying to run wireshark, then - capture - options from SVN 36928,
F15beta/x86_64:

#0  0x003be1a36415 in raise () from /lib64/libc.so.6
#1  0x003be1a37d2b in abort () from /lib64/libc.so.6
#2  0x003be1a723b3 in __libc_message () from /lib64/libc.so.6
#3  0x003be1a788aa in malloc_printerr () from /lib64/libc.so.6
#4  0x003591249ac3 in g_free () from /lib64/libglib-2.0.so.0
#5  0x004ca5ca in capture_prep_cb (w=optimized out,
d=optimized out) at capture_dlg.c:1890
#6  0x003591a0e2ee in g_closure_invoke () from
/lib64/libgobject-2.0.so.0
#7  0x003591a1f1a0 in ?? () from /lib64/libgobject-2.0.so.0
#8  0x003591a28972 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#9  0x003591a28b12 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#10 0x0031cbe8341e in gtk_widget_activate ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#11 0x0031cbd6638d in gtk_menu_shell_activate_item ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#12 0x0031cbd66772 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#13 0x0031cbd4f103 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x003591a0e2ee in g_closure_invoke () from
/lib64/libgobject-2.0.so.0
#15 0x003591a1efba in ?? () from /lib64/libgobject-2.0.so.0
#16 0x003591a2872b in g_signal_emit_valist ()
___
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] Failure to run pidl for dce-rpc MAPI dissector

[Kaul]

I'm trying the following:

[ykaul@ykaul mapi]$ pwd
/home/ykaul/wireshark/epan/dissectors/pidl/mapi
[ykaul@ykaul mapi]$ ls -ltr
total 316
-rw-rw-r--. 1 ykaul ykaul 228274 Apr 27 11:01 mapitags_enum.h
-rw-rw-r--. 1 ykaul ykaul   8410 Apr 27 11:01 response.cnf.c
-rw-rw-r--. 1 ykaul ykaul   3684 Apr 27 11:01 mapi.cnf
-rw-rw-r--. 1 ykaul ykaul670 Apr 27 11:01 Makefile
-rw-rw-r--. 1 ykaul ykaul  47739 Apr 27 11:01 mapi.idl
-rw-rw-r--. 1 ykaul ykaul   5710 Apr 27 11:01 mapicodes_enum.h
-rw-rw-r--. 1 ykaul ykaul  10189 Apr 27 11:01 request.cnf.c
-rw-rw-r--. 1 ykaul ykaul   2036 Apr 27 11:01 idl_types.h
[ykaul@ykaul mapi]$ pidl --ws-parser -- mapi.idl
Compiling mapi.idl
mapi.idl:422: warning: subcontext() is deprecated. Use represent_as() or
transmit_as() instead
mapi.idl:1592: EcDoRpc: property 'flag' not allowed on 'FUNCTION'
[ykaul@ykaul mapi]$ ls -ltr
total 316
-rw-rw-r--. 1 ykaul ykaul 228274 Apr 27 11:01 mapitags_enum.h
-rw-rw-r--. 1 ykaul ykaul   8410 Apr 27 11:01 response.cnf.c
-rw-rw-r--. 1 ykaul ykaul   3684 Apr 27 11:01 mapi.cnf
-rw-rw-r--. 1 ykaul ykaul670 Apr 27 11:01 Makefile
-rw-rw-r--. 1 ykaul ykaul  47739 Apr 27 11:01 mapi.idl
-rw-rw-r--. 1 ykaul ykaul   5710 Apr 27 11:01 mapicodes_enum.h
-rw-rw-r--. 1 ykaul ykaul  10189 Apr 27 11:01 request.cnf.c
-rw-rw-r--. 1 ykaul ykaul   2036 Apr 27 11:01 idl_types.h


So nothing seems to be happening.

The fix I'm actually interested is in request.cnf.c, but I would like to
test it and generate a new packet-dcerpc-mapi.c to test with.

TIA,
Y.
___
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] Trying to fix gcc's 'set but not used' errors on Whireshark

[Kaul]

Hi,

I'm trying to fix gcc 4.6's 'variable set but not used' errors that
wireshark compilation currently produces, via
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5858 .
I've already fixed quite a few of them. Most are trivial, those that weren't
I've remarked in the attachment comments.

- As I'm doing it file by file, I haven't made a lot of progress. All
epan/dissectors/packet-{a,b}* are done, I'm now into packet-c* ... Many more
to go - does anyone have a better process/idea how to accomplish that?
- Fearing that it'll take me ages, what can be done so at least some of
those will get into committed sooner rather than later?

TIA,
Y.
___
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 to remove/unregister a dissector?

[Kaul]

On Tue, Apr 26, 2011 at 9:57 PM, Chris Maynard chris.mayn...@gtech.comwrote:

 George Nychis gnychis@... writes:

  Another alternative, is to remove packet-smb* from the build.

 In most cases, to remove unwanted protocol dissectors from the build,
 delete the
 relevant packet-*.c files from epan/dissectors/Makefile.common's
 DISSECTOR_SRC.

 Alternatively, you could just disable those protocols via Analyze -
 Enabled
 Protocols, then uncheck all those that you don't want/need.  This method
 does
 not require recompiling Wireshark, but it doesn't prevent someone from
 re-enabling them again, so if you want to avoid that, then you'll have to
 recompile it.


If it could only be done somehow with some logical grouping... I do not need
many, many protocols, but it's impossible to go and start unchecking all the
irrelevant ones. Too many.
For example, I reckon I'll never meet ATM traffic, nor Appletalk, nor USB
based, bluethooth or anything but normal Ethernet, IP and above  (and yes,
if somehow something was encapsulated above Etherenet, so I lost it, no big
deal). Probably cost some in performance as well, especially for some of the
heuristic ones.

I'm also unsure how much of a performance hit we get by having all those
less used protocol fields in packet_info structure. Perhaps we should move
all those to a dynamically allocated (if need access to) structure. Random
example (from gssapi, which actually I see, but never decrypt):
  guint16 decrypt_gssapi_tvb;
  tvbuff_t *gssapi_wrap_tvb;
  tvbuff_t *gssapi_encrypted_tvb;
  tvbuff_t *gssapi_decrypted_tvb;
  gboolean gssapi_data_encrypted;


 (is packet_info even properly memory aligned with all those 'random' sized
fields in it?!)
Y.




 ___
 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

[Wireshark-dev] Compilation failure (mv: cannot stat `.deps/privileges.Tpo': No such file or directory)

[Kaul]

r36767, Fedora 15/x64 beta, gcc (GCC) 4.6.0 20110419 (Red Hat 4.6.0-5) :

make[2]: Entering directory `/home/ykaul/wireshark/wsutil'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
-I./..  -I/usr/local/include
'-DPLUGIN_DIR=/usr/local/lib/wireshark/plugins/1.5.2'  -DINET6
-D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
-Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security
-fexcess-precision=fast -I/usr/local/include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
-MT privileges.lo -MD -MP -MF .deps/privileges.Tpo -c -o privileges.lo
privileges.c
mv -f .deps/privileges.Tpo .deps/privileges.Plo
mv: cannot stat `.deps/privileges.Tpo': No such file or directory
make[2]: *** [privileges.lo] Error 1
make[2]: Leaving directory `/home/ykaul/wireshark/wsutil'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ykaul/wireshark'
make: *** [all] Error 2
___
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] Build failure: k12.c:275:11: error: variable 'actual_len' set but not used [-Werror=unused-but-set-variable]

[Kaul]

r36676, under F15/x64, gcc (GCC) 4.6.0 20110413 (Red Hat 4.6.0-4)


libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I/usr/local/include
-DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.5.2\ -Werror -DINET6
-D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
-Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security
-fexcess-precision=fast -I/usr/local/include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -MT
libwiretap_la-k12.lo -MD -MP -MF .deps/libwiretap_la-k12.Tpo -c k12.c  -fPIC
-DPIC -o .libs/libwiretap_la-k12.o
k12.c: In function 'get_record':
k12.c:275:11: error: variable 'actual_len' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors


Thanks,
Y.
___
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] Request to review https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4334 and https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5495

[Kaul]

I'd appreciate if someone could review and, if approved, check in the above
patches. They fix some VNC encoding errors and add some more parsing.
Especially the hextile is a bit problematic - it works on single packet
hextile encoding only (as no de-sgementation support is available - I have a
partial implementation there as well), but it's much more correct than the
current parsing, which is plain wrong.

Thanks in advance,
Yaniv.
___
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] UDP desegmentation - how to?

[Kaul]

Can I use something like tcp_dissect_pdus() for UDP packets? Specifically,
Kerberos over UDP - I think we can get the PDU length from the packet and
get a complete PDU.
___
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] [work in progress / stuck] improved dissection for VNC (correct hextile encoding, correct desegmentation)

[Kaul]

On Wed, Dec 15, 2010 at 4:29 PM, Jeff Morriss jeff.morriss...@gmail.comwrote:

 Kaul wrote:
  3. Corrected hextile encoding parsing. It's quite wrong the way it's
  done today (see 2nd rectangle in packet 23 of the attached sample
  capture). It completely ignored the fact that the hextile encoding is
  actually encoding a series of 16 by 16 pixel tiles (hence hexTILE, I
  reckon). This presents another problem which I don't know how to solve -
  I'm getting too many (legitimate!) items in my tree - and wireshark
  thinks I'm in an infinite loop. The fact it, each update may have
  several rectangles, each may have subrectables, each may have tiles...
  it's endless if the screen is big enough.

 Hmmm, are the items really of that much interest to a user?  I mean,
 would someone really want to look at all 150,000 tiles (or whatever)
 one-by-one?  I would guess not, in which case it would probably make
 sense to just have an item that says 150,000 tiles.


Well, it is interesting if you have few of them, to see how the protocol
really works. I guess I should stop adding them at some point... first 100
or so? if it's smaller than a packet size?
Nevertheless, one might want to find oddities in the protocol
implementation, and then he will need all of the data.
Y.

___
 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] [work in progress / stuck] improved dissection for VNC (correct hextile encoding, correct desegmentation)

[Kaul]

On Mon, Dec 13, 2010 at 11:29 PM, Christopher Maynard 
chris.mayn...@gtech.com wrote:

 Kaul myk...@... writes:

  Hi,Attached please find an incomplete, work-in-progress improved
 dissection of
 the VNC protocol.

 Hi Kaul, I think it would be better to open a bug report for this and
 submit the
 patches there.  That way, the patches won't be forgotten.


Indeed, good idea - I've attached it to the already open
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4334 .
In addition, already submitted parts of the work via a different bugzilla
entry (patch applicable to the current dissector) and plan to follow up with
another two or so patches.
Y.




 ___
 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

[Wireshark-dev] Can someone review https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5372 ?

[Kaul]

I keep hitting this bug in my tests.
I've provided a partial patch to the bug but also a more general patch to
the issue.

TIA,
Y.
___
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] Some more question on TCP desegmentation

[Kaul]

1. If only some of the segments (say, first 50 out of 70), will I get that
partial PDU, or just the original TVB (the first packet, essentially)?
2. I'm fighting hard with LDAP not being de-segmented properly, only to find
out that in tcp_dissect_pdus(), pinfo-can_desgement is false. What could be
the reasons for that?

TIA,
Y.
___
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] Some more question on TCP desegmentation

[Kaul]

On Wed, Dec 1, 2010 at 8:22 AM, Andreas andreassand...@gmx.net wrote:

 Am 30.11.2010 13:05, schrieb Kaul:
  1. If only some of the segments (say, first 50 out of 70), will I get
 that
  partial PDU, or just the original TVB (the first packet, essentially)?

 Don't know what you ask for. But when you call tcp_dissect_pdus(), you
 pdu_dissect function will get a fresh new TVB with that part.


Which part exactly? A new tvb in the length of the original TVB, or in the
length of as-much-PDU-as-it-could-fetch?
Y.



 --
 Andy

 ___
 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

[Wireshark-dev] Strange desegmentation code in packet-ssl?

[Kaul]

Any idea why isn't the SSL dissector using the straightforward
desgementation facilities available by Wireshark?
It is left over from ancient times? It seems like a complex piece of work,
instead of nicely using the PDUs dissection infrastructure - and I believe
that SSL is a classic protocol for this.

Specifically, it seems to fail to desegment segmented records in the
handshake process (on SSL on a non-standard port, coincidence?).
I wonder how much of an effort it'd be to 'convert' it. Anyone looked at it
before?

TIA,
Y.
___
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] Build broken in asn1/x721 (r34777)?

[Kaul]

Trying to re-build the ASN1 dissectors (is 'make' within the ASN1 the right
way to do it?) breaks:
Making all in x721
make[1]: Entering directory `/home/ykaul/wireshark/asn1/x721'
python ../../tools/asn2wrs.py \
 \
-p dummy \
-c ./dummy.cnf \
-s ./packet-dummy-template \
-D . \

ASN.1 to Wireshark dissector compiler

asn2wrs [-h|?] [-d dbg] [-b] [-p proto] [-c cnf_file] [-e] input_file(s) ...
  -h|?  : Usage
  -b: BER (default is PER)
  -u: Unaligned (default is aligned)
  -p proto  : Protocol name (implies -S). Default is module-name
  from input_file (renamed by #.MODULE if present)
  -o name   : Output files name core (default is proto)
  -O dir: Output directory
  -c cnf_file   : Conformance file
  -I path   : Path for conformance file includes
  -e: Create conformance file for exported types
  -E: Just create conformance file for exported types
  -S: Single output for multiple modules
  -s template   : Single file output (template is input file
  without .c/.h extension)
  -k: Keep intermediate files though single file output is used
  -L: Suppress #line directive from .cnf file
  -D dir: Directory for input_file(s) (default: '.')
  -C: Add check for SIZE constraints
  -r prefix : Remove the prefix from type names

  input_file(s) : Input ASN.1 file(s)

  -d dbg: Debug output, dbg = [l][y][p][s][a][t][c][m][o]
  l - lex
  y - yacc
  p - parsing
  s - internal ASN.1 structure
  a - list of assignments
  t - tables
  c - conformance values
  m - list of compiled modules with dependency
  o - list of output files

make[1]: *** [packet-dummy.c] Error 2
make[1]: Leaving directory `/home/ykaul/wireshark/asn1/x721'
make: *** [all-recursive] Error 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] Build broken in asn1/x721 (r34777)?

[Kaul]

So how *do* I build Wireshark now? It seems to affect the normal build:
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I./../.. -I./..
-I/usr/local/include -DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.5.0\
-Werror -DINET6 -D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
-Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security
-fexcess-precision=fast -I/usr/local/include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -MT
libdissectors_la-packet-dcerpc-netlogon.lo -MD -MP -MF
.deps/libdissectors_la-packet-dcerpc-netlogon.Tpo -c
packet-dcerpc-netlogon.c  -fPIC -DPIC -o
.libs/libdissectors_la-packet-dcerpc-netlogon.o
cc1: warnings being treated as errors
packet-dcerpc-netlogon.c: In function ‘get_keytab_as_list’:
packet-dcerpc-netlogon.c:6846:5: error: implicit declaration of function
‘read_keytab_file_from_preferences’
make[5]: *** [libdissectors_la-packet-dcerpc-netlogon.lo] Error 1
make[5]: Leaving directory `/home/ykaul/wireshark/epan/dissectors'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/ykaul/wireshark/epan/dissectors'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/ykaul/wireshark/epan/dissectors'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ykaul/wireshark/epan'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ykaul/wireshark'
make: *** [all] Error 2


On Thu, Nov 4, 2010 at 5:20 PM, Jeff Morriss jeff.morriss...@gmail.comwrote:

 Kaul wrote:
  Trying to re-build the ASN1 dissectors (is 'make' within the ASN1 the
  right way to do it?) breaks:

 Looks like it's a known issue:

 http://anonsvn.wireshark.org/viewvc?view=revrevision=34734
 ___
 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] Build broken in asn1/x721 (r34777)?

[Kaul]

On Thu, Nov 4, 2010 at 5:35 PM, Jeff Morriss jeff.morriss...@gmail.comwrote:

 Kaul wrote:
  So how *do* I build Wireshark now? It seems to affect the normal build:

 You shouldn't be building anything in the asn1 directory unless you mean
 to be (generally to rebuild those dissectors).  The top-level Makefile
 doesn't descend into asn1.


Indeed - I was trying (still am) to fix a bug in ldap.



  packet-dcerpc-netlogon.c: In function ‘get_keytab_as_list’:
  packet-dcerpc-netlogon.c:6846:5: error: implicit declaration of function
  ‘read_keytab_file_from_preferences’

 That's got nothing to do with what's in the asn1 directory.


I think it is.
packet-kerberos.h is created automatically by the ASN.1 dissector. Since its
make failed, this failed.
manually building it (../../tools/asn2wrs.py -b -e -p kerberos -c
./kerberos.cnf -s ./packet-kerberos-template -D . KerberosV5Spec2.asn
k5.asn) fixed this.
Y.




 At first glance it sounds like your packet-kerberos.h was compiled
 without HAVE_KERBEROS but packet-dcerpc-netlogon.c is compiled with it.
  Or something like that...
 ___
 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] Build broken in asn1/x721 (r34777)?

[Kaul]

On Thu, Nov 4, 2010 at 5:57 PM, Kaul myk...@gmail.com wrote:



 On Thu, Nov 4, 2010 at 5:35 PM, Jeff Morriss jeff.morriss...@gmail.comwrote:

 Kaul wrote:
  So how *do* I build Wireshark now? It seems to affect the normal build:

 You shouldn't be building anything in the asn1 directory unless you mean
 to be (generally to rebuild those dissectors).  The top-level Makefile
 doesn't descend into asn1.


 Indeed - I was trying (still am) to fix a bug in ldap.



  packet-dcerpc-netlogon.c: In function ‘get_keytab_as_list’:
  packet-dcerpc-netlogon.c:6846:5: error: implicit declaration of function
  ‘read_keytab_file_from_preferences’

 That's got nothing to do with what's in the asn1 directory.


 I think it is.
 packet-kerberos.h is created automatically by the ASN.1 dissector. Since
 its make failed, this failed.
 manually building it (../../tools/asn2wrs.py -b -e -p kerberos -c
 ./kerberos.cnf -s ./packet-kerberos-template -D . KerberosV5Spec2.asn
 k5.asn) fixed this.
 Y.


Spoke too soon. The compile still failed.
I'll tried to compile without Kerberos - that didn't work either - other
errors (I'm pretty sure no one tried ./configure --without-krb5 ; make ).
I wonder if it's due to Fedora 14, to which I upgraded just yesterday.

I've reveted packet-kerberos.[ch] per Anders' advice - that finally fixed
it.
Y.







 At first glance it sounds like your packet-kerberos.h was compiled
 without HAVE_KERBEROS but packet-dcerpc-netlogon.c is compiled with it.
  Or something like that...

 ___
 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] Wireshark or protocol bug? (HTTP MIME multipart)

[Kaul]

On Tue, Oct 26, 2010 at 5:59 PM, Anders Broman a.bro...@telia.com wrote:

  Kaul skrev 2010-10-25 23:55:



 On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter jaap.keu...@xs4all.nlwrote:

 Hi,

 I see no problem here. It loads fine in Wireshark 1.4.1.

 What I do see, and which is a bug in Wireshark, is that it doesn't treat
 it as multipart/mixed, as stated in RFC 2046, Section 5.1.3:

Any multipart subtypes that an implementation does not recognize
must be treated as being of subtype mixed.


 Indeed (and I'll see if I can fix that), but I've actually also
 specifically added multipart/encrypted to packet-multipart (and registered
 gssapi in multipart_media_type table and in media_type table so it'll
 recognize it specifically) - bu I still get the exception (because of the
 missing CR-LF-CR-LF expected?). RFC 1847, section 2.2 seems to show an
 example - with double CRLF.

 Taking a brief look at your trace it seems like double CRLF may be missing
 in some places, compare
 with this trace which I think is correct.
 See also RFC 2046 5.1.1. I think I used RFC 2045 - 2049 helping to
 implement this.


Strange indeed. The capture is from a (successful) remote Powershell
connection between Windows systems, utilizing Kerberos authentication.
MS bug...?
Y.




 TIA,
 Y.

  Thanks,
 Jaap

 On Sun, 24 Oct 2010 12:08:18 +0200, Kaul myk...@gmail.com wrote:

 I'm trying to add dissection of Kerberos encrypted HTTP sessions.
 Mostly, it's OK (got the headers parsed correctly, would file a BZ for
 this patch soon).
 However, when I'm trying to work with the body, which is a MIME multipart,
 it fails with exception.
 The reason seems to be that it does not have the double CRLF which is
 expected between headers and body of a MIME (?):
 imf_find_field_end() seems to fail to find additional CRLF - before the
 binary data (which is actually a Kerberos blob) appears.

 Attached please find a small capture showing the problem - not sure who's
 fault it is - or if it's fixable somehow in Wireshark.
 See packet 8 (dissect as HTTP please).

 Regards,
 Y.




 ___
 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 
 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-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

___
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 or protocol bug? (HTTP MIME multipart)

[Kaul]

On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter jaap.keu...@xs4all.nl wrote:

 Hi,

 I see no problem here. It loads fine in Wireshark 1.4.1.

 What I do see, and which is a bug in Wireshark, is that it doesn't treat it
 as multipart/mixed, as stated in RFC 2046, Section 5.1.3:

Any multipart subtypes that an implementation does not recognize
must be treated as being of subtype mixed.


Indeed (and I'll see if I can fix that), but I've actually also specifically
added multipart/encrypted to packet-multipart (and registered gssapi in
multipart_media_type table and in media_type table so it'll recognize it
specifically) - bu I still get the exception (because of the missing
CR-LF-CR-LF expected?). RFC 1847, section 2.2 seems to show an example -
with double CRLF.

TIA,
Y.

Thanks,
 Jaap

 On Sun, 24 Oct 2010 12:08:18 +0200, Kaul myk...@gmail.com wrote:

 I'm trying to add dissection of Kerberos encrypted HTTP sessions.
 Mostly, it's OK (got the headers parsed correctly, would file a BZ for this
 patch soon).
 However, when I'm trying to work with the body, which is a MIME multipart,
 it fails with exception.
 The reason seems to be that it does not have the double CRLF which is
 expected between headers and body of a MIME (?):
 imf_find_field_end() seems to fail to find additional CRLF - before the
 binary data (which is actually a Kerberos blob) appears.

 Attached please find a small capture showing the problem - not sure who's
 fault it is - or if it's fixable somehow in Wireshark.
 See packet 8 (dissect as HTTP please).

 Regards,
 Y.



 ___
 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

[Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)

[Kaul]

I'm trying to add dissection of Kerberos encrypted HTTP sessions.
Mostly, it's OK (got the headers parsed correctly, would file a BZ for this
patch soon).
However, when I'm trying to work with the body, which is a MIME multipart,
it fails with exception.
The reason seems to be that it does not have the double CRLF which is
expected between headers and body of a MIME (?):
imf_find_field_end() seems to fail to find additional CRLF - before the
binary data (which is actually a Kerberos blob) appears.

Attached please find a small capture showing the problem - not sure who's
fault it is - or if it's fixable somehow in Wireshark.
See packet 8 (dissect as HTTP please).

Regards,
Y.


kerberos_http_mark.pcap
Description: Binary data
___
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] Stripping Dissectors from wireshark.

[Kaul]

On Fri, Oct 22, 2010 at 4:32 PM, Hadriel Kaplan hkap...@acmepacket.comwrote:


 In wireshark, select analyze - enabled protocols... and uncheck
 everything you don't need. (though you will need to keep the lower layers
 dissected - e.g., for HTTP you'd need to keep Ethernet, IP, TCP selected,
 and possibly IPv6, and of course HTTP and possibly SSL, etc)


There are so many protocols, that it's useless to even try.
Would be nice if they were:
(1) grouped by 'families' (example: all the ZigBee protocols)
(2) grouped by layers (example: all the ATM stuff)

Y.



 If all you want is HTTP, and only for port 80 or 443 or whatever, you could
 use a BPF capture filter to only capture the right packets to begin with -
 that'll speed it up.

 -hadriel

 On Oct 21, 2010, at 9:56 PM, rishab gupta wrote:

  Hi,
 I want to speed up wireshark. I am concerned with only the major protocols
 such as http. Will it be a good idea to remove the dissectors that serve
 no purpose for me? If so how do I go about it, because every dissector
 seems to have a lot of dependencies wrapped around it...
 Any help will be much appreciated.

 Best,
 Rishabh Gupta

 ATT1..c



 ___
 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

[Wireshark-dev] packet-daap.c issues (bugs?)

[Kaul]

1. (line 180) tagsize is an int, probably should be an unsigned int (it's a
length of a tag). Not sure what happens if a negative value is fetched, but
doesn't look right.
2. (line 187) it verifies tvb_offset_exists(tvb, offset) - but then fetches
values from 4 and 8 bytes after offset. Probably should be changed to
tvb_offset_exists(tvb, offset + 8) ?
3. (line 194) After fetching tag name as a uint32, it also fetches it as a
string, char by char, by printing (as %c) the result of 4 tvb_get_guint8()
calls. Strange, but legit. I want, however, to change it to use
value_string.
4. The dissector recursively calls dissect_daap_one_tag(), I'm not sure what
will happen if a huge specially malformed segment (it's over a HTTP
response) will be dissected by Wireshark. I suspect we should limit the
recursion level, not only when there's nothing deeper to dissect.
5. (line 169) It seems to perform the dissection only if(tree), which means
it might not dissect it if the tree does not exist. Probably should dissect
it anyway, no?
6. (line 164) It performs col_append_fstr() with 8 bytes fetched from the
tvb - without verifying those 8 bytes are available first. This fetching is
also redundant (happens again in lines 190, 191).

I'd be happy to send patches to {some|all} the above, if people agree with
{some|all} my observations.

Hopefully, it'll help me understand why my iTunes server doesn't work ;-)

Y.
___
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] Usage of MS protocol documentation in Wireshark

[Kaul]

On Tue, Sep 7, 2010 at 11:00 PM, Ed Beroset bero...@mindspring.com wrote:




 -Original Message-
 From: Eloy Paris pe...@chapus.net
 Sent: Sep 7, 2010 3:11 PM
 To: wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] Usage of MS protocol documentation in
 Wireshark
 
 On 09/07/2010 02:20 PM, Stephen Fisher wrote:
 
 [...]
 
 Microsoft folks would probably find it useful to troubleshoot
  their software anyway ;)
 
 Don't know if things have changed recently but a couple of years ago a
 co-worker went to teach a networking class at the Microsoft Redmond
 campus and he was not allowed to use open source tools (including
 Wireshark) during the training. Back then the use of open source tools
 was frowned upon. I understand they are more open with regards to open
 source these days so things may have changed a little ;-)

 There is some evidence that suggests they were never as allergic to open
 source as some of their executives would like you to believe.  If you look
 at files shipped with the Windows operating system, including ftp.exe,
 finger.exe, nslookup.exe and others, you'll see that outwardly they have a
 Microsoft copyright, but in the text inside them, one finds text indicating
 Copyright 198x The Regents of the University of California.

 Ed
 ___
 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



Back to the original discussion - the license for the protocol documentation
is outlined in the link I've previously mentioned -
http://msdn.microsoft.com/en-us/library/cc207842.aspx
As for Network monitor - the parsers are under a BSD license actually -
http://msdn.microsoft.com/en-us/library/cc207842.aspx
Y.
___
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] Usage of MS protocol documentation in Wireshark

[Kaul]

Is it OK to use MS protocols documentation (concrete example -
http://msdn.microsoft.com/en-us/library/cc207842.aspx) to enhance Wireshark?

Seems so from the notice in the page, but wanted to verify in the list
first.

TIA,
Y.
___
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] Kerberos pre-auth type constants - MS extensions are wrong?

[Kaul]

It appears like MS extensions for Kerberos pre-auth type constants, such as:
#define KRB5_PA_PAC_REQUEST -128  /* = 0xFF80 =
(gint32)((gint8)0x80) MS extension */

are wrong - should be 128 (which is 0x80 btw), for example, based on a
capture I've done and on
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf(see
section 3.1.5.1)
Is it OK to fix them in packet-kerberos-template.c? Anyone knows where the
mistake comes from?

TIA,
Y.
___
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] Kerberos pre-auth type constants - MS extensions are wrong?

[Kaul]

On Mon, May 3, 2010 at 4:47 PM, Anders Broman anders.bro...@ericsson.comwrote:

  Hi,
 Note that packet-kerberos-template.c isn't used to generate
 packet-kerberos.c currently, I would guess
 that the info in packet-kerberos-template.c is copied from the current hand
 written dissector.
 Regards
 Anders



Yes, I've just discovered that. And indeed, changing the value in
packet-kerberos.c seems to solve the issue.
Y.



  --
 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul
 *Sent:* den 3 maj 2010 14:04
 *To:* Developer support list for Wireshark
 *Subject:* [Wireshark-dev] Kerberos pre-auth type constants - MS
 extensions are wrong?

 It appears like MS extensions for Kerberos pre-auth type constants, such
 as:
 #define KRB5_PA_PAC_REQUEST -128  /* = 0xFF80 =
 (gint32)((gint8)0x80) MS extension */

 are wrong - should be 128 (which is 0x80 btw), for example, based on a
 capture I've done and on
 http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf(see
  section 3.1.5.1)
 Is it OK to fix them in packet-kerberos-template.c? Anyone knows where the
 mistake comes from?

 TIA,
 Y.


 ___
 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

[Wireshark-dev] clang analysis

[Kaul]

Hi,

I've ran clang static analyser on SVN latest and got the following:
Bug Summary Bug TypeQuantityDisplay? All Bugs2769 Dead store
Dead assignment1692 Dead increment998 Dead initialization25 Dead nested
assignment32 Logic errors
Null dereference21 Use of uninitialized value1

Obviously, there's little chance I can fix all of them. I can try fix a few
from the dissectors I'm familiar with, though.
Some (most of the dead) might/probably are removed by current generation
compiler, so aren't so important to fix, although it'd be nice to.
The rest may be a bit more important to fix.
Example of such bug (from packet-bgp.c, which should REALLY be refactored to
functions!):
2235 ti = proto_tree_add_text(subtree2, tvb, o + i + aoff, tlen, 2236 Cluster
list: %s, cluster_list_emstr-str);

15
Dereference of null pointer (cluster_list_emstr)
___
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] RFC: sorted value_string + bsearch

[Kaul]

2010/4/12 Jakub Zawadzki darkja...@darkjames.ath.cx

 Hi,

 In wireshark there are some large value_string arrays.
 Some developers keep them sorted, some don't :)


Sort how? In some cases, wouldn't it make more sense to put the more
commonly used string near the top and perform a normal search?
I agree it makes sense when there's no knowledge about the distribution of
the strings.
Y.


 Dissectors in which value_string are sorted could be a little faster
 thanks to binary search.

 In attachment patch to introduce new 'fast' functions for value_string.

 Can this patch be commited? I don't know if I will have time to rewrite
 dissectors.
 Some time later it should be also possible to get rid of (hated)
 value_string NULL terminator.


 I'm also attaching sample dns_types rewrite.

 Cheers.

 ___
 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] Must build all?

[Kaul]

This would be useful to have in some documentation (readme.developer?).
Y.

On Sun, Apr 11, 2010 at 8:33 AM, Jaap Keuter jaap.keu...@xs4all.nl wrote:

 Hi,

 You never said on what platform you develop.
 In case of *nix, that depends on where your dissector lives. For a
 plugin it's just 'make'. For a buildin one you can use 'make -C epan
  make wireshark' to speed things up.
 In case of Windows, that depends on where your dissector lives. For a
 plugin it's just 'nmake -f Makefile.nmake'. For a buildin one it's
 'nmake -Makefile.nmake debug-wireshark'.
 But be careful if there are additional dependancies.

 Thanks,
 Jaap

 Send from my iPhone

 On 11 apr 2010, at 04:52, Shawn Mayer mayer...@wvwc.edu wrote:

  After I modify a dissector can I just build that individual file or
  do I
  have to build all? Sorry for the simple question.
 
  Shawn
 
  NTMail K12 - the Mail Server for Education
 
 ___


  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

___
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 I call the pkcs1 dissection from another dissector?

[Kaul]

On Fri, Mar 26, 2010 at 11:49 PM, Anders Broman
anders.bro...@ericsson.comwrote:



  --
 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul
 *Sent:* den 24 mars 2010 07:51

 *To:* Developer support list for Wireshark
 *Subject:* Re: [Wireshark-dev] How do I call the pkcs1 dissection from
 another dissector?

  On Thu, Mar 18, 2010 at 10:39 AM, Anders Broman 
 anders.bro...@ericsson.com wrote:



 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss
 Sent: den 17 mars 2010 18:00
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] How do I call the pkcs1 dissection from
 another dissector?

 Kaul wrote:
 
 
  On Fri, Mar 12, 2010 at 12:21 AM, Jeff Morriss jeff.morriss.ws
  http://jeff.morriss.ws@gmail.com http://gmail.com wrote:
 
  Kaul wrote:
find_dissector(pkcs-1) doesn't seem to be the correct way to
 do it.
How do I do it?
There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How
 do I
call it? I can create a TVB for it, of course.
 
  You'd need that dissector to be registered by name (by calling
  register_dissector()) first.
 
 
  Can you elaborate a bit? Who's 'that' ? my dissector or the PKCS#1?
  And how do I make the PKCS#1 register? It is one of the automatically
  created dissectors...
 
 Sorry, I meant the PKCS#1 dissector (i.e., you'd have to modify the
 dissector).  Looking briefly at that
 dissector, I don't quite know how
 register_dissector() should be called (in fact I'm not even clear what
 the entry point to that dissector is!).

   I think that pkcs is normaly called from other dissectors using
 OID's. If you try to explain more explicity what you are trying to do
 possibly
 with an example trace we may be able to help you.
   Regards
   Anders
  


   I have a blob within my protocol that I is a PKCS#1  (v2.0, EME-OAEP
 format) that I'd be happy to dissect.
   Y.
 Well what sort of ASN1 structures are included there? The pkcs1 dissector
 can dissect

 RSAPublicKey


The above - RSA public key (128bytes, I believe).
TIA,
Y.


  RSAPrivateKey
 :
 etc the reference in the heaser is RFC 2313
 /Anders



 ___
 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



 ___
 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] Status of enhancement patch [BUG 4610]

[Kaul]

Same question, different bug -
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422

TIA,
Y.

On Sat, Mar 27, 2010 at 6:26 PM, Anders Broman
anders.bro...@ericsson.comwrote:

  Committed revision 32306.

  --
 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kristofek, Chuck (IS)
 *Sent:* den 26 mars 2010 23:17
 *To:* wireshark-dev@wireshark.org
 *Subject:* [Wireshark-dev] Status of enhancement patch [BUG 4610]

  Hi,



 I waited the recommended few days before asking…

 I submitted an enhancement patch [bug4610], but got no

 response. Could someone please take a look at it?



 Best regards



 *Chuck Kristofek*

 *CAF DMO OI*

 *Systems Engineer*

 *Northrop Grumman - Information Systems*
 2721 Discovery Drive - Suite 100
 Orlando, FL 32826
 321-235-3961
 321-235-3880 FAX

 *This document/email may contain technical data, the use of which is
 restricted by the U.S. Arms Export Control Act. This data is subject to the
 International Traffic In Arms Regulations (ITAR). By accepting this data the
 consignee agrees to honor the requirements of the ITAR.*



 ___
 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] How do I call the pkcs1 dissection from another dissector?

[Kaul]

On Thu, Mar 18, 2010 at 10:39 AM, Anders Broman
anders.bro...@ericsson.comwrote:



 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss
 Sent: den 17 mars 2010 18:00
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] How do I call the pkcs1 dissection from
 another dissector?

 Kaul wrote:
 
 
  On Fri, Mar 12, 2010 at 12:21 AM, Jeff Morriss jeff.morriss.ws
  http://jeff.morriss.ws@gmail.com http://gmail.com wrote:
 
  Kaul wrote:
find_dissector(pkcs-1) doesn't seem to be the correct way to do
 it.
How do I do it?
There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How
 do I
call it? I can create a TVB for it, of course.
 
  You'd need that dissector to be registered by name (by calling
  register_dissector()) first.
 
 
  Can you elaborate a bit? Who's 'that' ? my dissector or the PKCS#1?
  And how do I make the PKCS#1 register? It is one of the automatically
  created dissectors...
 
 Sorry, I meant the PKCS#1 dissector (i.e., you'd have to modify the
 dissector).  Looking briefly at that
 dissector, I don't quite know how
 register_dissector() should be called (in fact I'm not even clear what the
 entry point to that dissector is!).

 I think that pkcs is normaly called from other dissectors using OID's. If
 you try to explain more explicity what you are trying to do possibly with an
 example trace we may be able to help you.
 Regards
 Anders


I have a blob within my protocol that I is a PKCS#1  (v2.0, EME-OAEP format)
that I'd be happy to dissect.
Y.

 ___
 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

___
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 I call the pkcs1 dissection from another dissector?

[Kaul]

On Fri, Mar 12, 2010 at 12:21 AM, Jeff Morriss jeff.morriss...@gmail.comwrote:

 Kaul wrote:
  find_dissector(pkcs-1) doesn't seem to be the correct way to do it.
  How do I do it?
  There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How do I
  call it? I can create a TVB for it, of course.

 You'd need that dissector to be registered by name (by calling
 register_dissector()) first.


Can you elaborate a bit? Who's 'that' ? my dissector or the PKCS#1? And how
do I make the PKCS#1 register? It is one of the automatically created
dissectors...
Y.


 ___
 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

[Wireshark-dev] r32134 - ...I hope strtok_s is portable - no, it isn't

[Kaul]

Broke my Linux (Fedora 12, x64) build.
Y.
___
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] [PATCH][RFC] show number of segments which were used in the desgementation

[Kaul]

On Tue, Mar 2, 2010 at 5:18 PM, Jaap Keuter jaap.keu...@xs4all.nl wrote:

 Hi,

 Better file an enhancement bug, so it won't get lost.

 Thanks,
 Jaap


Sure. The idea was to get some feedback first, but OK:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4550
Y.



 On Tue, 2 Mar 2010 09:32:24 +0200, Kaul myk...@gmail.com wrote:
  Attached non-elegant patch shows, in addition to the already shown total
  number of bytes, the number of segments that were used to desegment a
  message.
  It may not be very efficient (and I'm open to suggestions on how to
  enhance it) but it works.
 
  diff against SVN r32082.
 
  TIA,
  Y.
 ___
 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

[Wireshark-dev] How do I call the pkcs1 dissection from another dissector?

[Kaul]

find_dissector(pkcs-1) doesn't seem to be the correct way to do it. How do
I do it?
There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How do I call
it? I can create a TVB for it, of course.

TIA,
Y.
___
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] [PATCH][RFC] show number of segments which were used in the desgementation

[Kaul]

Attached non-elegant patch shows, in addition to the already shown total
number of bytes, the number of segments that were used to desegment a
message.
It may not be very efficient (and I'm open to suggestions on how to enhance
it) but it works.

diff against SVN r32082.

TIA,
Y.


reassemble.c.diff
Description: Binary data
___
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] enum or #define?

[Kaul]

Which one is better?
option 1:
#define SSL_HND_HELLO_REQUEST  0
#define SSL_HND_CLIENT_HELLO   1
...

or perhaps, option 2:
enum {
SSL_HND_HELLO_REQUEST,
SSL_HND_CLIENT_HELLO,
 };
...

and then (in both cases):

const value_string ssl_31_handshake_type[] = {
{ SSL_HND_HELLO_REQUEST, Hello Request },
{ SSL_HND_CLIENT_HELLO,  Client Hello },


?

TIA,
Y.
___
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] constify some functions in proto.c / tvbuff.c

[Kaul]

All BZ'ed under
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422 [Enhancement:
constify parameters in proto.c, packet.c, conversation.c, tvbuff.c,
addr_resolv.c].
Please let me know if it's accepted, it required one-liner changes to two
dissectors (also attached to the BZ).

Thanks in advance,
Y.


On Mon, Jan 25, 2010 at 11:23 PM, Kaul myk...@gmail.com wrote:

 On Mon, Jan 25, 2010 at 10:41 PM, Jaap Keuter jaap.keu...@xs4all.nlwrote:

 Hi,

 Note that this patch pushes more than just consts, but also changes in the
 VNC
 dissector and packet-redc as a PIDL dissector.


 Ouch. Please disregard them - they will be properly submitted - separately
 of course .
 I just  wanted to get feedback if the 'constifying' will be accpetable -
 I'll submit it as a patch-per-file appropriately, when it's ready, and via
 bugzilla.
 Thanks,
 Y.


 Thanks,
 Jaap


 Kaul wrote:
  Re-attaching diff - now without conflicts.
 
  On Mon, Jan 25, 2010 at 5:50 PM, Kaul myk...@gmail.com
  mailto:myk...@gmail.com wrote:
 
  Not sure how much it really matters with today's compilers, but it
  certainly a good habit of consifying params when possible.
  Attached patch, please review.
  (I'll open a bugzilla if this approach seems reasonable).
 
 


 ___
 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] Failing to get my tree to show - problem solved, but I don't understand why

[Kaul]

Well, I solved the problem - but I still don't get why it's working. I've
copied what packet-vnc.c does:
After getting the conversation object, get the per-packet info. If none
exist, I create one and copy the protocol conversation state machine to it.
Then, I act upon the state *from the packet info*. Everything works
beautifully afterwards (attached changed code - mainly the addition in lines
290-297 - which fetch the per packet information and use it.)

I'd still be happy to understand why this works now (also as a lesson for
others).
Y.


On Wed, Jan 20, 2010 at 11:15 PM, Kaul myk...@gmail.com wrote:



 On Tue, Jan 19, 2010 at 1:09 AM, Guy Harris g...@alum.mit.edu wrote:


 On Jan 16, 2010, at 10:39 AM, Kaul wrote:

  From README.developer:
  Wireshark distinguishes between the 2 modes with the proto_tree
 pointer

 I'll look at rewriting that to clarify that they're not modes of operation
 of Wireshark, and that one must not make assumptions about when you'll be
 called with, or without, a protocol tree (other than if Wireshark needs the
 entire tree, for whatever reason that might be, it'll pass a non-null
 pointer; otherwise, it might be null or it might be non-null, don't depend
 on either one).

  Would posting the complete code help?

 Probably.


 Thank you - attached.
 The main dissectors starts at dissect_spice(), and relevant code in line
 283 and on.

 Thanks in advance,
 Yaniv.



 ___
 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



/* packet-spice.c
 * Routines for Spice protocol dissection
 * Copyright 2010, Yaniv Kaul yk...@spicehat.com
 *
 * Wireshark - Network traffic analyzer
 * By Gerald Combs ger...@wireshark.org
 * Copyright 1998 Gerald Combs
 *
 * This program is free software; you can spiceistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *
 * This code is based on the protocol specification:
 *   http://www.spice-space.org/docs/spice_protocol.pdf
 */

#ifdef HAVE_CONFIG_H
# include config.h
#endif

#include stdio.h
#include stdlib.h
#include string.h
#include glib.h

#include epan/conversation.h
#include epan/dissectors/packet-tcp.h
#include epan/emem.h
#include epan/packet.h
#include epan/prefs.h

#define DBG2(format, arg1, arg2)fprintf(stderr, format, arg1, 
arg2)

#define SPICE_MAGIC 0x52454451 /* = REDQ */
#define SPICE_VERSION_MAJOR_1 1
#define SPICE_VERSION_MINOR_0 0

#define SPICE_TICKET_PUBKEY_BYTES 162

#define CHANNEL_NONE 0
#define CHANNEL_MAIN 1
#define CHANNEL_DISPLAY 2
#define CHANNEL_INPUTS 3 
#define CHANNEL_CURSOR 4
#define CHANNEL_PLAYBACK 5
#define CHANNEL_RECORD 6

typedef enum {
LINK_CLIENT,
LINK_SERVER,

TICKET_CLIENT,
TICKET_SERVER,

DATA
} spice_session_state_e;

#define TCP_PORT_SPICE  5910

static dissector_handle_t spice_handle;

static const value_string channel_types_vs[] = {
{ CHANNEL_NONE, Invalid   },
{ CHANNEL_MAIN, Main  },
{ CHANNEL_DISPLAY, Display   },
{ CHANNEL_INPUTS, Inputs},
{ CHANNEL_CURSOR, Cursor},
{ CHANNEL_PLAYBACK, Playback  },
{ CHANNEL_RECORD, Record},
{ 0,  NULL   }
};

static const value_string error_codes_vs[] = {
{ 0, SPICE_ERROR_OK },
{ 1, SPICE_ERROR_ERROR  },
{ 2, SPICE_ERROR_INVALID_MAGIC  },
{ 3, SPICE_ERROR_INVALID_DATA   },
{ 4, SPICE_ERROR_VERSION_MISMATCH   },
{ 5, SPICE_ERROR_NEED_SECUSPICE   },
{ 6, SPICE_ERROR_NEED_UNSECUSPICE },
{ 7, SPICE_ERROR_PERMISSION_DENIED  },
{ 8, SPICE_ERROR_BAD_CONNECTION_ID  },
{ 9, SPICE_ERROR_CHANNEL_NOT_AVAILABLE  },
{ 0,  NULL   }
};

/* This structure will be tied to each conversation. */
typedef struct {
guint32 connection_id;
guint32 num_channel_caps;
guint32 destport;
spice_session_state_e next_state;
guint8 channel_type;
guint8 channel_id;
} spice_conversation_t;

typedef struct

Re: [Wireshark-dev] Failing to get my tree to show

[Kaul]

On Tue, Jan 19, 2010 at 1:09 AM, Guy Harris g...@alum.mit.edu wrote:


 On Jan 16, 2010, at 10:39 AM, Kaul wrote:

  From README.developer:
  Wireshark distinguishes between the 2 modes with the proto_tree pointer

 I'll look at rewriting that to clarify that they're not modes of operation
 of Wireshark, and that one must not make assumptions about when you'll be
 called with, or without, a protocol tree (other than if Wireshark needs the
 entire tree, for whatever reason that might be, it'll pass a non-null
 pointer; otherwise, it might be null or it might be non-null, don't depend
 on either one).

  Would posting the complete code help?

 Probably.


Thank you - attached.
The main dissectors starts at dissect_spice(), and relevant code in line 283
and on.

Thanks in advance,
Yaniv.


 ___
 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

/* packet-spice.c
 * Routines for Spice protocol dissection
 * Copyright 2010, Yaniv Kaul yk...@spicehat.com
 *
 * Wireshark - Network traffic analyzer
 * By Gerald Combs ger...@wireshark.org
 * Copyright 1998 Gerald Combs
 *
 * This program is free software; you can spiceistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *
 * This code is based on the protocol specification:
 *   http://www.spice-space.org/docs/spice_protocol.pdf
 */

#ifdef HAVE_CONFIG_H
# include config.h
#endif

#include stdio.h
#include stdlib.h
#include string.h
#include glib.h

#include epan/conversation.h
#include epan/dissectors/packet-tcp.h
#include epan/emem.h
#include epan/packet.h
#include epan/prefs.h

#define DBG2(format, arg1, arg2)fprintf(stderr, format, arg1, 
arg2)

#define SPICE_MAGIC 0x52454451 /* = REDQ */
#define SPICE_VERSION_MAJOR_1 1
#define SPICE_VERSION_MINOR_0 0

#define SPICE_TICKET_PUBKEY_BYTES 162

#define SPICE_CHANNEL_NONE 0
#define SPICE_CHANNEL_MAIN 1
#define SPICE_CHANNEL_DISPLAY 2
#define SPICE_CHANNEL_INPUTS 3 
#define SPICE_CHANNEL_CURSOR 4
#define SPICE_CHANNEL_PLAYBACK 5
#define SPICE_CHANNEL_RECORD 6

#define SPICE_STATE_LINK_CLIENT 0
#define SPICE_STATE_LINK_SERVER 1
#define SPICE_STATE_TICKET_CLIENT 2
#define SPICE_STATE_TICKET_SERVER 3
#define SPICE_STATE_DATA 4

#define TCP_PORT_SPICE  5910

static dissector_handle_t spice_handle;

static const value_string channel_types_vs[] = {
{ 0, Invalid   },
{ 1, Main  },
{ 2, Display   },
{ 3, Inputs},
{ 4, Cursor},
{ 5, Playback  },
{ 6, Record},
{ 0,  NULL   }
};

static const value_string error_codes_vs[] = {
{ 0, SPICE_ERROR_OK },
{ 1, SPICE_ERROR_ERROR  },
{ 2, SPICE_ERROR_INVALID_MAGIC  },
{ 3, SPICE_ERROR_INVALID_DATA   },
{ 4, SPICE_ERROR_VERSION_MISMATCH   },
{ 5, SPICE_ERROR_NEED_SECUSPICE   },
{ 6, SPICE_ERROR_NEED_UNSECUSPICE },
{ 7, SPICE_ERROR_PERMISSION_DENIED  },
{ 8, SPICE_ERROR_BAD_CONNECTION_ID  },
{ 9, SPICE_ERROR_CHANNEL_NOT_AVAILABLE  },
{ 0,  NULL   }
};

/* This structure will be tied to each conversation. */
typedef struct {
guint32 connection_id;
guint32 num_channel_caps;
guint32 destport;
guint8 channel_type;
guint8 channel_id;
guint8 next_state;
} spice_conversation_t;


/* desegmentation of spice protocol */
static gboolean spice_desegment = TRUE;

/* Variables for our preferences */
static guint spice_preference_alternate_port = 0;

static gint ett_spice = -1;
static gint ett_link_client = -1;
static gint ett_link_server = -1;

static int proto_spice = -1;
static int hf_spice_magic  = -1;
static int hf_major_version  = -1;
static int hf_minor_version  = -1;
static int hf_message_size  = -1;
static int hf_conn_id  = -1;
static int hf_channel_type  = -1;
static int hf_channel_id  = -1;
static int hf_num_common_caps  = -1;
static int hf_num_channel_caps  = -1;
static int hf_caps_offset  = -1;
static int hf_error_code  = -1;
static int hf_serial = -1;
static int hf_link_client = -1

Re: [Wireshark-dev] Failing to get my tree to show

[Kaul]

On Sat, Jan 16, 2010 at 4:30 AM, Guy Harris g...@alum.mit.edu wrote:


 On Jan 15, 2010, at 1:50 PM, Kaul wrote:

  Hi,
 
  I'm trying to write a new dissector, and failing miserably getting my
 tree to show, because the tree I'm getting in my dissect_PROTONAME() is
 always NULL, not sure why.

 Null even if you click on the packet?


Nope.



  I'm dissecting over TCP, with (regretfully) my own desegmentation:

 By my own desegmentation I assume you mean my own code to get the TCP
 dissector to reassemble stuff, rather than using tcp_dissect_pdus() or
 req_resp_hdrs_do_reassembly(), given that you refer to setting
 pinfo-desegment_len.


Indeed. I cannot use either of the above mentioned methods.



  packets 1-3 are syn, syn-ack, ack.
  packet 4 is a start of a PDU, which is not enough to dissect the PDU,
 although I'm a getting its header. From the header, I'm taking the complete
 PDU length and therefore setting pinfo-desegment_len to calculated PDU
 length - length of what I got already ( with the offset = 0).
  This looks nice and correct and indeed seems to be desegmented correctly,
 BUT:
  packet 4 has my COL_PROTOCOL set (why?, I didn't dissect it eventually)

 You're setting COL_PROTOCOL before you're doing

  if (len  pdu_len  redc_desegment) { /* Did not get all
 the PDU - request the full length of the PDU */
  pinfo-desegment_offset = 0;
  pinfo-desegment_len = pdu_len - len;
  return len;
   }

 so you did enough dissection to set the column.


Even if I'm not setting right away (others do it as well - I've taken it
from packet-vnc.c), then it's even worse - all I see is the TCP.



 The BGP dissector works the same way; one could argue that it shouldn't.

  packet 5 doesn't (correct, I've asked for more than it has - it just a
 TCP segment)
  packet 6 has my COL_PROTOCOL set (good) - but the packet isn't dissected
 there, although now I have the complete data (and TCP desgmentation shows
 the data is indeed taken from packets 4, 5 ,6 correctly.

 OK, presumably you know it has COL_PROTOCOL set because row 6 of the packet
 list has Spice in the Protocol column; do you know that it's not dissected
 because, when you click on that row, you don't see a protocol tree for your
 protocol?


Exactly. It's not that it's not dissected - all the right functions are
called. But with tree = null, not much is seen.
I can see that TCP correctly shows the 3 segments in packet 6 (that it
reassembled from packets 4,5,6).




  I do know wireshark has two modes, one of which it goes over packets
 without the tree set, but I don't get when and where.

 I wouldn't describe them as modes; it's more like Wireshark generates a
 protocol tree if it knows it will need one, and in some cases, perhaps,
 where it doesn't, but doesn't really know that it doesn't.  There are no
 modes such that a guarantee is made that, in certain cases, you will be
 handed a tree and, in other cases, you won't, only that if the tree is going
 to be displayed or printed you will be handed a tree (if not, that's
 obviously a bug).


From README.developer:
Wireshark distinguishes between the 2 modes with the proto_tree pointer



 There's also a bit of a hack that attempts to prevent the entire protocol
 tree from being generated when it's *not* going to be displayed or printed
 and where some fields *aren't* needed, and some dissectors that, for
 example, use proto_item_append_string() have to work around - see change
 r31460, for example.


Again, I think my main issue is that my main dissector function is already
called with a null tree. That makes everything afterwards pretty much fail
to display.
I did notice it doesn't happen without the desegmentation stuff - so I'm
pretty sure it's related to that. Just have no idea why.
Would posting the complete code help?
TIA,
Y.

___
 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

[Wireshark-dev] How to parse a protocol with two different PDU types in a single connection?

[Kaul]

Hello,

I have a protocol that begins with a PDU of type A ('link' state), then
switches after it performed some negotiation to a PDU type B ('data' state).
I've tried something similar to:
conversation = find_conversation(pinfo-fd-num, pinfo-src, pinfo-dst,
pinfo-ptype, pinfo-srcport, pinfo-destport, 0);
if (!conversation) {
conversation = conversation_new(pinfo-fd-num, pinfo-src,
pinfo-dst, pinfo-ptype, pinfo-srcport, pinfo-destport, 0);
}

myproto_info =
(myproto_conversation_t*)conversation_get_proto_data(conversation,
proto_myproto);
if(!myproto_info) {
/* We don't yet have a conversation, so create one. */
myproto_info = se_alloc0(sizeof(myproto_conversation_t));
myproto_info-destport = pinfo-destport; /* Useful to differ
between c2s and s2c packets */
myproto_info-pdu_type_A = TRUE;
conversation_add_proto_data(conversation, proto_myproto,
myproto_info);
}

if (myproto_info-pdu_type_A == TRUE) {
/* If we are still in the link state part of the protocol */
tcp_dissect_pdus(tvb, pinfo, tree, myproto_desegment, 16,
get_myproto_link_pdu_len, dissect_myproto_link_pdu);
} else {
tcp_dissect_pdus(tvb, pinfo, tree, myproto_desegment, 16,
get_myproto_data_pdu_len, dissect_myproto_data_pdu);
}

And in dissect_myproto_link_pdu():
if (myproto_info-destport == pinfo-destport) {
/* dissectC2S messages */
} else {
  /* S2C messages - and turn off pdu_type_A ! */
 myproto_info-pdu_type_A = FALSE;
}

This doesn't work well. Once I turn it off, nothing is dissected any more -
as if it won't reach the first tcp_dissect_pdus() line anymore - even for
other conversations.

1. Is my approach correct?
2. Any hint as to what I'm doing wrong here?

TIA,
Yaniv.
___
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] Next releases

[Kaul]

On Fri, May 15, 2009 at 9:27 PM, Gerald Combs ger...@wireshark.org wrote:

 Next week I plan on releasing 1.2.0rc1 and 1.0.8. The 1.2.0rc1 release
 will include creating a /trunk-1.2 branch in SVN. If you need me to
 postpone the branch or release, please let me know.

 I've started working on the release notes (docbook/release-notes.xml).
 If I missed any new/updated features, let me know.
 ___
 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


I'd be happy if
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3215[Heuristic
dissection of VNC traffic (on non-standard ports)] could make it
into the 1.2 release.
I understand it's more of a feature than a bug fix, so it shouldn't be
included in 1.0 branch, but I see no reason not to include it in 1.2.

Anything I should do to make it happen?

TIA,
Y.
___
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] Splitting packet_info struct for performance reasons?

[Kaul]

I was astounded with the huge size of packet_info structure. I believe in
99% of the cases, there is no need for many of the fields within the
structure. Wouldn't it make sense, for performance reasons, to leave the
most usable ones within it, and create a pointer to an extra structure with
the other, less commonly used stuff. I'm pretty sure it'll save memory and
probably improve performance, but would require some changes and complicate
a bit the programming. Thoughts?

Semi-random examples:
guint16 src_idx;  /* Source port index (Cisco MDS-specific) */
  guint16 dst_idx;  /* Dest port index (Cisco MDS-specific) */
  guint16 vsan; /* Fibre channel/Cisco MDS-specific */

(how many of us need the above?)

  guint16 link_number;
  guint8  annex_a_used;
  guint16 profinet_type; /* the type of PROFINET packet (0: not a
PROFINET packet) */

(It it even 16bit aligned?!)

/* Extra data for DCERPC handling and tracking of context ids */
  guint16 dcectxid; /* Context ID (DCERPC-specific) */
  int dcetransporttype; /* Transport type
 * Value -1 means not a DCERPC packet
 */
  guint16 dcetransportsalt;/* fid: if
transporttype==DCE_CN_TRANSPORT_SMBPIPE */

(can't it reside in its own struct?, again, is it aligned on some
boundaries?)
___
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] Compilation fails on Kerberos issues

[Kaul]

SVN, on XP SP3, using VC 2008EE. Commented-out:
PCRE_DIR, GNUTLS_DIR, KFW_DIR, NETTLE_DIR, LUA_DIR
and it fails to compile:
   Creating library libwireshark.lib and object libwireshark.exp
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_kt_cl...@8 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_kt_end_seq_...@12 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_kt_next_en...@16 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_kt_start_seq_...@12 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_kt_reso...@12 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_init_cont...@4 referenced in function _read_keytab_file
dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external
symbol
_krb5_c_decr...@24 referenced in function _decrypt_krb5_data
libwireshark.dll : fatal error LNK1120: 7 unresolved externals
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\link.EXE' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\nmake.exe' : return code '0x2'
Stop.


I'm not entirely sure it's related, but it's troubling nevertheless.
___
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] SOLVED: Re: Issue with 1.1.2 and latest SVN (27315) - on Win32 - Wireshark is not displayed

[Kaul]

The issue was that in the recently used files there were some files on the
network path - that was unavailable anymore. After 10 minutes Wireshark
loaded, I've cleared the list and now it loads fine.
Not sure if we should do something about it or not.

On Wed, Jan 28, 2009 at 9:58 AM, Kaul myk...@gmail.com wrote:

 For some reason, when I'm launching Wireshark (both 1.1.2 and SVN 27315, on
 XP, SP3), after it is done with all the dissector loading stuff, the UI
 disappears - and does not appear. The process is still alive, with one
 thread, not doing much. Process Explorer of it:
 ... some low level Windows stuff
 kernel32.dll!FindFirstFileW+0x16
 MSVCR90.dll!wstat64i32+0xb6
 libwsutil.dll!ws_stdio_stat+0xbc
 wireshark.exe+0x4309a
 wireshark.exe+0x42e13
 wireshark.exe+0x3696f
 libgtk-win32-2.0-0.dll!gtk_menu_shell_select_item+0x426
 libgtk-win32-2.0-0.dll!gtk_container_foreach+0xad
 wireshark.exe+0x36911
 wireshark.exe+0x36ece
 wireshark.exe+0x36c1f
 wireshark.exe+0x2f391
 libwireshark.dll!read_prefs_file+0xe4
 ...

 Any ideas? If there's a PDB for the SVN build, I can perhaps get a better
 stack.


___
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] Issue with 1.1.2 and latest SVN (27315) - on Win32 - Wireshark is not displayed

[Kaul]

For some reason, when I'm launching Wireshark (both 1.1.2 and SVN 27315, on
XP, SP3), after it is done with all the dissector loading stuff, the UI
disappears - and does not appear. The process is still alive, with one
thread, not doing much. Process Explorer of it:
... some low level Windows stuff
kernel32.dll!FindFirstFileW+0x16
MSVCR90.dll!wstat64i32+0xb6
libwsutil.dll!ws_stdio_stat+0xbc
wireshark.exe+0x4309a
wireshark.exe+0x42e13
wireshark.exe+0x3696f
libgtk-win32-2.0-0.dll!gtk_menu_shell_select_item+0x426
libgtk-win32-2.0-0.dll!gtk_container_foreach+0xad
wireshark.exe+0x36911
wireshark.exe+0x36ece
wireshark.exe+0x36c1f
wireshark.exe+0x2f391
libwireshark.dll!read_prefs_file+0xe4
...

Any ideas? If there's a PDB for the SVN build, I can perhaps get a better
stack.
___
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] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

[Kaul]

Anyone had a chance to look at this patch?

On Sun, Jan 4, 2009 at 12:29 AM, Kaul myk...@gmail.com wrote:

 Attached please find a patch that enables to heuristically find VNC traffic
 on non-standard ports.

 (it also adds some if(tree) ... around some proto_tree_add_item()
 functions)

 Y.


 On Sun, Dec 28, 2008 at 11:50 PM, Stephen Fisher stephentfis...@yahoo.com
  wrote:

 On Sun, Dec 28, 2008 at 11:34:55PM +0200, Kaul wrote:

  BTW, there's no minimum length verification for messages. I'd assume
  that if we try to dissect traffic as VNC we should probably verify
  minimal lengths - both SERVER_VERSION and CLIENT_VERSION packets
  should be EXACTLY 12 bytes long and start with ASCII chars 'RFB '(3
  letters and space - hex 52 46 42 20). Moreover, this could also be
  used to heuristically find VNC traffic on non-standard ports.

 That's a good idea.  I've thought for a while about adding length
 verficiation to all of the fixed length packets in fact to help the
 dissector pick up close to the right place in the VNC session if it's
 already going on when the dissection starts.

  If agreed, I'll try to follow this with a patch, at least for some of
  the comments above.

 Go ahead and whip up a patch and we'll try it out :).  Thanks for your
 interest in improving the VNC dissector!


 Steve

 ___
 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] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

[Kaul]

Attached please find a patch that enables to heuristically find VNC traffic
on non-standard ports.

(it also adds some if(tree) ... around some proto_tree_add_item() functions)

Y.

On Sun, Dec 28, 2008 at 11:50 PM, Stephen Fisher
stephentfis...@yahoo.comwrote:

 On Sun, Dec 28, 2008 at 11:34:55PM +0200, Kaul wrote:

  BTW, there's no minimum length verification for messages. I'd assume
  that if we try to dissect traffic as VNC we should probably verify
  minimal lengths - both SERVER_VERSION and CLIENT_VERSION packets
  should be EXACTLY 12 bytes long and start with ASCII chars 'RFB '(3
  letters and space - hex 52 46 42 20). Moreover, this could also be
  used to heuristically find VNC traffic on non-standard ports.

 That's a good idea.  I've thought for a while about adding length
 verficiation to all of the fixed length packets in fact to help the
 dissector pick up close to the right place in the VNC session if it's
 already going on when the dissection starts.

  If agreed, I'll try to follow this with a patch, at least for some of
  the comments above.

 Go ahead and whip up a patch and we'll try it out :).  Thanks for your
 interest in improving the VNC dissector!


 Steve
 ___
 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



packet-vnc.c.diff
Description: Binary data
___
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] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

[Kaul]

It seems to be used to check according to very specific destination ports,
if we should dissect the messages as client to server or server to client
messages. I'm not sure why not just compare the current destination port
with the one we've saved in the conversation.
This will avoid erroneous dissection of VNC traffic on non-standard port
(that was not explicitly defined in the preferences.

BTW, there's no minimum length verification for messages. I'd assume that if
we try to dissect traffic as VNC we should probably verify minimal lengths -
both SERVER_VERSION and CLIENT_VERSION packets should be EXACTLY 12 bytes
long and start with ASCII chars 'RFB '(3 letters and space - hex 52 46 42
20).
Moreover, this could also be used to heuristically find VNC traffic on
non-standard ports.

If agreed, I'll try to follow this with a patch, at least for some of the
comments above.

Regards,
Y.
___
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] Failure to dissect long SASL wrapped LDAP response

[Kaul]

Please find attached patch against SVN 25526 to fix the problem. My 64K
capture is working fine with it. The fix:
1. Defines LDAP_SASL_MAX_BUF to 4*64*1024 - in packet-ldap.h
2. Uses it - in packet-ldap.c instead of the hard-coded 65535 value below.
3. Documents this in the comments.

It's obviously incomplete, in the sense that SASL buffers probably may be
bigger than my above 4*64K, but it fixes my issue and leaves room for fixing
it in a general manner.

Comments are welcome,
Y.

On Thu, Jun 12, 2008 at 11:53 PM, Kaul [EMAIL PROTECTED] wrote:

 Oh, that may explain it (from packet-ldap.c) marked with
 bold/italic/underline:

 */* check for a SASL header, i.e. assume it is SASL if
* 1, first four bytes (SASL length) is an integer

*with a value that must be 64k and 2
*(2 to fight false positives, 0x is a common
*random tcp payload)
* (no SASL ldap PDUs are ever going to be 64k in size?)

*
* 2, we must have a conversation and the auth type must
*be LDAP_AUTH_SASL
*/*
   sasl_len=tvb_get_ntohl(tvb, 0);

   *if*( sasl_len2 ){
   *goto* *this_was_not_sasl*;

   }

   *if*( sasl_len*65535* ){
   *goto* *this_was_not_sasl*;
   }


 Apparently, the above assumption is wrong.

 Y.




 On Thu, Jun 12, 2008 at 11:40 PM, Kaul [EMAIL PROTECTED] wrote:

 Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
 dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP
 response. Regretfully, I cannot share the capture, but the first packet that
 is not desgemented or dissected in any way (just shows as TCP payload) is
 (partial):
    00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00  ..J.E[...XE.
 0010   05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12  [EMAIL PROTECTED]
 0020   dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10  .[...oE..4...P.
 0030   fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06  .k..l.`..l..
 0040   09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff  .*.H
 0050   ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9  ...5/.U.
 0060   31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c  1i.+..0...l|
 0070   02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67  [EMAIL PROTECTED]
 0080   67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d  gregate,CN=Schem
 ...
 Notice from offeset 0x36 (after the TCP header) - the size of the SASL
 buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then
 0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes less than
 the SASL buffer, followed by the Kerberos 5 OID, and so on.
 Please note that previos LDAP request and responses were nicely dissected.
 It's just this long response that doesn't play nice. The unbind request at
 the end of all this also looks nice.

 I'd be happy to work with someone on testing a fix for it. I could test a
 Windows binary or a source patch in Linux.

 Thanks in advance,
 Yaniv.





packet-ldap.h.diff
Description: Binary data


packet-ldap.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

[Kaul]

Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP
response. Regretfully, I cannot share the capture, but the first packet that
is not desgemented or dissected in any way (just shows as TCP payload) is
(partial):
   00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00  ..J.E[...XE.
0010   05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12  [EMAIL PROTECTED]
0020   dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10  .[...oE..4...P.
0030   fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06  .k..l.`..l..
0040   09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff  .*.H
0050   ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9  ...5/.U.
0060   31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c  1i.+..0...l|
0070   02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67  [EMAIL PROTECTED]
0080   67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d  gregate,CN=Schem
...
Notice from offeset 0x36 (after the TCP header) - the size of the SASL
buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then
0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes less than
the SASL buffer, followed by the Kerberos 5 OID, and so on.
Please note that previos LDAP request and responses were nicely dissected.
It's just this long response that doesn't play nice. The unbind request at
the end of all this also looks nice.

I'd be happy to work with someone on testing a fix for it. I could test a
Windows binary or a source patch in Linux.

Thanks in advance,
Yaniv.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

[Kaul]

Oh, that may explain it (from packet-ldap.c) marked with
bold/italic/underline:

*/* check for a SASL header, i.e. assume it is SASL if
 * 1, first four bytes (SASL length) is an integer
 *with a value that must be 64k and 2
 *(2 to fight false positives, 0x is a common
 *random tcp payload)
 * (no SASL ldap PDUs are ever going to be 64k in size?)
 *
 * 2, we must have a conversation and the auth type must
 *be LDAP_AUTH_SASL
 */*
sasl_len=tvb_get_ntohl(tvb, 0);

*if*( sasl_len2 ){
*goto* *this_was_not_sasl*;
}

*if*( sasl_len*65535* ){
*goto* *this_was_not_sasl*;
}


Apparently, the above assumption is wrong.

Y.



On Thu, Jun 12, 2008 at 11:40 PM, Kaul [EMAIL PROTECTED] wrote:

 Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
 dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP
 response. Regretfully, I cannot share the capture, but the first packet that
 is not desgemented or dissected in any way (just shows as TCP payload) is
 (partial):
    00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00  ..J.E[...XE.
 0010   05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12  [EMAIL PROTECTED]
 0020   dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10  .[...oE..4...P.
 0030   fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06  .k..l.`..l..
 0040   09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff  .*.H
 0050   ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9  ...5/.U.
 0060   31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c  1i.+..0...l|
 0070   02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67  [EMAIL PROTECTED]
 0080   67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d  gregate,CN=Schem
 ...
 Notice from offeset 0x36 (after the TCP header) - the size of the SASL
 buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then
 0x83, (3 bytes of length which is now 0x36cc4 - correctly 5 bytes less than
 the SASL buffer, followed by the Kerberos 5 OID, and so on.
 Please note that previos LDAP request and responses were nicely dissected.
 It's just this long response that doesn't play nice. The unbind request at
 the end of all this also looks nice.

 I'd be happy to work with someone on testing a fix for it. I could test a
 Windows binary or a source patch in Linux.

 Thanks in advance,
 Yaniv.

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] LDAP GUID display bug?

[Kaul]

Well, this is exactly the bug - that it disregards the endianness of it.

On Feb 12, 2008 6:08 PM, Lars Friedrichs [EMAIL PROTECTED] wrote:

  Hi Kaul,

 that is simply network byte order vs. host byte order. on the network all
 numbers are transfered big endian style so the most significant byte is
 always the last byte. If you look closer you will notice it's just turned
 around.

 Bye
 Lars

 Kaul schrieb:

 Running 0.99.7, on Windows, capturing Active Directory LDAP communication,
 there's some wrong display of GUIDs (object type objectGUID). For example,
 what on the wire looks like (hex) 25 ff 7e 7d 1a f2 a2 49... should be
 7d7eff25-f21a-49a2-... (I think the rest is like the wire). However, I see
 that on the search request, even though on the wire it is the same, it is
 printed as 25:ff:7e:7d;1a:f2:
 Am I correct to assume it is because the assertionValue print naively
 prints the data, with disregard to its actual content?
 In the reply, as the item is indeed dissected as a GUID, it is displayed
 properly.

 TIA,
 Y.

 --

 ___
 Wireshark-dev mailing [EMAIL 
 PROTECTED]://www.wireshark.org/mailman/listinfo/wireshark-dev



 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] LDAP GUID display bug?

[Kaul]

Running 0.99.7, on Windows, capturing Active Directory LDAP communication,
there's some wrong display of GUIDs (object type objectGUID). For example,
what on the wire looks like (hex) 25 ff 7e 7d 1a f2 a2 49... should be
7d7eff25-f21a-49a2-... (I think the rest is like the wire). However, I see
that on the search request, even though on the wire it is the same, it is
printed as 25:ff:7e:7d;1a:f2:
Am I correct to assume it is because the assertionValue print naively prints
the data, with disregard to its actual content?
In the reply, as the item is indeed dissected as a GUID, it is displayed
properly.

TIA,
Y.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] [PATCH] packet-sctp.c: rename SERIAL_NUMBER_LENGTH to SCTP_SERIAL_NUMBER_LENGTH to fix compilation failure

[Kaul]

On Windows, with both MSVC 2005 express and MSVC 2008 express, compilation
fails due to redefinition of SERIAL_NUMBER_LENGTH.
Changed it to SCTP_SERIAL_NUMBER_LENGTH to avoid the collision.


packet-sctp.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

[Kaul]

Mine was defined, not even sure why.
Without it, it compiles fine - thanks.

I've filed http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2089 about
this issue.
Perhaps the bug is that nettle is not brought by the 'nmake ... setup'
command?


On Dec 11, 2007 10:02 AM, Stephen Fisher [EMAIL PROTECTED] wrote:

 On Tue, Dec 11, 2007 at 09:01:13AM +0200, Kaul wrote:

  Thanks, I've tried that, but it didn't help. Can you tell me where
  your hmac.h and/or des.h files are located?

 I actually don't seem to have those files.  Notice that they're included
 in packet-isakmp.c / packet-kerberos.c within a #ifdef HAVE_LIBNETTLE
 block.  My c:\wireshark\config.h does NOT hav e HAVE_LIBNETTLE defined.
 Does yours?


 Steve

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] packet-dlm compilation errors

[Kaul]

In addition to the inability to compile Wireshark (at least on my Windows)
for at least a week, due to problem with include files in kerberos, I'm now
also getting:
packet-dlm3.c
packet-dlm3.c(557) : error C2065: 'uint16_t' : undeclared identifier
packet-dlm3.c(557) : error C2146: syntax error : missing ';' before
identifier '
namelen'
packet-dlm3.c(557) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(558) : error C2065: 'uint32_t' : undeclared identifier
packet-dlm3.c(558) : error C2146: syntax error : missing ';' before
identifier '
exflags'
packet-dlm3.c(558) : error C2065: 'exflags' : undeclared identifier
packet-dlm3.c(589) : error C2065: 'exflags' : undeclared identifier
packet-dlm3.c(627) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(630) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(642) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(644) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(647) : error C2065: 'namelen' : undeclared identifier
packet-dlm3.c(650) : error C2065: 'exflags' : undeclared identifier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

[Kaul]

Thanks, I've tried that, but it didn't help. Can you tell me where your
hmac.h and/or des.h files are located?

On Dec 11, 2007 12:31 AM, Stephen Fisher [EMAIL PROTECTED] wrote:

 On Sun, Dec 02, 2007 at 10:05:16PM +0200, Kaul wrote:
  I can't compile latest SVN for the last two days or so, getting:
 
  packet-kerberos.c(74) : fatal error C1083: Cannot open include file: '
 des.h':
  No
   such file or directory
  ...
  packet-isakmp.c(50) : fatal error C1083: Cannot open include file: '
 hmac.h':
  No
  such file or directory

  Any ideas? gnutls related?

 Unfortunately, I have no idea since I'm not a regular Windows developer.
 I can say that my Windows build is working fine.  Have you run nmake -f
 makefile.nmake setup recently then tried compiling?  That will grab the
 latest libraries for you like you did when you first set up the buil
 environment.


 Steve

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

[Kaul]

I can't compile latest SVN for the last two days or so, getting:

packet-kerberos.c(74) : fatal error C1083: Cannot open include file: 'des.h':
No
 such file or directory
...
packet-isakmp.c(50) : fatal error C1083: Cannot open include file: 'hmac.h':
No
such file or directory

...
packet-dcerpc-nt.c
Generating Code...
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\cl.EXE' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\nmake.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\nmake.exe' : return code '0x2'
Stop.


Any ideas? gnutls related?
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Wireshark 0.99.7pre1 is now available

[Kaul]

It crashes on reassembling a segmented XML (over HTTP - I reckon an RSS
feed).
I thought all along it had something to do with my (yet unaccepted) changes
to packet-http.c and req_resp_hrds.c , so didn't want to bother the list
with it, but it just happened with a clean install of the binary as well.
Regretfully, when running within a debugger, it only offers disassembly
(although I compile with debug symbols). Any options how to debug it? It
doesn't happen if 'reassemble HTTP bodies spanning multiple TCP segments' is
turned off.

I'm afraid the information within the capture is private, so I can't share
it, but any help /hints debugging it will be appreciated.

On Nov 22, 2007 12:21 AM, Gerald Combs [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Wireshark 0.99.7pre1 is now available for testing.  Source code and a
 Windows installer can be downloaded immediately from

 http://www.wireshark.org/download/prerelease/wireshark-0.99.7pre1.tar.gz
 http://www.wireshark.org/download/prerelease/wireshark-0.99.7pre1.u3p

 http://www.wireshark.org/download/prerelease/wireshark-setup-0.99.7pre1.exe

 This release adds many bug fixes and new features.  An in-progress list
 of changes can be found in the release notes at
 http://www.wireshark.org/docs/relnotes/wireshark-0.99.7.html .

 Please report any problems you find to the wireshark-dev mailing list or
 open a ticket at http://bugs.wireshark.org/ .

 Barring any problems, the final release will be out late next week, on
 November
 29th or 30th.


 File verification information:

 wireshark-0.99.7pre1.tar.gz: 16679729 bytes
 MD5(wireshark-0.99.7pre1.tar.gz)=5ec97db4ec4683a527853871da649dae
 SHA1(wireshark-0.99.7pre1.tar.gz)=27324b52c9e790dc8bba6ade0f30bcb2cf8b4f3a
 RIPEMD160(wireshark-0.99.7pre1.tar.gz
 )=d1300c0ae8ac1c62c3aa688b4768cf8f6d42abf8

 wireshark-0.99.7pre1.u3p: 26187951 bytes
 MD5(wireshark-0.99.7pre1.u3p)=4720f92770959505001f647ef60bef1b
 SHA1(wireshark-0.99.7pre1.u3p)=d9350d9b6159e597008693764bb9027348bb8e8f
 RIPEMD160(wireshark-0.99.7pre1.u3p
 )=ec8baaeb1b3fc4a59a61f6f8c6066c45f97f2e89

 wireshark-setup-0.99.7pre1.exe: 21081220 bytes
 MD5(wireshark-setup-0.99.7pre1.exe)=a2e3bad6b36d2a9adab0f94a5a1f82c2
 SHA1(wireshark-setup-0.99.7pre1.exe
 )=da9662efc4737645fba31dea324f56400a5ea242
 RIPEMD160(wireshark-setup-0.99.7pre1.exe
 )=1d07d972b8f21646e49596d089ded480da105510

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iD8DBQFHRK94pw8IXSHylJoRApsVAKCv0LEOk5Q4lG+k1nHjog8Yx3vysQCgrOZF
 FfN7vOuaJNGo/ii6oN3DGhM=
 =YOX1
 -END PGP SIGNATURE-
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Wireshark 0.99.7pre1 is now available

[Kaul]

Thanks for your quick response. Tried with rev. 23547 - works!

Y.

On Nov 23, 2007 10:34 AM, Kukosa, Tomas [EMAIL PROTECTED] wrote:

  Hi,

 it could be probably problem with long hex dump pane crash which I have
 fixed in the Rev. 23527.
 It will be merged from development branch to 0.99.7 before release.

 Please test the last svn version if it really helps.

 Tomas


  --
 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *Kaul
 *Sent:* Friday, November 23, 2007 9:24 AM
 *To:* Developer support list for Wireshark
 *Cc:* Wireshark announcements; Community support list for Wireshark
 *Subject:* Re: [Wireshark-dev] Wireshark 0.99.7pre1 is now available

 It crashes on reassembling a segmented XML (over HTTP - I reckon an RSS
 feed).
 I thought all along it had something to do with my (yet unaccepted)
 changes to packet-http.c and req_resp_hrds.c , so didn't want to bother
 the list with it, but it just happened with a clean install of the binary as
 well.
 Regretfully, when running within a debugger, it only offers disassembly
 (although I compile with debug symbols). Any options how to debug it? It
 doesn't happen if 'reassemble HTTP bodies spanning multiple TCP segments' is
 turned off.

 I'm afraid the information within the capture is private, so I can't share
 it, but any help /hints debugging it will be appreciated.

 On Nov 22, 2007 12:21 AM, Gerald Combs  [EMAIL PROTECTED] wrote:

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Wireshark 0.99.7pre1 is now available for testing.  Source code and a
  Windows installer can be downloaded immediately from
 
  http://www.wireshark.org/download/prerelease/wireshark-0.99.7pre1.tar.gz
  http://www.wireshark.org/download/prerelease/wireshark-0.99.7pre1.u3p
 
  http://www.wireshark.org/download/prerelease/wireshark-setup-0.99.7pre1.exe
 
  This release adds many bug fixes and new features.  An in-progress list
  of changes can be found in the release notes at
  http://www.wireshark.org/docs/relnotes/wireshark-0.99.7.html .
 
  Please report any problems you find to the wireshark-dev mailing list or
 
  open a ticket at http://bugs.wireshark.org/ .
 
  Barring any problems, the final release will be out late next week, on
  November
  29th or 30th.
 
 
  File verification information:
 
  wireshark-0.99.7pre1.tar.gz: 16679729 bytes
  MD5(wireshark-0.99.7pre1.tar.gz)=5ec97db4ec4683a527853871da649dae
  SHA1(wireshark-0.99.7pre1.tar.gz)=27324b52c9e790dc8bba6ade0f30bcb2cf8b4f3a
 
  RIPEMD160(wireshark-0.99.7pre1.tar.gz
  )=d1300c0ae8ac1c62c3aa688b4768cf8f6d42abf8
 
  wireshark-0.99.7pre1.u3p: 26187951 bytes
  MD5(wireshark-0.99.7pre1.u3p)=4720f92770959505001f647ef60bef1b
  SHA1(wireshark-0.99.7pre1.u3p )=d9350d9b6159e597008693764bb9027348bb8e8f
  RIPEMD160(wireshark-0.99.7pre1.u3p
  )=ec8baaeb1b3fc4a59a61f6f8c6066c45f97f2e89
 
  wireshark-setup-0.99.7pre1.exe: 21081220 bytes
  MD5(wireshark-setup-0.99.7pre1.exe)=a2e3bad6b36d2a9adab0f94a5a1f82c2
  SHA1(wireshark-setup-0.99.7pre1.exe
  )=da9662efc4737645fba31dea324f56400a5ea242
  RIPEMD160(wireshark-setup-0.99.7pre1.exe
  )=1d07d972b8f21646e49596d089ded480da105510
 
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.6 (Darwin)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
  iD8DBQFHRK94pw8IXSHylJoRApsVAKCv0LEOk5Q4lG+k1nHjog8Yx3vysQCgrOZF
  FfN7vOuaJNGo/ii6oN3DGhM=
  =YOX1
  -END PGP SIGNATURE-
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev
 


 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] VS2008 Express compilation attempt

[Kaul]

A naive attempt (see attached patch to Makefile.nmake), resulted in:

...
libpcap.c
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\stdio.h(358) : error
C31
63: '_vsnprintf': attributes inconsistent with previous declaration
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\stdio.h(350)
: s
ee declaration of '_vsnprintf'
...
Generating Code...
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\cl.EXE' : return code '0x2'
Stop.


I found similar issue here:
http://sourceforge.net/forum/forum.php?thread_id=1839725forum_id=36109
but I couldn't resolve it in Wireshark's case.


config.nmake.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] VS2008 Express compilation attempt

[Kaul]

The attached change to libpcap.c (re-order the #include statements) seems to
solve it.
There are other places it is required (capture-wpcap.c, for example), and
this simple change didn't work as nicely.

There's a similar problem with inet_pton() and inet_ntop() in various other
files:
capture.c
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2tcpip.h(583) :
error C2
373: 'inet_pton' : redefinition; different type modifiers
c:\wireshark\inet_v6defs.h(31) : see declaration of 'inet_pton'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2tcpip.h(600) :
error C2
373: 'inet_ntop' : redefinition; different type modifiers
c:\wireshark\inet_v6defs.h(33) : see declaration of 'inet_ntop'
capture_opts.c
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2tcpip.h(583) :
error C2
373: 'inet_pton' : redefinition; different type modifiers
c:\wireshark\inet_v6defs.h(31) : see declaration of 'inet_pton'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2tcpip.h(600) :
error C2
373: 'inet_ntop' : redefinition; different type modifiers
c:\wireshark\inet_v6defs.h(33) : see declaration of 'inet_ntop'
Generating Code...
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN
\cl.EXE' : return code '0x2'
Stop.


On Nov 20, 2007 9:24 PM, Kaul [EMAIL PROTECTED] wrote:

 A naive attempt (see attached patch to Makefile.nmake), resulted in:

 ...
 libpcap.c
 C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\stdio.h(358) :
 error C31
 63: '_vsnprintf': attributes inconsistent with previous declaration
 C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\stdio.h(350)
 : s
 ee declaration of '_vsnprintf'
 ...
 Generating Code...
 NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
 9.0\VC\BIN
 \cl.EXE' : return code '0x2'
 Stop.


 I found similar issue here: 
 http://sourceforge.net/forum/forum.php?thread_id=1839725forum_id=36109

 but I couldn't resolve it in Wireshark's case.



libpcap.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Wireshark-commits] rev 23484: /trunk/ /trunk/: config.nmake /trunk/packaging/portableapps/win32/: makefile.nmake /trunk/packaging/u3/win32/: README.txt makefile.nmake

[Kaul]

Isn't it worth implementing for Win32 as well (and possibly Linux and so on)
?

On Nov 18, 2007 6:06 PM, Ulf Lamping [EMAIL PROTECTED] wrote:

 [EMAIL PROTECTED] schrieb:
  http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=23484
 
   Update to optionally use the Ultimate Packer for eXecutables (UPX) to
 pack the exes and dlls prior to U3 and PortableApps packaging.
 
 Very nice!
   For the U3 package, this results in a 40% smaller package.
 
 What I've roughly expected.
   For the PortableApps version, the package size is not much different,
 but the install time is quicker.
 
 ... and it will be smaller on the stick. PortableApps uses an NSIS
 installer, which has a pretty good compression ratio - so it's not
 surprising that packging the executables a second time won't help a lot.

 The values I've measured (install time and size on stick):
 uncompressed 2:50 55MB
 UPX 2:00 36MB

 So it seems to be worth included into the standard U3 and PortableApps
 packaging IMO.


 What about putting the upx301w.zip file into wireshark-win32-libs so we
 have it available on the build machine and let the config.nmake setting
 point to it as default?

 Regards, ULFL
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Smallest patch to req_resp_hdrs.{c|h}

[Kaul]

Sorry, attached.

On Nov 16, 2007 12:51 AM, Mike Duigou [EMAIL PROTECTED] wrote:

 It looks like the req_resp_hdrs.c portion of the patch was not included.
 Could you resend it?

 Mike

 Kaul wrote:
  This very small patch declares two variables passed to the function as
  const, and re-arranges two lines so they'll appear after an 'if'
  statement that if taken, won't need the above lines.
 
  Regards,
  Yaniv.

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev



req_resp_hdrs.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Smallest patch to req_resp_hdrs.{c|h}

[Kaul]

This very small patch declares two variables passed to the function as
const, and re-arranges two lines so they'll appear after an 'if' statement
that if taken, won't need the above lines.

Regards,
Yaniv.


req_resp_hdrs.h.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Small patch to packet-xml.c to allow dissecting the XML within application/rss+xml streams

[Kaul]

Used by some RSS servers, it contains XML.

Regards,
Yaniv.


packet-xml.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Small performance improvements to packet-http.c

[Kaul]

I've fixed ep_strndup - se_stnrdup, patch attached.
From subjective testings, it seems that there is some measurable performance
improvement - 5-10 percent on my test pcap file (~
you are not just avoiding a strncmp(), but also the char-by-char search for
the space that follows the method (as well as another strncmp() for 'M-',
which is a rare case as well). The optimization, while not the cleanest
coding-wise, works well because it works for the most common cases - and I
believe many, many times (subjectively  90%) of the times it'll hit the
optimized path.
Nevertheless, it is important for me that it'll be understood - so I
documented it inline clearly - I think.


On Nov 8, 2007 2:12 AM, Stephen Fisher  [EMAIL PROTECTED] wrote:

 On Mon, Nov 05, 2007 at 09:15:45AM +0200, Kaul wrote:

  Somewhat inspired by the performance improvements to tvbuff, I've made
  some small performance improvements to packet-http.c:

  1. In the most common cases 'GET ', 'POST', 'HTTP' - compare them
  against the 32bit value of those strings, instead of strncmp(). I
  reckon in most cases it'll be used, and there won't be need for longer
  comparison paths.

 Is this a significant enough performance improvement to warrant making
 the code a bit harder to read, maintain and understand?  The strncmp()
 function, at least in a recent FreeBSD libc, looks pretty quick and
 simple as it is.  I am just wondering; I do not mean to discourage you
 from you from contributing.


 Steve

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Small performance improvements to packet-http.c

[Kaul]

This time, with the patch attached.

On Nov 8, 2007 9:56 PM, Kaul [EMAIL PROTECTED] wrote:

 I've fixed ep_strndup - se_stnrdup, patch attached.
 From subjective testings, it seems that there is some measurable
 performance improvement - 5-10 percent on my test pcap file (~
 you are not just avoiding a strncmp(), but also the char-by-char search
 for the space that follows the method (as well as another strncmp() for
 'M-', which is a rare case as well). The optimization, while not the
 cleanest coding-wise, works well because it works for the most common cases
 - and I believe many, many times (subjectively  90%) of the times it'll hit
 the optimized path.
 Nevertheless, it is important for me that it'll be understood - so I
 documented it inline clearly - I think.



 On Nov 8, 2007 2:12 AM, Stephen Fisher  [EMAIL PROTECTED] wrote:

  On Mon, Nov 05, 2007 at 09:15:45AM +0200, Kaul wrote:
 
   Somewhat inspired by the performance improvements to tvbuff, I've made
   some small performance improvements to packet-http.c:
 
   1. In the most common cases 'GET ', 'POST', 'HTTP' - compare them
   against the 32bit value of those strings, instead of strncmp(). I
   reckon in most cases it'll be used, and there won't be need for longer
   comparison paths.
 
  Is this a significant enough performance improvement to warrant making
  the code a bit harder to read, maintain and understand?  The strncmp()
  function, at least in a recent FreeBSD libc, looks pretty quick and
  simple as it is.  I am just wondering; I do not mean to discourage you
  from you from contributing.
 
 
  Steve
 
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev
 




packet-http.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev