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

[Peter Wu]

Hi Kaul,

On Friday 20 December 2013 13:20:37 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)

Workaround: edit the header file and remove
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)

These errors was reported before, see
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9340

Workaround: use GTK2.

Regards,
Peter

___
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] cmake giving options the compiler does not understand

[Peter Wu]

Hi,

On Thursday 02 January 2014 16:02:08 Jeff Morriss wrote:
 It took me a while to get my cmake build going again today; one of the 
 reasons was that the builds would immediately fail with:
 
   cc: error: unrecognized command line option -Wshorten-64-to-32
 
 As far as I can tell the problem is simply that check_c_compiler_flag() 
 isn't working in my version of cmake (2.8.11): it always returns 1.  Or 
 does it not work for others?

I sometimes have this issue too, but it got fixed by clearing the build 
directory (`rm -rf build`) and then configuring the tree again with cmake.

In CMakeFiles/CMakeError.log, I can find that warning too, it seems that
it gets dropped by cmake (perhaps because it is not recognized?).

This is CMake 2.8.12.1 and GCC 4.8.2.

Regards,
Peter
___
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] do we continue to reference revision numbers?

[Peter Wu]

On Friday 31 January 2014 11:46:34 Hadriel Kaplan wrote:
 Any specific leading character(s) we should use, so that bugzilla can
 someday parse it and insert the appropriate url? Like ‘c[commit_id_sha1]'

I propose the regex /\bcommit [0-9a-f]{4,40}\b/i (or /[Cc]ommit .../ without i 
modifier). cabcdef does not look pretty and the commit abcdef notation is 
also very natural (see commit messages for Linux, bisect runs, etc.

Regards,
Peter

___
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 set up the display filter?

[Peter Wu]

On Monday 03 March 2014 16:25:06 我想不无聊 wrote:
 I just captured WLAN packets with wireshark, I want to display the packets
 whose source address is 10.0.1.128 ,what is the display filter
 expression?thanks.

The manual page of wireshark-filter(4) has an example for this. Adapter for 
your case:

ip.src == 10.0.1.128

If you only need packets from this IP, consider setting a capture filter.


dumpcap -i eth0 -w capture.pcapng -f 'host 10.0.1.128'

Or if you only care about packets originating from that IP:

dumpcap -i eth0 -w capture.pcapng -f 'src host 10.0.1.128'

(see manual page of pcap-filter(7)).

Peter

___
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 1.10.6 is now available

[Peter Wu]

On Saturday 08 March 2014 10:12:48 Edwin Groothuis wrote:
 On 8/03/14 06:49 , Gerald Combs wrote:
  I'm proud to announce the release of Wireshark 1.10.6.
 
 In the past I was able to get the source of this release via svn
 checkout http://anonsvn.wireshark.org/releases/xxx; and incorporate it
 back into our private repository.
 
 Could a skilled person show me how to get this with git?

You could create a tarball with all source code by running the following 
command *from the top-level dir*:

git archive -o tar.gz --prefix=wireshark-1.10.6/ wireshark-1.10.6  
wireshark-1.10.6.tar.gz

(if you run this from a subdirectory, then you will only include files 
starting from the subdirectory.)

This would be similar to `svn export`. If you have a git repository and want 
to merge the changes from 1.10.6, use something like this:

# assume your private work is on a branch private-branch
git checkout private-branch
# merge changes
git merge wireshark-1.10.6
# equivalent because Wireshark has TWO tags for the same commit:
#git merge v1.10.6

Regards,
Peter

___
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] Regarding Plugin attachment

[Peter Wu]

On Tuesday 11 March 2014 23:12:34 Nilesh Nayak wrote:
 Is it necessary to uninstall the wireshark each time you try to add a new
 plugin for your customised protocol?

No, a plugin can be enabled and disabled without reinstalling WS.

 Or can we have 2 instances of wireshark running on the same machine ?

See the manual page of wireshark, in particular the part about plugins. If you 
have two different versions of wireshark, then you can put two different 
plugins in different directories.

 Could someone help me with a basic foo plugin ?

What is your purpose? Have you read doc/README.developer already? If you are 
trying to create a dissector, I suggest to add a new protocol dissector 
instead of a plugin. Those are easier to add (but require you to build a new 
WS binary).

Regards,
Peter

___
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 use wireshark source code?

[Peter Wu]

Hi,

On Thursday 27 March 2014 17:05:08 我想不无聊 wrote:
 I add a file named peformance.h under wireshark  main directory,
 
 
 peformance.h

spelling error here (and below), it should be performance.

 #include glib.h
 
 
 typedef struct peformance_s
 {
   gfloat time[100];
   gfloat delay[100];
   guint32 packetSize[100];
   guint32 payload;
   guint32 index;
   guint32 temp_size;
   gfloat temp_time;
 }peformance;
 extern peformance* peformance_test;
 
 
 
 then I modify the /epan/dissectors/packet-ieee80211.c,
 #include ../../peformance.h
 
 
 then define the struct variable,
 peformance pef_test;
 peformance * peformance_test=pef_test;
 
 
 peformance_test-index=0;
 
 when i execute sudo make, it occurs to me one error ,below is the error 
 information:

You should not run the compilation as root. Just make is fine.
To fix up this mistake, change the ownership of the object files to your user.

 packet-ieee80211.c:94:30: error: ../../peformance.h: No such file or directory

This is a clear hint.

 packet-ieee80211.c:149: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before 'pef_test'
 packet-ieee80211.c:150: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '*' token
 packet-ieee80211.c:153: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '-' token

The top-level directory is already in the headers search path. Just drop the
../..:

   #include performance.h

Kind regards,
Peter

___
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 use wireshark source code?

[Peter Wu]

(re-adding list in reply)

Please do not top-post.

On Thursday 27 March 2014 17:34:38 我想不无聊 wrote:
 it still occurs to me this error:
 
 
 packet-ieee80211.c:131: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '-' token
 
 what is going on?

You really need to show more details, like source code and the context
of that error (i.e. some lines before and after this error).

Kind regards,
Peter

 
 -- 原始邮件 --
 [..]
  packet-ieee80211.c:94:30: error: ../../peformance.h: No such file or 
  directory
 
 This is a clear hint.
 
  packet-ieee80211.c:149: error: expected '=', ',', ';', 'asm' or 
  '__attribute__' before 'pef_test'
  packet-ieee80211.c:150: error: expected '=', ',', ';', 'asm' or 
  '__attribute__' before '*' token
  packet-ieee80211.c:153: error: expected '=', ',', ';', 'asm' or 
  '__attribute__' before '-' token
 
 The top-level directory is already in the headers search path. Just drop the
 ../..:
 
#include performance.h

___
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 include a head file

[Peter Wu]

On Friday 28 March 2014 13:10:09 我想不无聊 wrote:
 then I add the file to /gtk/main.c file ,
 #include peformance.h //somebody told me not to use ../peformance.h 
 because there is subdir to search

Well, I was that somebody and refused to reply on the last private mail
because you provided *no* additional details that was requested.

 
 peformance pef_test;
 peformance *peformance_test=pef_test;

Please fix this typo, it is performance. PeRformance.

 in the ./wiretap/libpcap.c file, I want to use struct peformance ,
 #include peformance.h  //or #include ../peformance.h,i do not know which 
 one to use
 
 peformance_test-index=0;
 
 it shows to me one error,the error information is :
 
wiretap/.libs/libwiretap.so: undefined reference to `peformance_test'  
 
 what is going on and why is that?

libwiretap is not linked with the ui, but wireshark is. If you need
your symbol in libwiretap, then define performance_test in libwiretap.
libwiretap gets linked with wireshark, so this should work fine.

Kind regards,
Peter

___
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 use the wireshark source code to develop application?

[Peter Wu]

On Sunday 30 March 2014 14:57:59 我想不无聊 wrote:
 //performance.h
 #include glib.h
 typedef struct performance_s
 {
 gfloat time[100];
 gfloat delay[100];
 guint32 packetSize[100];
 guint32 payload;
 guint32 index;
 guint32 temp_size;
 gfloat temp_time;
 }performance;

Finally, at least the spelling error got corrected.

 extern peformance* performance_test;

But the type here still has that typo.

Kind regards,
Peter

___
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] WARNING aclocal

[Peter Wu]

Hi,

On Sunday 06 April 2014 12:52:32 khemis haythem wrote:
 i m trying to build envirenement  
 1- ./autogen.sh 
 you should update your 'aclocal.m4' by running aclocal 
 what to do ?? i m blocked here for 2 days who can help me ? 

Posting the same question a day later won't speed up getting answers.
It would help if you post the full output.

Have you tried using cmake instead of autofoo? It improved build speed
for me and allows you to keep a clean source tree, separated from the
objects directory.

Peter
___
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] WARNING aclocal

[Peter Wu]

On Sunday 06 April 2014 13:15:07 khemis haythem wrote:
 really i haven't tried using cmake instead of autofoo 
 but when i can use cmake ? 
 and about the the full output, is like these picture :
 after $aclocal i get :
 aclocal.png 
 and after ./autogen.sh i get :
 autogen_sh.png 

Are you serious? Top-posting on a list... OK. But please
do not send pictures of command output if you could as well
copy it and insert the output in the mail.

Usage of cmake:
mkdir /tmp/wsbuild  cd /tmp/wsbuild  # /tmp/wsbuild it output dir
# The configure step, you can also use cmake-gui if you prefer
cmake ~/wireshark
make
make install

Examples for cmake:
https://git.lekensteyn.nl/peter/wireshark-notes/tree/notes.txt
https://github.com/Lekensteyn/aur/blob/master/wireshark/PKGBUILD#L34

Be sure to install appropriate headers and libraries... On Ubuntu you
can use sudo apt-get build-dep wireshark for that.

Peter

___
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] Possible change to packet-ssl.c?

[Peter Wu]

On Wednesday 09 April 2014 16:49:43 Guy Harris wrote:
 Why is that treated as a this is encrypted indication rather than a
 somebody's trying to extract whatever's in the server's memory after the
 request payload indication?

After the handshake, the record layer is encrypted, including heartbeats.
___
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 wireshark

[Peter Wu]

On Friday 11 April 2014 21:54:28 khemis haythem wrote:
 how i know that wireshark is corectly builded on ubuntu 12.04 ? 
 there's any methode to know this ?? 

Yes, run it. If you build it correctly, you have binaries in the run/ 
directory. run/wireshark, run/tshark, etc.

I see you have a Yahoo address. If you have logged in on 7 or 8 April via 
webmail, then you should change your password because it got possibly leaked 
via the Heartbleed bug.

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

Re: [Wireshark-dev] git history of files moved in SVN

[Peter Wu]

On Monday 14 April 2014 17:07:48 Jeff Morriss wrote:
  (That change doesn't show up in the history of
  epan/dissectors/packet-tcp.c in the Git repository, probably because the
  SVN-to-Git converter couldn't handle moves/renames in SVN, perhaps
  because SVN, while handling them better than CVS, still handles them a
  bit awkwardly.)
 
 Ouch--you'd think that this kind of thing would work.  I guess none of 
 the dissectors have a history prior to The Great Dissector Move of 
 2004/7/18.  Pity, as I recall a significant portion of the reason to 
 move to SVN (from CVS) was so that files could be moved without losing 
 history.

It is preserved, you just need to add the --follow option to continue the 
history after a rename:

git log --follow --stat epan/dissectors/packet-tcp.c

Output:

commit 669db206cb1f270046ad400fff7655e20c63e723
Author: Gilbert Ramirez g...@alumni.rice.edu
Date:   Sun Jul 18 18:06:47 2004 +

Move dissectors to epan/dissectors directory.

Also move ncp222.py, x11-fields, process-x11-fields.pl,
make-reg-dotc, and make-reg-dotc.py.

Adjust #include lines in files that include packet-*.h
files.

svn path=/trunk/; revision=11410

 packet-tcp.c = epan/dissectors/packet-tcp.c | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

Gits renames are based on heuristics, there is no rename metadata stored. 
Sometimes you also want to see renamed files in a single commit with 
additional changes. In that case you are looking for the -M option to detect 
that (by default there is a similarity index of 50%.) See the manual page git-
log(1) for more details.

Kind regards,
Peter

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

Re: [Wireshark-dev] [Wireshark-commits] master fc5d8db: Create the HTTP tree after we're assured it's HTTP. Otherwise a bogus tree is created when HTTP2 traffic is found.

[Peter Wu]

On Thursday 24 April 2014 16:41:02 mman...@netscape.net wrote:
 After looking at this, I'd have to say the DTLS decryption test is
 flawed.  It sets up a key to decifer traffic as HTTP, but it's not really
 HTTP, it's just a bunch of ASCII strings.  I can change it to any of the
 valid dissectors and presuming the DTLS decyption is done correctly (which
 I presume is the real point of this test), that protocol will attempt to be
 dissected in the subsequent frames (and be caught by that protocol's
 filter).
 
 Ideas on the best way to fix this so I can restore removing the bogus HTTP
 tree when it's not really HTTP? 

The Wireshark GUI has some panels for data sources on the bottom which shows 
Frame and Decrypted DTLS data. If something like dtls.data.data and/or 
dtls.data.str (or something generic for all data sources) would be added, 
then that would solve this problem.

Though I don't know how feasible this is, in terms of memory and CPU.

Kind regards,
Peter

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

Re: [Wireshark-dev] GIT vs SVN

[Peter Wu]

On Friday 25 April 2014 11:27:35 Jeff Morriss wrote:
 Basically:
 
 1) Create a branch off master (git checkout -b myprivatebranch master)
 2) Make your changes
 3) Check in your changes (git commit -a)
 3.a) Make sure you never git push from this branch :-).  If someone 
 knows a way to make it impossible, please let me know.

If you do not set a remote for this branch, then this branch won't be pushed.
The default behavior of git push without options can be configured with the 
push.default setting (see man git-config(1)).

There is nothing that prevents you from running `git push origin foo` though.

 Then if you want to pull in the later changes just do:
 
 4) git checkout master
 5) git pull
 6) git rebase master myprivatebranch

If you don't need to update master, you can follow this:

4) git fetch

(assuming that your current branch is myprivatebranch)
5a) git rebase origin/master
(otherwise, to combine git checkout  git rebase origin/master:)
5b) git rebase origin/master myprivatebranch

 
 git's pretty cool in that steps 4-6 can be automated: I have a script 
 named ~/bin/git-uup (haven't thought of a better name) which does 4-6 so 
 I only have to type git uup  make -j 9.

git fetch  git rebase origin/master  time make -j9

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

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

[Peter Wu]

On Monday 28 April 2014 22:36:46 Jaap Keuter wrote:
 I noticed that master and master-1.8 got their weekly updates, but
 master-1.10 missed it? Can we find out why?

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

Peter
___
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] ASAN bug in wiretap/pcapng; just remove the code?

[Peter Wu]

Hi Anders,

I found an ASAN bug in wiretap (stack-based buffer overrun) for which
an initial patch was submitted to
https://code.wireshark.org/review/1628/ (patchset 1 or 2).

After a more thorough look, it seems that the pcapng_dump_t type and
related code are unused.

It was first added in commit a41d93603c07fa8b6a7a334e7bf969ebd188085e
Author: Michael Tüxen tue...@fh-muenster.de  2009-06-27 17:20:44

Add support for writing pcapng files with multiple
encapsulations.
This fixes a bug reported by Sake during the
Sharkfest 09. Thanks for providing a
Netscreen tracefile with multiple link layer
types.
This patch will be included in Wireshark 1.2.1
and higher.

svn path=/trunk/; revision=28862

Your (Anders) patch commented out the functions that actually use this:
commit c7f1a431d23e17a15777652b1252e139f182b0e6
Author: Anders Broman anders.bro...@ericsson.com
Date:   Mon Feb 20 20:15:51 2012 +

Handle reading and writing of multiple IDB:s, write IDB options and use 
correct lengt for strings, handle more than 100 char comment

svn path=/trunk/; revision=41082

It seems that the functionality got moved to other files, but the original
code using pcapng_dump_t can be removed (including the overrunning
g_array_ parts). Is that a correct observation?

A patch is underway, I'm asking just in case the change was unintentional.

Kind regards,
Peter

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

[Wireshark-dev] Gerrit usability and git web interface

[Peter Wu]

Hi,

First, a request: could the gitweb commit messages also be post-
processed such that things like Bug: XXX and URLs become clickable?

An arbitrary example that shows the expected and actual messages:
https://code.wireshark.org/review/999/
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=changes/99/999/2;ds=sidebyside


Gerrit has some usability issues, some comments:

 - Diffs for large files are slow[1]. I asked on IRC (#gerrit @ Freenode),
   Gerrit 2.9 should have become better at this. See the button on the
   top-right for example options[2]. I am told that this is a per-patch
   and per-user setting, but it is not clear whether a default can be set.
   Since many dissectors in WS are huge, it is probably wise to set
   defaults that are oriented at performance: disable syntax highlighting?
   (if possible!)

 - Saner Open All diffs. The Qt people have made a patch that shows all
   changes side-by-side on one page rather than opening a window for every
   file[3]. Perhaps it is worth merging this into gerrit?

 - Would it be possible to include a diff for change mails? 
   The option sendemail.includeDiff can be used for this[4].

Also, would it be possible to set up these redirections on
code.wireshark.org:

/git - /review/gitweb
/gitweb - /review/gitweb

Besides gitweb, there is also cgit which has much nicer URLs, for example:
https://git.lekensteyn.nl/peter/wireshark/tree/epan/dissectors/packet-ssl-utils.c
Perhaps it is something to consider?

Kind regards,
Peter

 [1]: https://code.google.com/p/gerrit/issues/detail?id=2325
 [2]: 
https://gerrit-review.googlesource.com/#/c/49601/31/gerrit-gwtui/src/main/java/com/google/gerrit/client/account/MyPreferencesScreen.java
 [3]: https://code.google.com/p/gerrit/issues/detail?id=938
 [4]: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html

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

Re: [Wireshark-dev] Fwd: Re: Storing Generated Code in Git [Was: master 9079e3a: Cheat and try to fix the generated file manually.]

[Peter Wu]

On Tuesday 24 June 2014 15:42:38 Bálint Réczey wrote:
 2014-06-24 5:26 GMT+02:00 Joerg Mayer jma...@loplof.de:
  On Mon, Jun 23, 2014 at 09:17:32PM -0400, Evan Huus wrote:
So perhaps what we should do is:
   
not check generated code into Git;
 +1

+1

   
put all generated code into the source tarballs.
 
  +2
 How about releasing two tarballs, one with and one without the generated 
 files?
 We could count the downloads.

I wouldn't bother.

 - Git is for all plain sources.
 - A distribution tarball should contain all files from git plus
   auto-generated ones. This is intended for users who just want to
   build wireshark without doing modifications to the auto-generated
   files. If wanted, they could still regenerate autogenerated files.

autotools should be able to generate that tarball, I am not so sure
about cmake.

Developers build WS from git anyway and should have the tools ready to
generate files. If the tools are not available, then that part can
simply be disabled. That would save compile time too :-)


Kind regards,
Peter

___
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] Return value of a new-style dissector

[Peter Wu]

Hi,

Since Pascal's change (TCP: do desegmentation sanity checks for all sub 
dissectors types), the whois dissector was starting to throw:

Dissector bug, protocol TCP, in packet 6: epan/dissectors/packet-tcp.c:3953: 
failed assertion save_desegment_offset == pinfo-desegment_offset  
save_desegment_len == pinfo-desegment_len

That came from this part:

pinfo-desegment_len = DESEGMENT_UNTIL_FIN;
pinfo-desegment_offset = 0;
return (0);

It is likely supposed to mean well, this packet is mine, please give all data 
until the connection is closed. The `return 0` is clearly wrong here. But
what is the correct value?

From epan/packet.h:
/*
 * Dissector that returns:
 *
 *  The amount of data in the protocol's PDU, if it was able to
 *  dissect all the data;
 *
 *  0, if the tvbuff doesn't contain a PDU for that protocol;
 *
 *  The negative of the amount of additional data needed, if
 *  we need more data (e.g., from subsequent TCP segments) to
 *  dissect the entire PDU.
 */
typedef int (*new_dissector_t)(tvbuff_t *, packet_info *, proto_tree *, void *);

Almost all callers of call_dissector... ignore its return value, those who
care seem only to be interested in a boolean (zero vs non-zero). The dissectors
which use DESEGMENT_... do arbitrary things:

 - Return 0, this is just a plain error. See whois, finger, snmp, alljoyn, 
ms-mms.
 - Return tvb_length(tvb). See nbns
 - Return -pinfo-desegment_len. See ldp.
 - Return -1. See sigcomp, rtsp
 - Return -2. See fcip.
 - Return offset. See ssh, ssl
 - Return -DESEGMENT_ONE_MORE_SEGMENT (!!). jxta
 - Return the actual bytes that is wanted (offset_next - offset_before). See 
xot.

(Found with `view -p $(grep -rnl DESEGMENT_ONE_MORE_SEGMENT)`)

This suggests that something is wrong in the API definition. As it stands now,
it really needs a boolean. Can someone clarify this? Is this a bug, an
incomplete migration from the old-style dissector or a documentation issue?
Did I misunderstood something?

Kind regards,
Peter

___
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] Return value of a new-style dissector

[Peter Wu]

On Wednesday 25 June 2014 18:32:44 Peter Wu wrote:
 Hi,
 
 Since Pascal's change (TCP: do desegmentation sanity checks for all sub 
 dissectors types), the whois dissector was starting to throw:
 
 Dissector bug, protocol TCP, in packet 6: epan/dissectors/packet-tcp.c:3953: 
 failed assertion save_desegment_offset == pinfo-desegment_offset  
 save_desegment_len == pinfo-desegment_len
 
 That came from this part:
 
 pinfo-desegment_len = DESEGMENT_UNTIL_FIN;
 pinfo-desegment_offset = 0;
 return (0);
 
 It is likely supposed to mean well, this packet is mine, please give all 
 data 
 until the connection is closed. The `return 0` is clearly wrong here. But
 what is the correct value?
 
 From epan/packet.h:
 /*
  * Dissector that returns:
  *
  *The amount of data in the protocol's PDU, if it was able to
  *dissect all the data;
  *
  *0, if the tvbuff doesn't contain a PDU for that protocol;
  *
  *The negative of the amount of additional data needed, if
  *we need more data (e.g., from subsequent TCP segments) to
  *dissect the entire PDU.
  */
 typedef int (*new_dissector_t)(tvbuff_t *, packet_info *, proto_tree *, void 
 *);
 
 Almost all callers of call_dissector... ignore its return value, those who
 care seem only to be interested in a boolean (zero vs non-zero). The 
 dissectors
 which use DESEGMENT_... do arbitrary things:
 
  - Return 0, this is just a plain error. See whois, finger, snmp, alljoyn, 
 ms-mms.
  - Return tvb_length(tvb). See nbns
  - Return -pinfo-desegment_len. See ldp.
  - Return -1. See sigcomp, rtsp
  - Return -2. See fcip.
  - Return offset. See ssh, ssl
  - Return -DESEGMENT_ONE_MORE_SEGMENT (!!). jxta
  - Return the actual bytes that is wanted (offset_next - offset_before). See 
 xot.
 
 (Found with `view -p $(grep -rnl DESEGMENT_ONE_MORE_SEGMENT)`)

For DESEGMENT_UNTIL_FIN:

 - Return 0. See finger, ldss, whois.

desegment_len seems to be invented for use in and by dissectors, the packet API
does not use it.

Proposal: make the API return gboolean rather than an int?
Alternative: use negative values to set DESEGMENT_ONE_MORE_SEGMENT (if
desegment_len is unset). Smells like bad API design though, having two
ways to do the same thing. It may also cause breakage in unobvious ways,
existing dissectors that return the wrong value or previously set
desegment_len values?

So, back to the first proposal, what about changing to return a boolean?

 This suggests that something is wrong in the API definition. As it stands now,
 it really needs a boolean. Can someone clarify this? Is this a bug, an
 incomplete migration from the old-style dissector or a documentation issue?
 Did I misunderstood something?
 
 Kind regards,
 Peter

___
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] Return value of a new-style dissector

[Peter Wu]

On Wednesday 25 June 2014 12:56:21 Evan Huus wrote:
 On Wed, Jun 25, 2014 at 12:54 PM, Evan Huus eapa...@gmail.com wrote:
 
  On Wed, Jun 25, 2014 at 12:32 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
  Hi,
 
  Since Pascal's change (TCP: do desegmentation sanity checks for all sub
  dissectors types), the whois dissector was starting to throw:
 
  Dissector bug, protocol TCP, in packet 6:
  epan/dissectors/packet-tcp.c:3953:
  failed assertion save_desegment_offset == pinfo-desegment_offset 
  save_desegment_len == pinfo-desegment_len
 
  That came from this part:
 
  pinfo-desegment_len = DESEGMENT_UNTIL_FIN;
  pinfo-desegment_offset = 0;
  return (0);
 
  It is likely supposed to mean well, this packet is mine, please give all
  data
  until the connection is closed. The `return 0` is clearly wrong here. But
  what is the correct value?
 
  From epan/packet.h:
  /*
   * Dissector that returns:
   *
   *  The amount of data in the protocol's PDU, if it was able to
   *  dissect all the data;
 
 
  I think the above line is misleading, it should say The amount of data in
  the protocol's PDU, if the tvbuff contains a PDU for that protocol. So
  tvb_captured_length is the right return value for whois, because it is the
  amount of data (so far) claimed by the whois dissector.

Some dissectors (HTTP iirc) do repeated dissections, so this is more accurate:
The amount of data in tvbuff that could form one or more PDUs

   *  0, if the tvbuff doesn't contain a PDU for that protocol;
   *
   *  The negative of the amount of additional data needed, if
   *  we need more data (e.g., from subsequent TCP segments) to
   *  dissect the entire PDU.
 
 
  If the tcp dissector respects this (what happens if return is negative
  *and* pinfo-desegment_len is set???) then it should maybe do this instead
  of setting desegment_len at all...
 
 
 Does this mean we can get rid of the pinfo-desegment stuff once all
 dissectors are new-style?

Yes. Return -1 if you need *at least* 1 byte (like DESEGMENT_ONE_MORE_SEGMENT,
but smarter since it can then count before calling the dissector). Return
DESEGMENT_UNTIL_FIN if you want to have everything until the last byte.
Note: it should then not return tvb_captured_length(tvb).

   */
  typedef int (*new_dissector_t)(tvbuff_t *, packet_info *, proto_tree *,
  void *);
 
  Almost all callers of call_dissector... ignore its return value, those who
  care seem only to be interested in a boolean (zero vs non-zero). The
  dissectors
  which use DESEGMENT_... do arbitrary things:
 
   - Return 0, this is just a plain error. See whois, finger, snmp,
  alljoyn, ms-mms.
   - Return tvb_length(tvb). See nbns
   - Return -pinfo-desegment_len. See ldp.
   - Return -1. See sigcomp, rtsp
   - Return -2. See fcip.
   - Return offset. See ssh, ssl
   - Return -DESEGMENT_ONE_MORE_SEGMENT (!!). jxta
   - Return the actual bytes that is wanted (offset_next - offset_before).
  See xot.
 
  (Found with `view -p $(grep -rnl DESEGMENT_ONE_MORE_SEGMENT)`)
 
  This suggests that something is wrong in the API definition. As it stands
  now,
  it really needs a boolean. Can someone clarify this? Is this a bug, an
  incomplete migration from the old-style dissector or a documentation
  issue?
  Did I misunderstood something?
 
 
  I'm not sure, I didn't write the new API. I think incomplete migration?

Ok, forget about the boolean. It would be really nice if desegment_len could
be dropped by fixing the return value.

Guy Harris introduced the new_dissector_t type according to git, the intent
was good, but the implementation is incomplete.

commit 193b8c9bfbd15afde08076ee1dc09abf914b9abe
Author: Guy Harris g...@alum.mit.edu
Date:   Tue Feb 26 11:55:39 2002 +

Allow dissectors to be registered as old-style or new-style
dissectors.  Old-style dissectors return nothing.  New-style
dissectors return one of:

a positive integer, giving the number of bytes worth of data in
the tvbuff that it considered to be part of the PDU in the
tvbuff;

zero, if it didn't consider the data in the tvbuff to be a PDU
for its protocol;

a negative integer, giving the number of additional bytes worth
of data in needs to get the complete PDU (for use with
fragmentation/segmentation when the length of the PDU isn't
known to the protocol atop the one the dissector is dissecting).

Have call_dissector() return the return value of new-style dissectors,
and the length of the tvbuff handed to it for old-style dissectors.

Have dissector_try_port() return FALSE if the subdissector is a
new-style dissector and returned 0.

Make the EAP dissector a new-style dissector, and have a EAP fragment
dissector that is also a new-style dissector and handles fragmentation
of EAP messages (as happens above, for example, RADIUS).  Also, clean up
some signed vs. unsigned comparison

[Wireshark-dev] Collection of captures for each supported dissector?

[Peter Wu]

Hi,

Is there an accessible list of capture files for each supported
dissector? I would like to make some changes w.r.t. reassembly, but
want to be sure not to introduce regressions. SampleCaptures contains
a list of captures, but these are not complete and are not grouped
per dissector.

What I am looking for are captures that exercise the normal cases and
boundaries of a dissector. Also known as a torture test.

A dissector may have multiple captures for different situations, but it
should not be too large (100 MiB is large). The regression test is
then performed with a diff against the output of tshark.

Does anyone known such a list?

Kind regards,
Peter
https://lekensteyn.nl
___
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] Collection of captures for each supported dissector?

[Peter Wu]

On Monday 30 June 2014 07:12:56 Evan Huus wrote:
 The menagerie is our collection of capture files that the fuzz-bot uses to
 test with. It contains a substantial number of files across as many
 protocols as we have been able to accumulate. However, I am not sure it is
 entirely publicly accessible?

I have seen the menagerie mentioned in bug reports, but could never find this 
publically.

 Additionally, it is not indexed. There is a script somewhere to use tshark
 to extract the protocols contained in each capture and build a list, but it
 only works for protocols which are dissectible by default (no decode as,
 decryption, or other special settings usually).
 
 One of the ideas floated at sharkfest this year was the possibility of a
 proper interface to the menagerie, but I don't think anything really came
 of it. What protocol are you interested in right now?

There is no particular protocol I am interested at, it was an idea to improve 
regression testing. Right now I am looking at all dissectors below TCP (or on 
top, depending on how you look at it).


By the way, could I get delete permissions for attachments for the 
SampleCaptures page on the wiki? There are a bunch of duplicates (and even 
some empty files) listed as attachment and not linked. Some are not even
captures files although their extension suggest so.

Empty files:
mount-de.pcap.gz
omron-test-csum.pcap
wireshark.org.pcap.gz

Not pcap (but tcpdump text output or even a media file):
packetout.pcap
RTSP.pcap

Duplicates can be found with:
md5sum * | sort | uniq -w32 -D | while read sum file; do echo $sum $(date 
+%Y-%m-%d %H:%M -r $file) $(du -hD $file); done

Are there known efforts to index the files? I don't think that the wiki is a 
sustainable way to collect them?

Kind regards,
Peter
https://lekensteyn.nl

___
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] Collection of captures for each supported dissector?

[Peter Wu]

(adding back the list, adding Gerald)

On Monday 30 June 2014 09:33:29 Evan Huus wrote:
 On Mon, Jun 30, 2014 at 9:05 AM, Peter Wu pe...@lekensteyn.nl wrote:
  On Monday 30 June 2014 07:12:56 Evan Huus wrote:
   The menagerie is our collection of capture files that the fuzz-bot
   uses to
   test with. It contains a substantial number of files across as many
   protocols as we have been able to accumulate. However, I am not sure it
   is entirely publicly accessible?
  
  I have seen the menagerie mentioned in bug reports, but could never find
  this publically.
 
 The best public collection I've been able to find is [1] which is all the
 fuzzed captures that have ever caused the fuzz-bot to fail. It's worth
 noting that the vast majority of the remaining menagerie (~90% at a rough
 guess) is harvested from Bugzilla attachments, so most of the individual
 captures are already public, they're just not easily browseable.

5 GiB of non-specific captures, I think I'll pass for now on this.
 
 [1] http://www.wireshark.org/download/automated/captures/
 
   Additionally, it is not indexed. There is a script somewhere to use
   tshark
   to extract the protocols contained in each capture and build a list, but
   it only works for protocols which are dissectible by default (no decode
   as, decryption, or other special settings usually).
   
   One of the ideas floated at sharkfest this year was the possibility of a
   proper interface to the menagerie, but I don't think anything really
   came
   of it. What protocol are you interested in right now?
  
  There is no particular protocol I am interested at, it was an idea to
  improve
  regression testing. Right now I am looking at all dissectors below TCP (or
  on
  top, depending on how you look at it).
  
  
  By the way, could I get delete permissions for attachments for the
  SampleCaptures page on the wiki?
 
 I think Gerald has to grant this.

Gerald, could I get delete privileges for the captures on the SampleCaptures 
page?

  There are a bunch of duplicates (and even
  some empty files) listed as attachment and not linked. Some are not even
  captures files although their extension suggest so.
  
  Empty files:
  mount-de.pcap.gz
  omron-test-csum.pcap
  wireshark.org.pcap.gz
  
  Not pcap (but tcpdump text output or even a media file):
  packetout.pcap
  RTSP.pcap
  
  Duplicates can be found with:
  md5sum * | sort | uniq -w32 -D | while read sum file; do echo $sum $(date
  +%Y-%m-%d %H:%M -r $file) $(du -hD $file); done
  
  Are there known efforts to index the files? I don't think that the wiki is
  a
  sustainable way to collect them?
 
 No efforts I know of, but I agree the current method isn't scaling.
 
 The script I mentioned to get the list of protocols in one (or more)
 capture files is in git as ./tools/list_protos_in_cap.sh. Pipe it to a text
 file and then grep for the protocols you're looking for.

Thanks for the pointers, maybe it is already sufficient for my purposes of 
validation.

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

Re: [Wireshark-dev] Backport to 1.1 Change in wireshark[master-1.12]: ssl: add SslSession structure

[Peter Wu]

(Alexis, no need to cc me on my gmail, Google has already enough data ;))

On Thursday 03 July 2014 18:26:29 Graham Bloice wrote:
 On 3 July 2014 18:20, Alexis La Goutte alexis.lagou...@gmail.com wrote:
  Hi,
  
  I'm OK to backport this serie of patch to 1.12
  
  Other core ?
  
  I want also try to also add to backport 1.12 change about HTTP2
  (include nghttp2 lib)
 
 I wouldn't like to backport nghttp2 until we get the build for that cleaned
 up.  I have the change for that ready to go, just awaiting your updates to
 the library itself.  Doesn't git cope with moves though, so you should be
 OK if I make my change first?  The only thing I haven't checked is dist
 building stuff, in case that needs to know the files have moved.

git works fine for this, make a separate branch for your changes. Commit
often (with meaningful changes, try to avoid introducing huge changes over the 
same code), then rebase periodically against the latest master. The advantage 
of separate commits is that it makes handling merge conflicts (if any) easier 
as you only have to look at a single commit instead of a huge diff.

So, any problems with merging the ssl changes? Could I get some +1 so it can 
be merged? (all changes are backports which were reviewed before if it wasn't 
already clear).

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

[Wireshark-dev] Should dissect_tcp_pdus be used as much as possible?

[Peter Wu]

Hi,

Should reassembly be enabled in as many TCP protocols as possible? That
is, is it desirable that TCP-based protocols use dissect_tcp_pdus with
reassembly set to true?

I am asking because I was fixing an error in the return value of the
Plan 9 dissector[1]. While at it, I converted it to use
dissect_tcp_pdus as that was trivial. I have not seen a fragmented 9p
capture though.

Kind regards,
Peter
https://lekensteyn.nl

 [1]: https://code.wireshark.org/review/2836/

___
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] Backport request for proto_tree_add_subtree[_format]

[Peter Wu]

Hi all,

I would like to have the proto_tree_add_subtree and 
proto_tree_add_subtree_format functions backported to master-1.12. Any objects 
to that? It is only a new addition to the API, so it should be pretty safe.

It should make backporting changes easier. (read: backport a refactoring (WIP) 
to reduce code duplication in the SSL and DTLS dissectors.)

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

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

[Peter Wu]

On Thursday 10 July 2014 23:54:59 mman...@netscape.net wrote:
 The proto_tree_add_subtree[_format] code refactoring was very intentionally
 post-1.12 and I don't see much point to just having the API there without
 it.  Further refactoring of specific dissectors like SSL and DTLS probably
 won't be backported either, but if it is breaking a proto_tree_add_subtree
 back into its original proto_tree_add_text + proto_item_add_subtree doesn't
 seem that hard to do.

Ok, it turns out that I did not need it. proto_tree_add_none_format needs a hf 
which proto_tree_add_text does not have. Is the plan to eventually replace 
these as well, or just leave it as-is?

 -Original Message-
 From: Guy Harris g...@alum.mit.edu
[..]
 If the refactoring merely cleans up working code, producing code that
 doesn't appear different to the end user (old code dissects as well as new
 code, crashes no more than new code, etc.), it's probably not worth
 backporting it.
 
 If the refactoring fixes bugs, or makes it easier to fix existing bugs, that
 might make it worth backporting.

Reached the 3k changeset milestone!
https://code.wireshark.org/review/2999/
https://code.wireshark.org/review/3000/

The previous patch is needed for patch 3k to apply correctly. The last patch 
also fixes garbage in the display of Certificate in DTLS for the provided 
capture, but I guess that it can get even worse when a handshake message is 
fragmented.

Kind regards,
Peter
https://lekensteyn.nl

___
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] Bug in expert_add_info_format with a NULL pi parameter

[Peter Wu]

Hi,

While working on refactoring the SSL dissector[1], I noticed that
expert_add_info_format(pinfo, NULL, ...) does not add an expert item to the
tree view. In the case of the SSL dissector, the NULL should be replaced by 
the proto item to which the message is related, but with pi = NULL, an item 
should still be added somewhere, right? See attached capture. It should add
an expert warning with Cipher suite length (1) must be a multiple of 2.
Note that in the current implementation, a text label is also added.

This is probably a bug, but the documentation says this:

/** Add an expert info.
 Add an expert info tree to a protocol item, using registered expert info 
item,
 but with a formatted message.
 @param pinfo Packet info of the currently processed packet. May be NULL if
pi is supplied
 @param pi Current protocol item (or NULL)
 @param eiindex The registered expert info item
 @param format Printf-style format string for additional arguments
 */
WS_DLL_PUBLIC void
expert_add_info_format(packet_info *pinfo, proto_item *pi, expert_field 
*eiindex,
const char *format, ...) G_GNUC_PRINTF(4, 5);


I have confirmed (via a gdb breakpoint) that pinfo is never NULL. Any idea
what is going on here?

Kind regards,
Peter
https://lekensteyn.nl

 [1]: https://code.wireshark.org/review/3021/

bad.pcapng
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] Bug in expert_add_info_format with a NULL pi parameter

[Peter Wu]

On Saturday 19 July 2014 00:33:26 Peter Wu wrote:
 Hi,
 
 While working on refactoring the SSL dissector[1], I noticed that
 expert_add_info_format(pinfo, NULL, ...) does not add an expert item to the
 tree view. In the case of the SSL dissector, the NULL should be replaced by
 the proto item to which the message is related, but with pi = NULL, an item
 should still be added somewhere, right? See attached capture. It should add
 an expert warning with Cipher suite length (1) must be a multiple of 2.
 Note that in the current implementation, a text label is also added.
 
 This is probably a bug, but the documentation says this:
 
 /** Add an expert info.
  Add an expert info tree to a protocol item, using registered expert info
 item,
  but with a formatted message.
  @param pinfo Packet info of the currently processed packet. May be NULL if
 pi is supplied
  @param pi Current protocol item (or NULL)
  @param eiindex The registered expert info item
  @param format Printf-style format string for additional arguments
  */
 WS_DLL_PUBLIC void
 expert_add_info_format(packet_info *pinfo, proto_item *pi, expert_field
 *eiindex,
   const char *format, ...) G_GNUC_PRINTF(4, 5);
 
 
 I have confirmed (via a gdb breakpoint) that pinfo is never NULL. Any idea
 what is going on here?

Upon further investigation, it seems to be a bug in the SSL dissector. With a 
NULL pi, the expert item is not added to the tree view (which is fine). But 
due to a bug, it is also not available in the expert info overview.

By removing the `if (tree || ssl)` from ssl_dissect_hnd_hello_common and 
ssl_dissect_hnd_cli_hello (after applying patch up to change 3021), the expert 
info is displayed again (because the offset is calculated correctly), but only 
when Restrict to display filter is enabled. When that checkbox is not 
checked, the expert item still disappears.

In dissect_ssl3_record, dissection of the individual messages is skipped if 
the tree is not available:

  1915 /* PAOLO: if we are doing ssl decryption we must dissect some 
requests type */
  1916 if (ssl_hand_tree || ssl)

By adding '|| 1` here, the expert info is always added, as expected. I can 
imagine the overhead of decryption, but this will break all expert info fields 
in WS operating in the record layer. For now I will remove the `if 
(ssl_hand_tree || tree)` optimization I think.

Peter

 Kind regards,
 Peter
 https://lekensteyn.nl
 
  [1]: https://code.wireshark.org/review/3021/

-- 
Kind regards,
Peter
https://lekensteyn.nl
___
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] Help Regarding AIRPDCAP_DEBUG_PRINT_LINE

[Peter Wu]

On Wednesday 30 July 2014 17:11:30 Ashok Kumar wrote:
 I am interested in getting prints AIRPDCAP_DEBUG_PRINT_LINE.
 Can anyone help me in enabling this prints and where we can see this print
 outputs.

$ grep -rwn AIRPDCAP_DEBUG_PRINT_LINE .
...
epan/crypt/airpdcap_debug.h:44:#define  AIRPDCAP_DEBUG_PRINT_LINE(...
...


#ifdef  _DEBUG
#ifdef  __FUNCTION__
#define AIRPDCAP_DEBUG_PRINT_LINE(notdefined, msg, level) 
print_debug_line(__FUNCTION__, msg, level);
#else
#define AIRPDCAP_DEBUG_PRINT_LINE(function, msg, level) 
print_debug_line(function, msg, level);
#endif
#else
...
#endif

So, you need to add -D_DEBUG to your CFLAGS (or just add a #define _DEBUG line 
to that header).

 is it possible to any other kinds of prints to airpdcap files and use it
 for debugging.

Kind regards,
Peter
https://lekensteyn.nl
___
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-announce] Wireshark 1.12.0rc3 is now available

[Peter Wu]

On Wednesday 30 July 2014 14:35:06 Gerald Combs wrote:
 After comparing the tarballs generated by make dist and
 git-export-release.sh I have to agree. Both have issues but the dist
 tarball will build according to our documentation on Linux, Windows, and
 OS X.
 
 make dist is missing:
   - Quite a bit under asn1. asn1/*/CMakeLists.txt, gnm, gprscdr,
 and other assorted files.
   - Several CMake modules
   - Many files under debian
   - Many docbook files
   - Several READMEs in doc
   - Many files in plugins
   - Most (all?) files in tools
 
 git-export-release.sh is missing:
   - ./configure, install-sh, other Autotoolery
   - Files generated using Bison/Flex
   - help/faq.txt
   - packaging/macosx/Info.plist
   - plugins/*/plugin.c
   - ui/*/*shark-tap-register.c
 
 It looks like you can't build from a dist tarball using CMake which is
 something we should fix.

Instead of relying on autotools to generate the distribution tarball, one 
could also (temporarily) add all generated files to git and use git to build 
the tarball.

Something like this (ensure that you have no other files in your git tree!):

git clean -xfd # Ensure clean working dir (destructive!)
./autogen.sh
./configure
find -name Makefile* -print0 | xargs -0 git add -f
git add ... configure, config.status, bison, flex, etc...
git commit -q -m Release
git archive --prefix=... HEAD | xz -9  tar.gz
git reset --hard HEAD~ # Return to previous version

Another thing to consider is the availability of cmake which does not require 
additional files in a distribution tarball like autotools. If all platforms 
support cmake, what about dropping the autotools-generated stuff?

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

Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on running from the build directory.

[Peter Wu]

On Thursday 31 July 2014 17:11:59 Evan Huus wrote:
 This issue has been bugging me for a while, but I also haven't been able to
 come up with a satisfactory solution.

Oh my, that filesystem.c code is really ugly and relying on a lot of 
assumptions. Why does it need to distinguish build dirs from other dirs in the 
first place? From the comments, it seems to that for security/stability 
reasons, and another reason is to make plugins get loaded from the build dir.

What about solely relying on envvars? Then there can be a shell-script if you 
like the wrapper provided by libtool:

#!/bin/bash
# tools/run.sh - Wrapper for binaries
# since Mac does not have `readlink -f`, this is an alternative:
rundir=$(cd $(dirname $0)  pwd)
#rundir=$(dirname $(readlink -f $0))
export WIRESHARK_DATA_DIR=$rundir
export WIRESHARK_PLUGIN_DIR=$rundir
#etc.
exec $rundir/${0##*/} $@

With links:
tmpbin/tshark - ../tools/run.sh
tmpbin/wireshark - ../tools/run.sh
etc.

(no need to set LD_LIBRARY_PATH as RPATH is set by cmake for the in-tree 
binaries)

Kind regards,
Peter

 On Thu, Jul 31, 2014 at 4:56 PM, Wireshark code review 
 
 code-review-do-not-re...@wireshark.org wrote:
  URL:
  https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=43a81b
  61395358d93a3f859e9058dfd7ecc39a7e Submitter: Guy Harris
  (g...@alum.mit.edu)
  Changed: branch: master
  Repository: wireshark
  
  Commits:
  
  43a81b6 by Guy Harris (g...@alum.mit.edu):
  Add some information on running from the build directory.
  
  Change-Id: I6c01141cd02af358152d007175ec0b51357e42b3
  Reviewed-on: https://code.wireshark.org/review/3298
  Reviewed-by: Guy Harris g...@alum.mit.edu
  
  Actions performed:
  from  9505d3a   Need to make Windows installer packages as well.
  adds  43a81b6   Add some information on running from the build
  
  directory.
  
  Summary of changes:
   README.cmake |   18 +-
   1 file changed, 17 insertions(+), 1 deletion(-)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on running from the build directory.

[Peter Wu]

On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
 On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl wrote:
[..] 
  Oh my, that filesystem.c code is really ugly and relying on a lot of
  assumptions. Why does it need to distinguish build dirs from other dirs in
  the first place?
 
 So that you can just type ./wireshark or ./tshark after you've done a
 build, and have it Just Work, rather than having to install Wireshark or
 TShark before you can run it.  Note that we run TShark to generate some man
 pages.

The binaries themselves already Just Work(tm) without libtool because CMake 
sets RPATH. (If it still tries to search for globally installed WS, note that 
there existed a bug in CMake 2.8[1] that set the wrong RPATH when linked 
against libraries in `/lib64`. That got fixed in CMake 3.0)

 [1]: http://www.cmake.org/Bug/view.php?id=14875

  From the comments, it seems to that for security/stability
  reasons,
 
 From one of the comments:
 
 /*
  * Check whether WIRESHARK_RUN_FROM_BUILD_DIRECTORY is set in the
  * environment; if so, set running_in_build_directory_flag if we
  * weren't started with special privileges.  (If we were started
  * with special privileges, it's not safe to allow the user to point
  * us to some other directory; running_in_build_directory_flag, when
  * set, causes us to look for plugins and the like in the build
  * directory.)
  */
 
 So the code that sets the running from the build directory flag takes into
 account security issues, but it doesn't *exist* for security reasons.
 
 On the other hand, from doc/README.packaging:
 
   WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN 
 THEM
 AS ROOT.

That was indeed the reason for comments on security reasons, together with 
ignoring plugins from the env vars. Fun fact: currently there are over 3.5M 
lines of code (only counting *.h and *.c, surely I missed some cpp and py 
files). I would like to get rid of the WIRESHARK_RUN_FROM_BUILD_DIRECTORY if 
possible, not treating it specially and instead rely on environment variables 
to configure stuff.

  and another reason is to make plugins get loaded from the build dir.
 
 Not just plugins, but also global configuration files, etc..

Currently the configuration cannot be overridden when ran from the confdir, 
but that seems to be a useless restriction. Setting WIRESHARK_DATA_DIR should 
work without surprises (this behavior is not even documented, only root/setuid 
should have this special behavior).

  What about solely relying on envvars?
 
 Sure, as long as the user doesn't have to do anything to set the environment
 variable.  Otherwise, it doesn't Just Work.
  Then there can be a shell-script if you
  like the wrapper provided by libtool:
  
  #!/bin/bash
  # tools/run.sh - Wrapper for binaries
 
  # since Mac does not have `readlink -f`, this is an alternative:
 Neither do older versions of other BSD-flavored OSes.  I guess Apple just
 haven't updated readlink in a while.

Apple has a greadlink (GNU readlink), but I don't think that is installed by 
default either. Actually, since `$0` is expected to be a symlink, it should be 
fine to use just `readlink $0`, and exit in other cases (printing a help 
message instead?).

  rundir=$(cd $(dirname $0)  pwd)
  #rundir=$(dirname $(readlink -f $0))
  export WIRESHARK_DATA_DIR=$rundir
  export WIRESHARK_PLUGIN_DIR=$rundir
  #etc.
  exec $rundir/${0##*/} $@
  
  With links:
  tmpbin/tshark - ../tools/run.sh
  tmpbin/wireshark - ../tools/run.sh
  etc.
 
 So tmpbin is the top-level source directory, so running ./tshark,
 ./wireshark, etc. from the top-level CMake build directory would be
 sufficient?

The object (output) directory. For top-level directories, the symlink would 
appear as `./tshark - tools/run.sh` (assuming that run.sh is copied over). If 
this approach is taken, an option must be added to support the use of GDB / 
valgrind.

Kind regards,
Peter
https://lekensteyn.nl

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

Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on running from the build directory.

[Peter Wu]

On Thursday 31 July 2014 20:04:52 Evan Huus wrote:
 FWIW this issue also makes it impossible to run parts of the test suite
 from an out-of-tree build, which can be problematic.

Which part exactly? I can run most of the test-suite with an OOT build using:

WS_BIN_PATH=/tmp/wsbuild/run ./test.sh -s $suite

Some things fail for me, but that seems unrelated to the build dir:

clopts testing because unprivileged users still have a dbus capture interface)
2.4.1 Step: Invalid permissions for dumpcap parameter -D, exit status must be 
2   
   
Invalid permissions for dumpcap parameter -D, exit status must be 2 Failed!   

 
exit status: 0  

 
./testout.txt:1. dbus-system
./testout.txt:2. dbus-session


1.1 Step: Name resolution, no external, no profile hosts, global profile

 
Name resolution, no external, no profile hosts, global profile Failed!

 
Failed to resolve 8.8.8.8 using global hosts file.  

 

This fails because the hosts file is copied to /tmp/wsbuild/run/, but 
Wireshark is looking in the source directory:
open(/tmp/wireshark/hosts, O_RDONLY)  = -1 ENOENT (No such file or 
directory)



LUA?
 Testing Dir.open  
tshark: Lua: Error during loading:
 [string /home/peter/projects/wireshark/test/lua/dir.l...]:130: attempt to 
call global 'typeof' (a nil value)
test Dir.open-31...passed
test Dir.open-32...passed

wslua dir Failed!
didn't find pass marker
./temp/file3.txt:fooobarrloo
./temp/file2.txt:fooobarrloo
./temp/file1.txt:fooobarrloo


Kind regards,
Peter
https://lekensteyn.nl
___
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] Changes to packet-erf dissector

[Peter Wu]

On Thursday 14 August 2014 15:59:41 Wasim Abu Moch wrote:
 My name is Wasim and I'm a SW engineer at Mellanox Technologies.  As I
 understood from my old boss that in order to do some changes to ERF dissector
 I should contact/consult Stephen Donnelly from Endace (Emulex now), my
 question is: Is he still involved? What's his mail? Do I have to get his
 approval or can I just push for review.

Stephen seems still active judging from his replies on this bug[1]. You probably
do not need to contact him if you need to make changes, just push for review if
you have your changes ready. Then add him as reviewer in Gerrit so he can check
your changes.

Kind regards,
Peter
https://lekensteyn.nl

 [1]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10300

___
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] help with pushing to Gerrit

[Peter Wu]

On Sunday 17 August 2014 09:31:16 Wasim Abu Moch wrote:
 Can anyone tell how I can push my changes for review, the documentation on the
 website says:
 
 $ git push ssh://my.usern...@code.wireshark.org:29418/wireshark 
 HEAD:refs/for/master/snowcone-machine

 But I don't know which username to use.

This is the username you entered when registering in Gerrit. See
http://wiki.wireshark.org/Development/SubmittingPatches

-- 
Kind regards,
Peter
https://lekensteyn.nl

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

Re: [Wireshark-dev] Building Wireshark on MAC

[Peter Wu]

On Tuesday 30 September 2014 21:36:33 Anders Broman wrote:
 Ok that was helpful, unfortunately the result is:
 
 -- The following OPTIONAL packages have not been found:
 
 
  * CAP
 
  * GTK3
 
  * Qt5LinguistTools
 
  * Qt5MacExtras
 
  * Qt5PrintSupport
 
  * Qt5Widgets
 
  * SBC , SBC Codec for Bluetooth A2DP stream playing , www:
 http://git.kernel.org/cgit/bluetooth/sbc.git
 
  * SETCAP
 
  * YAPP
 
 Any ideas why it does not find any GUI toolkit?

Where is the installation of GTK3 or Qt? If you have installed Qt4, try
-DENABLE_QT5=0 for a fallback.

 Regards
 Anders
 
 2014-09-30 9:56 GMT+02:00 Peter Wu pe...@lekensteyn.nl:
 
  On Monday 29 September 2014 21:09:22 Anders Broman wrote:
   Well for a cmake newbie it would help with an example of which parameters
   to use...
 
  Typically you have a build directory separate from your code. Minimal
  example:
 
  mkdir build  cd build
  cmake $path_to_srcdir
  make
  # Build artifacts are now in run/
 
  Options can be added with -DVAR=VAL, for example: -DENABLE_QT5=0 (to
  disable
  Qt5), -DCMAKE_BUILD_TYPE=Debug (defaults to RelWithDebInfo).
 
  Alternatively you can use cmake-gui:
 
  mkdir build  cd build
  cmake-gui $path_to_srcdir
  # Press Configure, select stuff, press Generate
  make
 
  --
  Kind regards,
  Peter
  https://lekensteyn.nl

___
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] CapturePrivileges not working

[Peter Wu]

On Monday 13 October 2014 11:07:43 Roland Knall wrote:
 No, it's a cmake out-of-tree build. There simply does not seem to be a way
 to set dumpcap correctly. Fun part is, that even dumpcap is set suid, it
 still does not bring any output run by my user with dumpcap -D.

Well, if the owner of dumpcap is not root, then the suid bit won't make you
root.

 Only sudo dumpcap -D lists any interfaces.

`sudo ./dumpcap -D` I guess?

 With ldd the only library used is wsutil (which should not be an issue), and
 there are no residual .lib/lt-* files lying around. But I have also built it
 now with autotools (just to ensure that it is not a cmake-related issue), and
 still it does not work:
 
 $ getcap dumpcap .libs/lt-dumpcap
 dumpcap = cap_net_admin,cap_net_raw+eip
 .libs/lt-dumpcap = cap_net_admin,cap_net_raw+eip
 $ ls -l dumpcap .libs/lt-dumpcap
 -rwxr-xr-x 1 knallr knallr   9120 Okt 13 11:02 dumpcap
 -rwxr-xr-x 1 knallr knallr 279816 Okt 13 11:03 .libs/lt-dumpcap
 $ ./dumpcap -D
 dumpcap: There are no interfaces on which a capture can be done

I think this should work as lt-dumocao has the right capabilities. What
filesystem is this on? tmpfs does not support filesystem capabilities.

What I generally do when I need to capture something is using the global dumpcap
binary which has the right capabilities. Run the following from the cmake build
dir to replace the built dumpcap with the globally installed dumpcap:

ln -svf /usr/bin/dumpcap run/dumpcap

-- 
Kind regards,
Peter
https://lekensteyn.nl

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

[Wireshark-dev] Gerrit StartSSL OpenID provider

[Peter Wu]

Hi,

Has anyone tried to link a StartSSL identity in Gerrit? I just tried to do so,
but get a 401 Unauthorized back in Gerrit.

Although not available in the UI, you can chose your own OpenID provider by
hitting one of the provider buttons (e.g. StartSSL), then cancel by hitting Esc
(Stop). Use Firebug to disable the submit event on the form and edit the hidden
form, then submit.

In my case, I chose for https://lekensteyn.startssl.com/ but now I have another
Anonymous Coward account which is not linked to my main identity.

Any suggestions to remove the Anonymous Coward account, and properly link my
StartSSL identity to Gerrit?
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] QT with cmake

[Peter Wu]

On Tuesday 21 October 2014 11:20:54 Dario Lombardo wrote:
 I tried to compile the master of wireshark using cmake.
 
 mkdir build
 cd build
 cmake ..
 make
 
 In run/ I can find wireshark-gtk but not qt. Any specific command to pass
 to cmake to have it? I am able to obtain qt executable using autotools
 (meaning that my qt dev subsystem should be fine).

If I am not mistaken, the CMake build defaults to Qt5 by default. To use Qt4
instead, pass the option -DENABLE_QT5=0. Otherwise, install the qt5-tools
package which should provide the packages which are reported missing during
cmake.

Have you checked the cmake output already?

-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] QT with cmake

[Peter Wu]

On Tuesday 21 October 2014 13:12:18 Dario Lombardo wrote:
 Well... after installing some other qt5 packages I get
 
 CMake Error at ui/qt/CMakeLists.txt:306 (QT5_ADD_TRANSLATION):
   Unknown CMake command QT5_ADD_TRANSLATION.

On Arch Linux, the package qt5-tools provides the following file which defines
that function:
/usr/lib/cmake/Qt5LinguistTools/Qt5LinguistToolsMacros.cmake

What distro are you using? For Debian/Ubuntu you need to install qttools5-dev.

Kind regards,
Peter

___
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] QT with cmake

[Peter Wu]

On Tuesday 21 October 2014 14:11:25 Dario Lombardo wrote:
 On Tue, Oct 21, 2014 at 1:20 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
 
  What distro are you using? For Debian/Ubuntu you need to install
  qttools5-dev.
 
 
 It is exactly what I'm using (ubuntu 14.04). I've installed  qttools5-dev
 and compilation made few steps ahead, but then stopped with
 
 Scanning dependencies of target qtui
 [ 79%] Building CXX object ui/qt/CMakeFiles/qtui.dir/about_dialog.cpp.o
 In file included from
 /home/dario/Projects/wireshark/ui/qt/about_dialog.cpp:25:0:
 /home/dario/Projects/wireshark/ui/qt/ui_about_dialog.h:13:25: fatal error:
 QtGui/QAction: No such file or directory
  #include QtGui/QAction
  ^
 compilation terminated.
 make[2]: *** [ui/qt/CMakeFiles/qtui.dir/about_dialog.cpp.o] Error 1
 make[1]: *** [ui/qt/CMakeFiles/qtui.dir/all] Error 2
 make: *** [all] Error 2

Have you tried to clear your build dir? The QtGui/QAction file is located in the
qt4 include directory, in qt5 it is located at QtWidgets/QAction.

-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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 dissector development - Reassembly tcp frames

[Peter Wu]

On Tuesday 04 November 2014 11:48:03 Guillaume Ribière wrote:
 I read the readme.dissector and try using two methods:
 
First method:
 
tcp_dissect_pdus(tvb, pinfo, tree, dns_desegment, 2,
get_dns_pdu_len, dissect_dns_tcp_pdu, data);
return tvb_captured_length(tvb);

You would use this when your protocol has a well-defined packet message format
where the length of a packet can be determined from the beginning of a message.
Example: SSL has a record length notion. IIRC this will call dns_desegment
multiple times if a packet contains multiple PDUs (messages).

Second method :
 
guint offset = 0;
while(offset  tvb_reported_length(tvb)) {
gint available = tvb_reported_length_remaining(tvb, offset);
gint len = tvb_strnlen(tvb, offset, available);
 
if( -1 == len ) {
/* we ran out of data: ask for more */
pinfo-desegment_offset = offset;
pinfo-desegment_len = DESEGMENT_ONE_MORE_SEGMENT;
return (offset + available);
}
 
[..]
offset += (guint)len;
}
 
/* if we get here, then the end of the tvb coincided with the end of a
   string. Happy days. */
return tvb_captured_length(tvb);

This can be used if you do not know the length of the data onbeforehand. In the
above example, the a C string is NUL-terminated and you cannot know the full
length until you have read everything.

 But impossible to reassemble the message, I do not understand why ... can
 you help me please? I hope you understand my problem ...: /

What issue are you encountering? Be very careful not to return 0 from a
dissector as it means I do not know this data, pass it to a different
dissector. If you set desegment_len to a fixed positive value other than
DESEGMENT_ONE_MORE_SEGMENT, then you won't be able to change the segment length
later.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] On which platforms is there a need for Wireshark to have a Language preference?

[Peter Wu]

On Monday 24 November 2014 23:45:11 Andreas Sikkema wrote:
 Here's an example, a forum that I use quite frequently. When I set
 Firefox to Dutch, The links for Login and Registration get translated to
 Aanmelden and Registreren. In my mind, Aanmelden and Registreren both
 mean Registration. So now I am confsed, which of the links should I
 follow to login?

In dit specifieke geval is het misschien handig om aanmelden als iets
korts te zien (loop langs de receptie, zeg even gedag) en registratie
als iets uitgebreiders (geef je naam en andere gegevens op).

Iets wat misschien vaker voorkomt is dat je een taal pakt wat anderen
ook gebruiken om makkelijker logboeken te kunnen lezen, of om
makkelijker jouw foutmeldingen door te kunnen geven.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] On which platforms is there a need for Wireshark to have a Language preference?

[Peter Wu]

*sigh* this was supposed to be off-list.

On Tuesday 25 November 2014 00:36:13 Peter Wu wrote:
 On Monday 24 November 2014 23:45:11 Andreas Sikkema wrote:
  Here's an example, a forum that I use quite frequently. When I set
  Firefox to Dutch, The links for Login and Registration get translated to
  Aanmelden and Registreren. In my mind, Aanmelden and Registreren both
  mean Registration. So now I am confsed, which of the links should I
  follow to login?
 
 In dit specifieke geval is het misschien handig om aanmelden als iets
 korts te zien (loop langs de receptie, zeg even gedag) en registratie
 als iets uitgebreiders (geef je naam en andere gegevens op).
 
 Iets wat misschien vaker voorkomt is dat je een taal pakt wat anderen
 ook gebruiken om makkelijker logboeken te kunnen lezen, of om
 makkelijker jouw foutmeldingen door te kunnen geven.

___
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] Petri Dish update

[Peter Wu]

On Tuesday 25 November 2014 23:37:26 Pascal Quantin wrote:
 2014-11-25 18:59 GMT+01:00 Alexis La Goutte alexis.lagou...@gmail.com:
  For information,
  I have add the check of last commit
  the Ubuntu Petri Dish buildbot launch a ./tools/pre-commit HEAD^1
  (launch check[APIs|hf|filenames] on tested commit)
 
  It is possible to have same false postive warnings errors

 unfortunately (as expected) it can trigger some false positives making
 Petri Dish fail (like for example
 http://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20x86-64%20Petri%20Dish/builds/813/steps/Pre-commit%20check/logs/stdio
 even if this one could be questionable). I know that the script can choke
 on some ASN.1 auto generated dissectors. Maybe we are not ready for this
 yet...

Is it possible to make the buildbot add a Code-Review -1 instead of
setting the Verified flag for pre-commit failures?
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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 dialog, monitor changed callback (bug 10685)

[Peter Wu]

Hi,

I came across a duplicated piece of code by grepping for the string DLT
n which I originally found in ui/gtk/capture_dlg.c. Two questions:

 - Can somebody reduce the duplication (two occurrences in
   ui/gtk/capture_dlg.c, one in ui/qt/manage_interfaces_dialog.cpp)?
 - Why is the callback for capture_prep_monitor_changed_cb so huge?

There is a crash in certain circumstances, and
capture_prep_monitor_changed_cb is involved:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10685

cc'ing Michael Tüxen as he extended capture_prep_monitor_changed_cb in
commit eaffdfeaaa572bb818f116afb3c63b3d43c153ea
Date:   Fri Aug 5 07:19:17 2011 +

Add support for multiple interfaces to the capture options dialog.
Obtained from Irene Ruengeler.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] PSA: QString.toUtf8().constData() pattern is unsafe

[Peter Wu]

Hi all,

I mostly use Wireshark GTK, but just tried the Qt UI again. A recurring
problem was an ASAN crash on shutdown. It turns out that there are many
users of this pattern:

recent_add_cfilter(NULL, currentText().toUtf8().constData());

This is unsafe as currentText().toUtf8() returns a new instance of
QByteArray and constData() returns a pointer to data inside that object.
After returning, the data is destructed and a use-after-free condition
occurs.

The more correct way to do this is to use another variable to ensure
that a reference is held to that QByteArray:

QByteArray text_utf8 = currentText().toUtf8();
recent_add_cfilter(NULL, text_utf8.constData());

See also the commit message at https://code.wireshark.org/review/5528/
Please avoid this pattern in the future, and watch it during reviews.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] PSA: QString.toUtf8().constData() pattern is unsafe

[Peter Wu]

On Friday 28 November 2014 15:48:29 Evan Huus wrote:
 I'm a bit confused - wouldn't the new instance of QByteArray simply be
 leaked in the example code, as opposed to destructed? C++ doesn't have
 automatic garbage collection...

Why would it be leaked? There is a new QByteArray instance text_utf8
that stays allocated until the scope is left, then its distructor is
called.

Maybe you are confused with the new keyword which would require you to
add delete to destruct an object?

Peter

 On Fri, Nov 28, 2014 at 2:13 PM, Peter Wu pe...@lekensteyn.nl wrote:
  Hi all,
 
  I mostly use Wireshark GTK, but just tried the Qt UI again. A recurring
  problem was an ASAN crash on shutdown. It turns out that there are many
  users of this pattern:
 
  recent_add_cfilter(NULL, currentText().toUtf8().constData());
 
  This is unsafe as currentText().toUtf8() returns a new instance of
  QByteArray and constData() returns a pointer to data inside that object.
  After returning, the data is destructed and a use-after-free condition
  occurs.
 
  The more correct way to do this is to use another variable to ensure
  that a reference is held to that QByteArray:
 
  QByteArray text_utf8 = currentText().toUtf8();
  recent_add_cfilter(NULL, text_utf8.constData());
 
  See also the commit message at https://code.wireshark.org/review/5528/
  Please avoid this pattern in the future, and watch it during reviews.
  --
  Kind regards,
  Peter
  https://lekensteyn.nl

___
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] PSA: QString.toUtf8().constData() pattern is unsafe

[Peter Wu]

On Saturday 29 November 2014 00:38:34 John Sullivan wrote:
 On Friday, November 28, 2014, 7:13:26 PM, Peter Wu wrote:
  Hi all,
 
  I mostly use Wireshark GTK, but just tried the Qt UI again. A recurring
  problem was an ASAN crash on shutdown. It turns out that there are many
  users of this pattern:
 
  recent_add_cfilter(NULL, currentText().toUtf8().constData());
 
  This is unsafe as currentText().toUtf8() returns a new instance of
  QByteArray and constData() returns a pointer to data inside that object.
  After returning, the data is destructed and a use-after-free condition
  occurs.
 
  The more correct way to do this is to use another variable to ensure
  that a reference is held to that QByteArray:
 
  QByteArray text_utf8 = currentText().toUtf8();
  recent_add_cfilter(NULL, text_utf8.constData());
 
 This is not necessarily a problem with the calling code, and (without
 having personally actually checked either the calling or the called
 code) may not be solvable with just that change.
 
 The temporary is guaranteed to live until the end of the full
 expression.
 
 Which means that during the execution of recent_add_cfilter, the
 pointer is guaranteed to be valid.

Ah cool, I did not know this. I assumed that the pointer became invalid
after the (sub)expression is evaluated rather than after the statement.

 What isn't valid is assuming that same pointer is valid after that
 point. The terminating semicolon. So if recent_add_cfilter implies
 that the data will be needed after the point at which
 recent_add_cfilter returns, it must either copy the data, or if the
 data is reference counted/countable, add a reference to it.

This is exactly what I encountered, and due to the previous assumption I
made, I extended it to other uses of the pattern (including the provided
example).

What actually crashed was the code that saves Recent files (because it
stores a pointer to a const char*), and a UAT change handler
(Preferences - Protocols - SSL - Edit RSA keys, Add and try to type
something -- instant ASAN crash).

 (A const assigned to a temporary will keep the temporary alive to the
 end of the scope of the const, so in any case it is a good idea in
 these cases to make the local a const type. If the called function
 returns a real object, it'll go in to a temporary and be no different.
 If it returns a  to an existing object, then the call*ing* code
 doesn't need to make a whole new copy of the full object and is
 therefore much more efficient.)

(Thanks for explaining, I haven't touched my C++ book for a long time)

 Neither is it fantastic to re-malloc an object when not really
 required. If the actual lifetime is much longer then re-allocation is
 fine, but if it is genuinely locally scoped then a better solution is
 to refactor any called functions within that scope so they all take
 references to the operated on object, then it becomes physically
 impossible to call them without still having a live object of the
 appropriate type.

All users do not modify the char pointer, and if they needed to store
them, they do duplicate the memory.

I will amend the patch. Thanks again for clarifying C++ behavior!
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] TCP reassembly and Return value of a new-style dissector

[Peter Wu]

On Tuesday 09 December 2014 21:01:37 Anders Broman wrote:
 Hi,
 I have recently come across some problems with reassembly of SIP 
 messages over TCP. One problem seems to be related to when a segment 
 contains one full PDU and a segment of the next (following) PDU (in
 this case the first SIP line of the following PDU) is not complete.

(added punctuation for easier reading)

HTTP does not seem to have problems with it, probably because it tries
to consume as much of a PDU as possible, saving incomplete data for
later desegmentation. See the attached crafted packet for example which
contains three HTTP responses:

 1. PDU 1 contains one full HTTP response and the begin of the next.
 2. PDU 2 contains all the remainder of the second HTTP response, minus
one last character.
 3. PDU 3 has the last character of the second request and the begin of
the third request .
 4. PDU 4 contains the remainder of the third HTTP request.

'HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\nContent-Length: 1\r\n\r\n1'
'HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n', 'Content-Length: 
2\r\n\r\n1', '2'
'HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\nC', 'ontent-Length: 
3\r\n\r\n123'

 I think the ultimate solution would be for the TCP dissector to call the 
 SIP dissector again with the next incomplete PDU
 after receiving the number of bytes accepted by the SIP dissector e.g 
 using the new-style dissector interface.
 also see http://seclists.org/wireshark/2014/Jun/289

It would indeed be nice if the dissector core could be improved to
handle this situation. As I mentioned before, the HTTP dissector has no
problems with this because it tries to dissect all data until more data
is needed.

This is from dissect_sip:

remaining_length = tvb_reported_length(tvb);
len = dissect_sip_common(tvb, 0, remaining_length, pinfo, tree, FALSE, 
FALSE);
if (len  0)
return 0;   /* not SIP */
else
return len;

dissect_http instead always returns tvb_captured_length (all data in
the PDU is part of the HTTP protocol) while returning 0 means I know
for sure that this is not SIP.

dissect_sip_common returns -1 meaning need more data, but then
dissect_sip return 0 meaning no, not SIP, try a different dissector!.

 As I read the code the first step would be to have
 call_dissector()[OK]
 try_conversation_dissector()
 dissector_try_heuristic()
 dissector_try_uint_new [OK]
 
 Return the number of bytes consumed, 0 or -1(need more data) not sure 
 about DESEGMENT_UNTIL_FIN (-2?).
 
 If people agree the biggest change is to change 
 dissector_try_heuristic() to return an int.
 What do you think?

I would not particularly mind changing the return value, but what should
be the new semantics of the return value? I found that documentation is
quite lacking here. When I tried to make the core to actual handle
return values[1], many dissectors broke because they were not written
with the documented behavior (see also the mail you linked before).

Here is a document I wrote back then to clarify it for myself
https://git.lekensteyn.nl/peter/wireshark-notes/tree/doc/dissector.txt
-- 
Kind regards,
Peter
https://lekensteyn.nl

 [1]: 
https://git.lekensteyn.nl/peter/wireshark/commit/?h=reassembly-fixesid=aef08cc2434b5ba5aee4422fbcf481004c62583a


http-fragmented-nonempty.pcapng.gz
Description: application/gzip
___
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] Getting involved with Wireshark (was: Re: What Wireshark base version to use for customization)

[Peter Wu]

Hi,

(This is kind of off-topic, start a new thread for such questions.)

On Wednesday 10 December 2014 15:29:03 pogiako wrote:
 I'm looking for something something to work on for my thesis. I'm a Free 
 Software guy and I thought of contributing to Wireshark is great idea. 
 I'm doing an exploratory project (Like to find something out or to prove 
 something), more on research. I don't code, I only know basic C. I have 
 the KR 2nd E. book, will that help? I have up to April or May for this.

KR is sufficient to learn the basics of the C language, but you can't
learn without actually practising.

I started contributing to Wireshark when I noticed that SSL decryption
was not working in one case. It turned out that some numbers were
missing, so I wrote my first Wireshark patch to solve that[1]. Moral of
the story: you do not really need deep Wireshark knowledge to write such
a patch and the best way to get involved is to fix an issue you
encounter while using Wireshark.

A good way to get acquainted with Wireshark is to write a dissector. See
doc/README.dissector (and doc/README.developer) for details. Once you
get more familiar, consider skimming the bug tracker
(https://bugs.wireshark.org/) for issues that can be fixed. Type in your
favorite protocol/feature (e.g. ssl, http or gtk) and try to find
out whether you can fix it or not. A good learning experience even if
you do not manage to fix the bug.
-- 
Kind regards,
Peter
https://lekensteyn.nl

 [1]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9144

___
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] nflog in qt and gtk

[Peter Wu]

On Friday 19 December 2014 11:08:01 Dario Lombardo wrote:
 On Thu, Dec 18, 2014 at 4:29 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
 
  You should not run Wireshark with sudo, instead set the appropriate
  privileges on the dumpcap binary as described at
  http://wiki.wireshark.org/CaptureSetup/CapturePrivileges
 
 
 Generally speaking, you are right, and it's waht I do with my stable
 wireshark. But with my development version, the setcapped binary is
 overwritten every time I recompile. So I use the master compiled version
 with sudo.

If I need to perform a capture, i just overwrite dumpcap with:
ln -sfv /usr/bin/dumpcap /tmp/wsbuild/run/

It looks like you also avoid overwriting this file/symlink by disabling
dumpcap building:

cmake -DBUILD_dumpcap=0 ...

   What did I do wrong?
 
  I have spend some minutes into debugging it and it turns out that you
  cannot have two open sockets for NFLOG.
 
  Reproducer:
  $ dumpcap -i nflog -w /dev/null
  Capturing on 'nflog'
  File: /dev/null
  (in a different shell)
  $ dumpcap -i nflog -w /dev/null
  Capturing on 'nflog'
  dumpcap: The capture session could not be initiated on interface 'nflog'
  (Can't listen on group group index: Operation not permitted).
  Please check to make sure you have sufficient permissions, and that you
  have the proper interface or pipe specified.
 
  The difference between GTK and Qt is that Qt additionally executes
  `dumpcap -S -Z none` which seems to open a socket for each available
  interface to collect stats.
 
  At this point I stopped debugging, hope it helps.
 
 
 If I've got the point, wireshark QT is not expected to work with nflog,
 right? If stats can't be stopped, it won't work.

Nope, it won't work at the moment. The problem is that NFLOG can only be
opened by one user which is a kernel limitation. From
net/netfilter/nfnetlink_log.c:

inst = instance_lookup_get(log, group_num);
if (inst  inst-peer_portid != NETLINK_CB(skb).portid) {
ret = -EPERM;
goto out_put;
}
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] nflog in qt and gtk

[Peter Wu]

On Friday 19 December 2014 11:55:47 Dario Lombardo wrote:
 On Fri, Dec 19, 2014 at 11:44 AM, Peter Wu pe...@lekensteyn.nl wrote:

  Nope, it won't work at the moment. The problem is that NFLOG can only be
  opened by one user which is a kernel limitation. From
  net/netfilter/nfnetlink_log.c:
 
  inst = instance_lookup_get(log, group_num);
  if (inst  inst-peer_portid != NETLINK_CB(skb).portid) {
  ret = -EPERM;
  goto out_put;
  }
 
 
 When wireshark-qt waits in the main screen, it shows a graph for each
 interface. Is it generated by dumpcap -S -Z none? When capture starts,
 those graphs are not shown anymore. Wouldn't be a solution to kill dumpcap
 -S -Z none when in capture and re-run it again when in home screen?

Kill statistics before starting the capture? Sounds fine to me, though I
am not sure whether it has other side-effects. The Capture - Options
dialog is another place where these stats are visible.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] nflog in qt and gtk

[Peter Wu]

On Friday 19 December 2014 17:07:20 Dario Lombardo wrote:
 On Fri, Dec 19, 2014 at 12:35 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
  The Capture - Options
  dialog is another place where these stats are visible.
 
 
 Is it visible during capture?

No, it is not visible during capture. The options menu item is also
disabled when a capture is active.
-- 
Kind regards,
Peter
https://lekensteyn.nl

___
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] Our Git URLs: https vs ssh

[Peter Wu]

Hi Stephen,

On Friday 02 January 2015 15:34:46 Stephen Fisher wrote:
 I've seen two URLs for getting Wireshark via Git:
 
   https://code.wireshark.org/review/wireshark
 
   and
 
   ssh://my.usern...@code.wireshark.org:29418/wireshark 
 
 
 The first one is mentioned in the developer's guide and elsewhere, while 
 the second is mentioned for using Gerrit to submit changes.  Since I 
 submit changes to Gerrit, I've always used the SSH URL even for the 
 initial pull (clone).  Can users use the HTTPS one initially and then 
 easily change to the SSH one if they decide to contribute?  I'm still 
 used to the SVN days where committers had to use the SSH URL to get into 
 the SVN repo and everyone else used the public URL.

You can change the remote with `git remote set-url`. SVN has only one
URL AFAIK, but git can configure a different one depending on the
direction:

$ git remote -v
origin  https://code.wireshark.org/review/wireshark (fetch)
origin  ssh://lekenst...@code.wireshark.org:29418/wireshark (push)

To change the fetch URL, you can use this command:

git remote set-url origin https://code.wireshark.org/review/wireshark

To set the push URL, use this instead:

git remote set-url --push origin ssh://...

Verify with `git remote -v`.

Now you can fetch changes without having to unlock your SSH key.

Kind regards,
Peter

___
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] Copying of filters from the filter tool bar with ctrl-c is broken

[Peter Wu]

On 02/04/2015 05:17 PM, Anders Broman wrote:
 Hi, Copying of filters from the filter tool bar with ctrl-c is
 broken, this commit is probably the culprit. 
 https://code.wireshark.org/review/#/c/5832/

Confirmed that modifiers are broken. Ctrl-A is also broken.

Thanks for the head-ups, I'll have a look at it after finishing the
STARTTLS patches.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl/
___
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] Two Descrypted SSL data sections in one frame

[Peter Wu]

On 02/08/2015 08:25 PM, Petr Gotthard wrote:
 I'm trying to add SSL support for the AMQP dissector. I managed to correctly 
 decrypt and reassemble the application data, however from some reason the SSL 
 dissector (or someone else?) split the application data in two blocks: the 
 first data block contains the first byte of the AMQP frame and the second 
 data block contains the remaining bytes.
  -- In the Packet Details section I can see (after the SSL sub-tree) a 
 sub-tree Data (1 byte) and below it another sub-tree [Malformed Packet: 
 AMQP] (the packet is malformed because it is missing the first byte)
  -- in the Packet Bytes section I can see two Decrypted SSL data 
 sections. One with 1 byte (the first byte of an AMQP frame) and the other 
 section with the remaining bytes of this AMQP frame.
  
 Do you have any idea why did SSL create two decrypted SSL data sections and 
 split the frame?

This sounds like the 1/n-1 split done to workaround the BEAST attack[1].

If you need more bytes, set pinfo-desegment_len (and maybe
pinfo-desegment_offset). See doc/README.dissector, section 2.7.2.

How is SSL implemented for AMQP? Is it immediately running on top of
SSL/TLS, or is there a preceding STARTTLS-like handshake? In the
latter case, see
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9515 and the
related patches.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl/

[1]: https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
___
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] What is the data parameter of call_dissector_with_data?

[Peter Wu]

Hi,

To fix a bug, I need to pass the protocol type from a STARTTLS-like
protocol to the SSL dissector. I was about to use the unused data
field of dissect_ssl for this, but it turns out that the TCP dissector
fills in this field. That makes it entirely useless for other purposes
(such as passing parameters from via call_dissector_with_data).

It seems that my best alternative is p_add_proto_data (documented in
README.dissector, section 2.5 Per-packet information).

What is actually the purpose of the data parameter? It is not
documented well AFAIK, the packet-PROTOABBREV.c does not mention it at
all for example besides marking it as unused.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl/
___
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] Supported Python versions?

[Peter Wu]

Hi,

Triggered by a build error due to html2text.py, I have recently started
with adding Python 3 support to various Python scripts[1][2]. The change
to html2text.py[1] was tested with Python 2.6, 2.7, 3.2 and 3.4.

The configure script however checks for Python = 2.5 which was first
released in 2006 with the last security update in 2011. This version
also lacks support for nice language constructs such as 'with'.
checklicenses.py is already incompatible with this.

Any objections if this gets bumped to 2.6 or even 2.7? The
dfilter-test.py script already requires 2.7 (or newer).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: https://code.wireshark.org/review/7779
 [2]: 
https://code.wireshark.org/review/#/q/status:open+project:wireshark+branch:master+topic:python3,n,z
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt: Convert ProtoTree from QTreeWidget to Model/View

[Peter Wu]

Hi,

I have recently discovered that the Qt UI gets in an inconsistent state
(leading to crashes) whenever a packet dialog is open and packets are
re-dissected. This is reported at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11044

Before proceeding to a reimplementation attempt using Model/View, I
would like to solicit for some feedback. Was the QTreeWidget choice done
consciously? Do you foresee issues with sharing field items via the same
model? Is someone already working on this?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Qt: Convert ProtoTree from QTreeWidget to Model/View

[Peter Wu]

On Mon, Mar 09, 2015 at 11:44:21AM -0700, Gerald Combs wrote:
 On 3/9/15 7:56 AM, Peter Wu wrote:
  Hi,
  
  I have recently discovered that the Qt UI gets in an inconsistent state
  (leading to crashes) whenever a packet dialog is open and packets are
  re-dissected. This is reported at
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11044
  
  Before proceeding to a reimplementation attempt using Model/View, I
  would like to solicit for some feedback. Was the QTreeWidget choice done
  consciously? Do you foresee issues with sharing field items via the same
  model? Is someone already working on this?
 
 A QTreeWidget was chosen lazily, i.e. it did the job at the time. A custom
 model might make more sense given that we have a large limit on the number
 of tree items (MAX_TREE_ITEMS = 1e6).
 
 Having independent models lets each packet dialog persist across files.
 Would a shared model still allow that?

As far as I know, you can only have one open capture file. Correct me if
I am wrong.

Both File sets and opening files manually result in all packet dialogs
getting closed after opening a new capture (v1.99.4rc0-34-g6bc138c).
This is the current GTK+ implementation, Qt crashes for the reasons
mentioned in bug 11044.

A split model/view can in theory allow for opening multiple capture
files in separate views, this would need some additional refactoring
though.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Qt: Convert ProtoTree from QTreeWidget to Model/View

[Peter Wu]

On Mon, Mar 09, 2015 at 02:19:20PM -0700, Gerald Combs wrote:
 On 3/9/15 1:32 PM, Peter Wu wrote:
  On Mon, Mar 09, 2015 at 11:44:21AM -0700, Gerald Combs wrote:
  On 3/9/15 7:56 AM, Peter Wu wrote:
  Hi,
 
  I have recently discovered that the Qt UI gets in an inconsistent state
  (leading to crashes) whenever a packet dialog is open and packets are
  re-dissected. This is reported at
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11044
 
  Before proceeding to a reimplementation attempt using Model/View, I
  would like to solicit for some feedback. Was the QTreeWidget choice done
  consciously? Do you foresee issues with sharing field items via the same
  model? Is someone already working on this?
 
  A QTreeWidget was chosen lazily, i.e. it did the job at the time. A custom
  model might make more sense given that we have a large limit on the number
  of tree items (MAX_TREE_ITEMS = 1e6).
 
  Having independent models lets each packet dialog persist across files.
  Would a shared model still allow that?
  
  As far as I know, you can only have one open capture file. Correct me if
  I am wrong.
 
 That's correct. That's also *exactly* why many of the Qt dialogs catch
 captureFileClosing and disconnect themselves from the current capture file.
 If a user wants packet dialogs from multiple capture files spread across
 multiple monitors I'm not going to question her motives.

So was your comment more like a wishlist feature or did you mean
persistence across packet selections?

  Both File sets and opening files manually result in all packet dialogs
  getting closed after opening a new capture (v1.99.4rc0-34-g6bc138c).
  This is the current GTK+ implementation,
 
 This is annoying behavior, IMHO.
 
  Qt crashes for the reasons mentioned in bug 11044.
 
 ...as is this. :)

Well, closing a capture file should also close other dialogs right? Or
are you pointing at the File sets feature?

File sets are quite a strange feature by the way. Using dumpcap -b
files:3 -b duration:5 I was unable to make wireshark recognize a file
set by opening the first one from the set. Must be me... ;)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Qt: Convert ProtoTree from QTreeWidget to Model/View

[Peter Wu]

On Mon, Mar 09, 2015 at 02:39:20PM -0700, Guy Harris wrote:
 
 On Mar 9, 2015, at 1:32 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
  As far as I know, you can only have one open capture file. Correct me if
  I am wrong.
 
 That's currently the case, but let's not wire that assumption in; a
 proper OS X app would use one UI process for all open files.

Yes, this is the status quo but it would indeed nice to let one process
load many files to reduce startup time and memory footprint.

 (We might implement that by moving packet dissection to separate
 processes, one process for each open file, so that we don't have to
 make per-file private data; we might also, at least on some platforms,
 be able to sandbox the dissection processes, so that, for example, any
 file opening they do must be done for them by the main process, which
 would only allow opening selected files, such as files in the
 preferences directory.)

Coincidentally I have been thinking about using seccomp on Linux (after
reading comments on this LWN page[1]). There are problematic dissectors
such as SSL which may have to read key log files, dissectors needing
name resolution and others, but it is an interesting idea to explore.
Oh, and plugins / statistics will also be more difficult, but it has to
start somewhere.

A file dissector (PNG?) or the logcat format are probably candidates to
start testing as there are no other layers.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: https://lwn.net/Vulnerabilities/630471/
___
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] Qt: Convert ProtoTree from QTreeWidget to Model/View

[Peter Wu]

On Mon, Mar 09, 2015 at 05:25:10PM -0700, Gerald Combs wrote:
 On 3/9/15 4:14 PM, Peter Wu wrote:
  On Mon, Mar 09, 2015 at 02:19:20PM -0700, Gerald Combs wrote:
  On 3/9/15 1:32 PM, Peter Wu wrote:
  On Mon, Mar 09, 2015 at 11:44:21AM -0700, Gerald Combs wrote:
  On 3/9/15 7:56 AM, Peter Wu wrote:
  Hi,
 
  I have recently discovered that the Qt UI gets in an inconsistent state
  (leading to crashes) whenever a packet dialog is open and packets are
  re-dissected. This is reported at
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11044
 
  Before proceeding to a reimplementation attempt using Model/View, I
  would like to solicit for some feedback. Was the QTreeWidget choice done
  consciously? Do you foresee issues with sharing field items via the same
  model? Is someone already working on this?
 
  A QTreeWidget was chosen lazily, i.e. it did the job at the time. A 
  custom
  model might make more sense given that we have a large limit on the 
  number
  of tree items (MAX_TREE_ITEMS = 1e6).
 
  Having independent models lets each packet dialog persist across files.
  Would a shared model still allow that?
 
  As far as I know, you can only have one open capture file. Correct me if
  I am wrong.
 
  That's correct. That's also *exactly* why many of the Qt dialogs catch
  captureFileClosing and disconnect themselves from the current capture file.
  If a user wants packet dialogs from multiple capture files spread across
  multiple monitors I'm not going to question her motives.
  
  So was your comment more like a wishlist feature or did you mean
  persistence across packet selections?
 
 I mean persistence across files. In the Qt UI I can do the following today:
 
 - Open a.pcap.
 - Double-click packet 12, which opens packet 12 in a separate window.
 - Close a.pcap.
 - Open b.pcap
 - Select packet 15.
 - Compare packet 12 from a.pcap with packet 15 from b.pcap.
 
 The I/O graph, capture file properties, conversations, endpoints, and other
 dialogs behave in a similar fashion, e.g. I can compare the TCP
 conversations across files from the same application instance.

Oh, this is a new feature in the Qt UI. I thought it was something that
already exists in GTK+ and since Qt crashed, I limited testing to GTK+.

  Both File sets and opening files manually result in all packet dialogs
  getting closed after opening a new capture (v1.99.4rc0-34-g6bc138c).
  This is the current GTK+ implementation,
 
  This is annoying behavior, IMHO.
 
  Qt crashes for the reasons mentioned in bug 11044.
 
  ...as is this. :)
  
  Well, closing a capture file should also close other dialogs right? Or
  are you pointing at the File sets feature?
 
 Why should it? Why yank away useful information just because the user
 closes the capture file?

Closing suggests that you stop working with the file. This allows
resources to be released. If you now accidentally close that packet
dialog, you have to reopen the capture file. Then wouldn't it be more
convenient if you can work with multiple capture files and switch
between them? The implementation could use tabs (as is done for sites in
a web browser) or a dropdown select menu, or whatever).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Make CMake reuse Makefile.common?

[Peter Wu]

On Wed, Mar 04, 2015 at 02:11:02PM -0500, Evan Huus wrote:
 On Wed, Mar 4, 2015 at 2:04 PM, Jeff Morriss jeff.morriss...@gmail.com 
 wrote:
  On 03/04/15 11:55, Graham Bloice wrote:
 
  On 4 March 2015 at 16:44, Jeff Morriss jeff.morriss...@gmail.com
  mailto:jeff.morriss...@gmail.com wrote:
 
  On 03/04/15 04:07, Michal Labedzki wrote:
 
  On 03/03/15 11:50, Alexis La Goutte wrote:
 
  And also if i remember the target is only have CMake for
  build system
  (and remove autofoo...)
 
 
  I hope there will be only CMake in near future (imply remove
  autotools). As I know cmake aka build systems working for all
  platforms. What about remove building part of autotools, use
  cmake for
  that and use autotools for other tasks?
 
 
  It may work but last I checked it didn't work too well: there's a
  bunch of stuff that works when running from an autotools build
  directory that doesn't from a cmake directory.  And it doesn't
  appear many people have been working on that.
 
 
  Maybe that should be enumerated somewhere.  I've only built (off
  Windows) on Ubuntu using CMake and it worked for me.  On Windows there
  are a few bits left to finish off, but I think the nmake usage is coming
  to an end.
 
 
  It generally works it's just missing features.  A bunch are documented in
  README.cmake but not all.  For example I think Evan found that the test
  suite--at least the Lua portion--don't work in cmake builds; I fixed that in
  autotools (starting with https://code.wireshark.org/review/3348) but I don't
  think anyone has touched the cmake part (I gave up even thinking about cmake
  a while ago).
 
 Yes, the last time I checked the lua test suite on an out-of-tree
 cmake build failed because it couldn't find the right init.lua file.

This likely happened because of the build dir is not correctly used in
cmake builds. See https://code.wireshark.org/review/7453
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Make CMake reuse Makefile.common?

[Peter Wu]

On Tue, Mar 03, 2015 at 05:50:10PM +0100, Alexis La Goutte wrote:
 On Mon, Mar 2, 2015 at 1:16 PM, Peter Wu pe...@lekensteyn.nl wrote:
 
  Hi,
 
  Recently there have been two issues due to separate copies between CMake
  and autofoo (missing ATH dissector, missing field registrations for
  plugins).
 
  The former could occur due to missing duplication from Makefile.common
  into CMakeLists.txt. The latter happens because the
  plugins/*/CMakeLists.txt are slightly different than the Makefiles (in
  terms of variable sets).
 
  Hereby I am proposing to convert Makefile.common automatically to
  CMakeLists.inc.txt, and then include that during the build process to
  set variables. The inspiration comes from cURL which too supports
  autoconf, and (as an experimental option) cmake.
 
  See this transformation macro[0] and its use[1] for an example.
 
 Hi Peter,
 
 Need to try... but i known CMake cURL is no perfect... and there is some
 plan to drop support of CMake ;-)

There *was* a plan to drop CMake support if nobody cared, but since then
patches have been sent to improve it (also from my side).

 And also if i remember the target is only have CMake for build system (and
 remove autofoo...)

That would be great, but I would not rush this yet, there are still some
cmake issues like
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10074. (other issues
I have found, but for which no bug is filled: the path to xdg-open is
fully expanded by cmake).

How are the windows binaries currently build? Using nmake I believe?

  --
  Kind regards,
  Peter Wu
  https://lekensteyn.nl
 
   [0]: https://github.com/bagder/curl/blob/master/CMakeLists.txt#L986
   [1]:
  https://github.com/bagder/curl/blob/master/tests/libtest/CMakeLists.txt#L31
___
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] WS runtime error

[Peter Wu]

On Wed, Mar 04, 2015 at 11:24:28AM -0800, Guy Harris wrote:
 
 On Mar 4, 2015, at 7:29 AM, Joerg Mayer jma...@loplof.de wrote:
 
  When starting Wireshark with a specific trace file (unfortunately 
  confidential),
  I get the following message on startup (git head):
  
  /home/jmayer/work/wireshark/git/ui/qt/packet_list.cpp:537:13: runtime 
  error: load of value 9, which is not a valid value for type 'bool'
  
  Does this provide enough information? If not, what should I do to track down
  the cause of this?
 
 Some Googling suggests that this is an error from ASAN.
 
 If the line number is correct, perhaps the constructor for PacketList
 needs to initialize the tail_at_end_ member.

I get this error already when starting wireshark without capture. The
error is not on that line, but in rows_inserted_ member which is in a
few lines above. Looking at the code there are more members missing.
I'll cook a patch for this.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] My recent build of Wireshark from the master branch consumes 99-100% of the CPU

[Peter Wu]

On Tue, Mar 10, 2015 at 08:37:39PM -0700, Richard Sharpe wrote:
 On Tue, Mar 10, 2015 at 8:15 PM, Evan Huus eapa...@gmail.com wrote:
  On Tue, Mar 10, 2015 at 11:15 PM, Richard Sharpe
  realrichardsha...@gmail.com wrote:
  Hi,
 
  Has anyone else experienced this?
 
  What causes it?
 
  I believe there is a known issue with the Qt auto-scroll feature that
  is being investigated.
 
 OK, thanks.

It is probably this bug:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11035
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Dropping tcp.pdu.size? (was: Re: Buildbot test failures - wslua)

[Peter Wu]

Hi,

On Wed, Mar 11, 2015 at 05:25:17PM +0100, Pascal Quantin wrote:
[..]
 yes I was about to denounce me but Alexis beat me :). This is a side effect
 of the fix for bug 11007 where the addition of the PDU size item was broken
 since some time.
 I know that Peter is debating the usefulness of this field. In the meantime
 we should fix the test suite to pacify the buildbot.
 I can give it a try tonight but if someone is courageous enough to fix it
 earlier, feel free.

I was indeed questioning the usefulness of this field in bug 11007[1].

For a background, the tcp.pdu.size field was added by Ronnie while a
user was having a different problem with a HTTP Content-Length field[2].
Since the addition, tcp_dissect_pdus has been advertised in the
developer documentation for reassembling arbitrary messages.

Now, most protocols will have a field where you can read the length of
the PDU making the tcp.pdu.size field superfluous.

When the protocol is not on top of TCP, it now still shows up in the TCP
tree since Pascals change. If it is on top of TLS, the length is not
related to TCP at all.

What is the usefulness of tcp.pdu.len when you cannot select the bytes
themselves for export in tshark?

So, what about removing tcp.pdu.size? Are there any objections? Most
users seem to encounter it, but not use it (see bug report).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11007
 [2]: https://www.wireshark.org/lists/wireshark-users/200611/msg00167.html
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Supported Python versions?

[Peter Wu]

On Sun, Mar 22, 2015 at 04:58:14PM +0100, Pascal Quantin wrote:
 2015-03-22 16:48 GMT+01:00 Peter Wu pe...@lekensteyn.nl:
 
  Hi,
 
  Triggered by a build error due to html2text.py, I have recently started
  with adding Python 3 support to various Python scripts[1][2]. The change
  to html2text.py[1] was tested with Python 2.6, 2.7, 3.2 and 3.4.
 
  The configure script however checks for Python = 2.5 which was first
  released in 2006 with the last security update in 2011. This version
  also lacks support for nice language constructs such as 'with'.
  checklicenses.py is already incompatible with this.
 
  Any objections if this gets bumped to 2.6 or even 2.7? The
  dfilter-test.py script already requires 2.7 (or newer).
 
 
 Hi Peter,
 
 the OSX 10.5 x86 buildbot still runs Python 2.5, so bumping the minimum
 Python  version would require updating the buildbot. So it's better to keep
 compatibility for the scripts used during build steps.
 
 Pascal.

According to the ComputerWorld source listed by Wikipedia[1], OS X 10.5
became unsupported since June 2011. Python 2.5 also does not receive
security updates anymore. (OS X 10.6 has Python 2.7 which is still
supported.)

Are there OS version usage statistics available for Wireshark?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

PS. could someone review changes https://code.wireshark.org/review/7778
and https://code.wireshark.org/review/7779, without these changes the
build fail on systems where Python 3 is the default.

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

[Wireshark-dev] Make CMake reuse Makefile.common?

[Peter Wu]

Hi,

Recently there have been two issues due to separate copies between CMake
and autofoo (missing ATH dissector, missing field registrations for
plugins).

The former could occur due to missing duplication from Makefile.common
into CMakeLists.txt. The latter happens because the
plugins/*/CMakeLists.txt are slightly different than the Makefiles (in
terms of variable sets).

Hereby I am proposing to convert Makefile.common automatically to
CMakeLists.inc.txt, and then include that during the build process to
set variables. The inspiration comes from cURL which too supports
autoconf, and (as an experimental option) cmake.

See this transformation macro[0] and its use[1] for an example.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [0]: https://github.com/bagder/curl/blob/master/CMakeLists.txt#L986
 [1]: 
https://github.com/bagder/curl/blob/master/tests/libtest/CMakeLists.txt#L31
___
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] SSL/DTLS: allow setting of app data dissector when using keylog file

[Peter Wu]

On Mon, Feb 23, 2015 at 03:32:48PM +0100, Gianrico wrote:
 I am looking for advices/opinions for a new feature.
 
 Basically I would like to have the possibility of specifying the inner
 app data protocol when dissecting/decrypting ssl/dtls using the keylog
 file.
 
 There are situations when the inner protocol might be a custom
 protocol (ssl vpn in my case).
 At the moment it looks like you can specify the inner protocol only
 when using the ssl key and uat table.
 
 By the way, for obvious reasons, when troubleshooting with third party
 captures it is becoming more frequent to receive the (pre)-master
 secret (when RSA in use).
 
 I have proposed this patch :
 
 https://code.wireshark.org/review/#/c/7233/
 
 Peter properly noted that this is a hack and it would be better to
 keep the keylog file clean and move the setting somewhere else.

SSL keylog suggests that it contains names, adding metadata could be
done, but I think there is a better approach. Consider what would happen
if this file is missing (but you have RSA keys), then the packets are
still not dissected as wanted.

It looks like that the current method of associating an application data
protocol with SSL is inflexible. It causes bugs such as
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10984 (worth
reading, it contains an analysis and some suggestions).

Your goal is likely to force the correct protocol on a SSL Application
Data stream. The current methods for this are:

 - Add a heuristics dissector with heur_dissector_add(ssl, ...)
 - Register with ssl_dissector_add(port, proto, is_tcp)

Both have shortcomings:

 - The heuristics dissector gets called for each packet even though
   SSL/TLS is stream-oriented.  Since you often cannot decrypt the
   stream without knowing the decryption state, it is pretty much
   guaranteed that the first packet is always available. As such, it
   would make more sense to call the heuristics dissector only once for
   the first packet.
 - The ssl_dissector_add function allows for registration of only one
   protocol per port.

I propose to make one or more of these changes:

 - Call the heuristics dissector only for the first data frame.
 - Decouple the list of valid protocols from
   transport_proto/addr/server_port-appdata_proto/keyfile
   associations. This allows for multiple valid protocols while linking
   one unique key per transport_proto/address/server_port tuple.
   (Jeff, comments?)
 - Allow a wildcard protocol name in the UAT dialog just to set the key,
   not the protocol (any, * or the empty string?).
 - Select an appdata protocol in this order: STARTTLS hint, heuristics,
   associations, (first available) dissector hint.

Why the suggested protocol selection order?

 - STARTTLS hint is quite strong.
 - Good heuristics can do the right thing automatically.
 - Associations are entered by the user.
 - For protocols such as SMTP, there is one clear choice which is great.
   For port 443, the best guess is HTTP (which should have been caught
   by the heuristics dissector) but others are possible.

Gianrico, do you think that good heuristics is possible for your
protocols?

 I would like to have, anyway, the flexibility of having multiple app
 data dissector when multiple (pre)master kays are in the keylog file
 (see again proposed patch for an example)
 
 Please let me know your thoughts and if that makes sense to be
 implemented or should i just keep it for me.

A concern with the current approach would be backwards compatibility. By
using PROTO 443,http RSA (pre-master) (masterkey), the file becomes
useless for older Wireshark versions (and other implementations using
this file, if they exist).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl


pgpBCbqhm04ke.pgp
Description: PGP signature
___
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] SSL/DTLS: allow setting of app data dissector when using keylog file

[Peter Wu]

On Mon, Feb 23, 2015 at 10:49:55PM +0100, Peter Wu wrote:
 On Mon, Feb 23, 2015 at 03:32:48PM +0100, Gianrico wrote:
 
 I propose to make one or more of these changes:
 
  - Call the heuristics dissector only for the first data frame.

I forgot to mention the 1/n-1 splitting which is nowadays commonly done
for SSL dissectors to mitigate BEAST. New-style dissectors could return
-1 (I want more data) if they need more than the first byte.

  - Decouple the list of valid protocols from
transport_proto/addr/server_port-appdata_proto/keyfile
associations. This allows for multiple valid protocols while linking
one unique key per transport_proto/address/server_port tuple.
(Jeff, comments?)
  - Allow a wildcard protocol name in the UAT dialog just to set the key,
not the protocol (any, * or the empty string?).
  - Select an appdata protocol in this order: STARTTLS hint, heuristics,
associations, (first available) dissector hint.
 
 Why the suggested protocol selection order?
 
  - STARTTLS hint is quite strong.
  - Good heuristics can do the right thing automatically.
  - Associations are entered by the user.
  - For protocols such as SMTP, there is one clear choice which is great.
For port 443, the best guess is HTTP (which should have been caught
by the heuristics dissector) but others are possible.

-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Use of tcp_dissect_pdus() with a protocol which has a variable length PDU length field

[Peter Wu]

Hi,

While looking at improving the Websocket dissector, I found the need to
support variable length fields in tcp_dissect_pdus. Here is Bills
original mail (which had no replies).

On Fri, May 09, 2014 at 11:02:45AM -0400, Bill Meier wrote:
 To: TCP re-assembly experts:
 
 
 The MQTT protocol dissected by packet-mqtt.c runs over TCP. The field which
 specifies the MQTT PDU length can be 1 to 4 bytes; the length of a complete
 MQTT PDU can be less than 4 bytes.
 
 So: trying use tcp_dissect_pdus() won't work since the fixed length
 needed to handle the maximum size of the PDU length field is larger than
 the possible minimum PDU size.
 
 One approach is to assume that the complete length field will, with high
 probability, always be in 1 TCP segment and thus available even if
 specifying a 'fixed length' which includes only a 1 byte PDU length field.
 (This is certainly not guaranteed).
 
 Or, obviously, the dissector could do reassembly as described in
 README.dissector section 2.7.2 Modifying the pinfo struct.
 
 However, digging a little deeper, I note that tcp_dissect_pdus() is doing
 something related to want_pdu_tracking (which I've never delved into and
 which is not mentioned in README.dissector).
 
 So it occurred to me that using a modified tcp_dissect_pdus() which allows
 the get_pdu_len function to return DESEGMENT_ONE_MORE_SEGMENT might be a
 workable approach.
 
 So: I added the following to tcp_dissect_pdus() and modified
 the packet-mqtt.c get_pdu_len() function appropriately.
 
 (added code in tcp_dissect_pdus):
 
  plen = (*get_pdu_len)(pinfo, tvb, offset);
 +
 +/* Is more data being requested before the PDU length can be
 determined ?
 + *  If so, request same.
 + */
 +if (plen == DESEGMENT_ONE_MORE_SEGMENT) {
 +if (!proto_desegment || !pinfo-can_desegment) {
 +REPORT_DISSECTOR_BUG(DESEGMENT_ONE_MORE_SEGMENT not
 allowed);
 +}
 +pinfo-desegment_offset = offset;
 +pinfo-desegment_len = DESEGMENT_ONE_MORE_SEGMENT;
 +return;
 +}
 +
  if (plen  fixed_len) {
 
 
 My questions:
 
 1. Is this a reasonable approach (it works AOK in my tests) ?

This approach looks fine to me. I have taken the same approach (but
replacing REPORT_DISSECTOR_BUG by DISSECTOR_ASSERT in
https://code.wireshark.org/review/7279

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

Looking at the current implementation of tcp_dissect_pdus, it is not
necessary to change want_pdu_tracking as the size of the new PDU is not
yet known.

Since this is an interesting API update, I thought that informing the
list would be a good idea.

Kind regards,
Peter
___
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] Can we put android phone device connected over USB to Win 7 PC in promiscous mode?

[Peter Wu]

On Wed, Feb 25, 2015 at 07:52:03AM +0100, Michal Labedzki wrote:
 On 24 February 2015 at 23:03, Peter Wu pe...@lekensteyn.nl wrote:
  Before you attempt to use the output of `adb shell` in a pipe, keep in
  mind that adb mangles newlines (LF - CRLF) and is therefore unsuitable
  for binary data. This does not matter for textual output such as
  tcpdump -D, but it affects tcpdump -w - (writes pcap to stdout).
 
 Yes, I know. In real it is not a problem (there is possibility to
 safely replace bytes),  but I decided to use text output because from
 time to time on Google Gerrit someone may found patch to fix these
 newlines...

Not sure if understood your comment, does that refer to patching adb?
You can use ssh or adb with port forwarding (adb forward and netcat) as
alternative transports.

 Peter, what do you think about tcpdump interfaces from Android in
 Wireshark (PC side)? I do not have ready that in my extcap tool (that
 I will contribute soon), but it is trivial to do that (something like
 that I do for old Android for Bluetooth interface hcidump). Pros:
 ~realtime sniffing from Android (with tcpdump and permissions...);
 also may add interfaces for USB [Unfortunately I do not see any phone
 that implement that...], Cons: add a lot of interfaces... sometimes
 2 (wlan0, any), somethimes 5, etc.

The kernel on my phone (CyanogenMod 11 with patched 3.0.64 kernel on
i9300) has CONFIG_USB_MON=y and /sys/kernel/debug/usb/usbmon/ exists too
(no /dev/usbmonX). cat'ing that file (or using tcpdump for that matter)
produces no output even if I have a USB cable attached for adb...
strange.

This is the output for tcpdump -D (as root):

1.wlan0
2.usbmon1 (USB bus number 1)
3.p2p0
4.usbmon2 (USB bus number 2)
5.any (Pseudo-device that captures on all interfaces)
6.lo

No bluetooth interfaces even if I enable the interface (this is tcpdump
4.4.0 with libpcap 1.4.0).

If you try to make Android capture interfaces available in Wireshark,
then you are effectively trying to enable remote capturing from a Linux
source right? I suggest to use the 'adb forward' method mentioned above.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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] Can we put android phone device connected over USB to Win 7 PC in promiscous mode?

[Peter Wu]

Hi,

On Tue, Feb 24, 2015 at 08:30:09AM +0100, Michal Labedzki wrote:
 Hello,
 
 I think I am working on solution for you... If you have ADB (SDK) and
 tcpdump (with permissions) then I can emulate live capture from
 Android devices. Please check:
 adb shell tcpdump -D
 adb shell su -c tcpdump -D

Before you attempt to use the output of `adb shell` in a pipe, keep in
mind that adb mangles newlines (LF - CRLF) and is therefore unsuitable
for binary data. This does not matter for textual output such as
tcpdump -D, but it affects tcpdump -w - (writes pcap to stdout).

 Limitation: works only with Wireshark, or standalone application, not
 Windows Interface.
 
 On 24 February 2015 at 08:13, Shashikant Ajegaonkar
 ajegaon...@gmail.com wrote:
  Hi All,
 
  Has anyone tried to put WiFi interface of Android device in promiscous mode?
  Is it possible to enumerate phone over adb interface as device  wireless
  network interface in Win7 machine and configure it in promiscous mode for
  sniffer application?

I have once written an Android app which can put a wireless interface in
promiscuous mode and capture layer 2 frames (802.11). There are some
issues to consider:

 - The wireless driver of my phone did not support monitor mode. So I
   bought a USB on the go cable and a Ralink 802.11n USB adapter using
   the rt2x00 driver. This driver was not supported by the custom
   firmware (Cyanogenmod) so I had to build a new kernel as well.
 - The easiest way to make use of tcpdump is by running it as root, but
   you can also use capabilities and declare a manifest permission in
   the Android app. (This required a kernel patch,
   http://stackoverflow.com/q/13042117/427545).
 - Battery drains fast when using an external USB adapter, phone can
   get quite hot.
 - If your firmware does not include tcpdump, it is actually quite easy
   to build it. All you need are the libpcap and tcpdump sources and the
   Android NDK.

Oh and it is not trivial to build Wireshark for Android. It has many
dependencies, and last time I looked using dumpcap/tshark, I stopped
once it notes that Glib was missing.

If you just want to debug an app on the phone, it is much easier to
setup a VPN/proxy and start tapping at the VPN or proxy server.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
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 messages I don't want to see

[Peter Wu]

Hi Jörg,

On Tue, Jul 14, 2015 at 08:01:38PM +0200, Joerg Mayer wrote:
 ... but have no idea how to find or fix:
 
 jmayer@egg privat$ wireshark -r 6.pcap.gz
 /home/jmayer/work/wireshark/git/epan/address.h:158:5: runtime error: null 
 pointer passed as argument 1, which is declared to never be null
 /home/jmayer/work/wireshark/git/epan/address.h:158:5: runtime error: null 
 pointer passed as argument 2, which is declared to never be null
 /home/jmayer/work/wireshark/git/epan/crypt/airpdcap.c:1558:16: runtime error: 
 index 256 out of bounds for type 'AIRPDCAP_SEC_ASSOCIATION [256]'

These messages are from ubsan (Undefined Behavior Sanitizer). In order
to debug such issues, I suggest setting these options:

export UBSAN_OPTIONS=print_stacktrace=1 \
ASAN_OPTIONS=strip_path_prefix=/home/jmayer/work/wireshark/git/ \

It produces the stack trace of the origin and strips the common source
prefix. See http://stackoverflow.com/q/30809022 if you want to use gdb
to break on such reports.

 git head as of 6-7 hours ago, qt only.
 I loaded an 802.11 trace, added a wpa2 key and looked at the result. The trace
 is probably confidential (will need to ask).
 Please let me know what information is needed to get rid of the first 3 
 messages
 in particular.

A stacktrace would be helpful :-)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Peter Wu]

Try cmake -DBUILD_wireshark=0 (case is significant). These options are defined 
in CMakeOptions.txt which you can also find via invocation of cmake-gui.

Kind regards,
Peter
https://lekensteyn.nl
(pardon my brevity, top-posting and formatting, sent from my phone)


On 12 November 2015 19:13:07 CET, Bill Meier  wrote:
>How do I disable building QT Wireshark when using CMake ?
>
>Thanks
>
>Bill
>
>___
>Sent via:Wireshark-dev mailing list 
>Archives:https://www.wireshark.org/lists/wireshark-dev
>Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

Re: [Wireshark-dev] Supported GnuTLS/glib/libgcrypt versions?

[Peter Wu]

On Thu, Oct 15, 2015 at 12:03:41PM -0700, Guy Harris wrote:
> 
> On Oct 14, 2015, at 11:25 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> 
> > Looks like GnuTLS is only needed if you have to supply a RSA private
> > key.
> 
> How much of it doe we use?
> 
> If it's a sufficiently small amount, would it be worth just carving
> that part out and incorporating it directly into Wireshark, especially
> if that part is unlikely to change in the future in ways that we'd
> care about (bug fixes and new features that we'd actually use)?

That was the only functionality GnuTLS is used for. The change that
resulted in newer version requirement is matching the RSA private key by
its public key (instead if asking the user to specify an address +
port).

If needed I can try to create a compatibility file for older GnuTLS
versions that implements the needed functionality.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Supported GnuTLS/glib/libgcrypt versions?

[Peter Wu]

On Thu, Oct 15, 2015 at 08:44:56PM +0200, Anders Broman wrote:
> Den 15 okt 2015 19:43 skrev "Jeff Morriss" <jeff.morriss...@gmail.com>:
> >
> > On 10/14/15 14:25, Peter Wu wrote:
> >>
> >> On Mon, Oct 12, 2015 at 02:02:18PM -0400, Jeff Morriss wrote:
> >>>
> >>> But you do raise a good point: I should start doing test compiles of
> the 2.0
> >>> rc on RHEL 6.  I hadn't realized my users would have to continue using
> the
> >>> Gtk+ GUI.  Too bad...
> >>
> >>
> >> I have started testing with cmake + CentOS 6, it is not doing bad. At
> >> least these fixes are needed to fix the build:
> >> https://code.wireshark.org/review/10916
> >> https://code.wireshark.org/review/11041
> >
> >
> > Funny, I actually didn't have any problems (once I updated my
> (customized) RPM spec file with some of the changes from master).  But
> rpmbuild is using autotools and building from the source tarball.

Yes, the problems only occurred with cmake.

> >>>> Speaking of bumping library versions, can we also bump the glib and
> >>>> libgcrypt versions? Current versions are glib 2.14 and libgcrypt
> >>>> 1.1.92. If we could go to glib 2.28 (Feb 2011) and gcrypt 1.5.0 (Jun
> >>>> 2011), it would enable us to use newer functions such as
> >>>> g_list_free_full.
> >>>
> >>>
> >>> The glib change is OK for me (for RHEL 6) but it does appear to
> >>> mean we'd lose support for all SLES versions; I'd tend to think
> >>> that would be a bad thing.
> >>
> >>
> >> I made a mistake, SLES 12 includes glib2 2.38.2, the wiki is now updated
> >> to reflect that. For now the minimum gcrypt version is 1.4.2
> >> (https://code.wireshark.org/review/11043).
> >
> >
> > So bumping the glib version means we'd lose SLES 11.  Given how
> > recent (for an enterprise version) SLES 12 is I'd guess there are
> > still a lot of SLES 11 users out there.
> >
> >
> I'm need to build on SLES11 so please don't break that.

How does SLES work? Is upgrading to the latest SP seamless? How about
newer releases such as SLES12?  SLES11 SP2 provides gcrypt 1.5.0 which
is sufficiently new, but SP1 is not compatible anymore (1.4.1 < 1.4.3).

Looks like glib won't be upgraded any time soon. Do you need SSL
decryption with a given RSA private key?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Supported GnuTLS/glib/libgcrypt versions?

[Peter Wu]

On Mon, Oct 12, 2015 at 02:02:18PM -0400, Jeff Morriss wrote:
> On 10/11/15 17:32, Peter Wu wrote:
> >Hi,
> >
> >Michal reported to me that a recent change in the SSL dissector was not
> >compatible with older GnuTLS versions[1].
> >
> >The changes introduced the use of functions gnutls_pubkey_import and
> >gnutls_pubkey_import_rsa_raw which were introduced with GnuTLS 2.12.0 in
> >2011-03-24 (2.11.3 development). Michal is using (RHEL6?) GnuTLS 2.8.5
> >(released in November 2009).
> >
> >Since the minimum Qt4 version for upcoming Wireshark 2.0 is already
> >higher than what RHEL6 ships, would you mind if the GnuTLS version is
> >also bumped?
> 
> Since GnuTLS is optional [and I don't do decryption very often ;-)] I don't
> really mind.  I can't say that I know how much the rest of the RHEL 6 world
> uses decryption though.

Looks like GnuTLS is only needed if you have to supply a RSA private
key. When using the SSL keylog file, having just libgcrypt is
sufficient. Currently the SSL dissector requires both to be present for
decryption, but that is an unnecessary restriction. I'll move code
around so that at least decryption with a SSL keylog file can be
supported.

> But you do raise a good point: I should start doing test compiles of the 2.0
> rc on RHEL 6.  I hadn't realized my users would have to continue using the
> Gtk+ GUI.  Too bad...

I have started testing with cmake + CentOS 6, it is not doing bad. At
least these fixes are needed to fix the build:
https://code.wireshark.org/review/10916
https://code.wireshark.org/review/11041

GnuTLS needs more work, for now it RHEL6 support for decryption with a
RSA private key will be dropped. Maybe I'll find a solution later.
The version check is updated at https://code.wireshark.org/review/11044.

> >Speaking of bumping library versions, can we also bump the glib and
> >libgcrypt versions? Current versions are glib 2.14 and libgcrypt
> >1.1.92. If we could go to glib 2.28 (Feb 2011) and gcrypt 1.5.0 (Jun
> >2011), it would enable us to use newer functions such as
> >g_list_free_full.
> 
> The glib change is OK for me (for RHEL 6) but it does appear to mean we'd
> lose support for all SLES versions; I'd tend to think that would be a bad
> thing.

I made a mistake, SLES 12 includes glib2 2.38.2, the wiki is now updated
to reflect that. For now the minimum gcrypt version is 1.4.2
(https://code.wireshark.org/review/11043).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Supported GnuTLS/glib/libgcrypt versions?

[Peter Wu]

Hi,

Michal reported to me that a recent change in the SSL dissector was not
compatible with older GnuTLS versions[1].

The changes introduced the use of functions gnutls_pubkey_import and
gnutls_pubkey_import_rsa_raw which were introduced with GnuTLS 2.12.0 in
2011-03-24 (2.11.3 development). Michal is using (RHEL6?) GnuTLS 2.8.5
(released in November 2009).

Since the minimum Qt4 version for upcoming Wireshark 2.0 is already
higher than what RHEL6 ships, would you mind if the GnuTLS version is
also bumped?

Speaking of bumping library versions, can we also bump the glib and
libgcrypt versions? Current versions are glib 2.14 and libgcrypt
1.1.92. If we could go to glib 2.28 (Feb 2011) and gcrypt 1.5.0 (Jun
2011), it would enable us to use newer functions such as
g_list_free_full.

I have also added GnuTLS and libgcrypt to the wiki for comparison:
https://wiki.wireshark.org/Development/Support_library_version_tracking
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [2]: 
https://code.wireshark.org/review/#/c/10766/6/epan/dissectors/packet-ssl-utils.c@52
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] FILETIME to nstime_t conversions gives a warning

[Peter Wu]

Hi Guy,

Thank you for your detailed reply.

On Mon, Oct 05, 2015 at 08:11:55AM -0700, Guy Harris wrote:
> 
> On Oct 4, 2015, at 6:09 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> 
> > I am getting these compile warnings using Clang 3.7.0:
> > 
> >wsutil/nstime.c:235:25: warning: shifting a negative signed value is 
> > undefined [-Wshift-negative-value]
> >time_t l_time_min = TIME_T_MIN;
> >^~
> >wsutil/nstime.c:223:36: note: expanded from macro 'TIME_T_MIN'
> >: ~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1)))
> >   ^
> >wsutil/nstime.c:236:25: warning: shifting a negative signed value is 
> > undefined [-Wshift-negative-value]
> >time_t l_time_max = TIME_T_MAX;
> >^~
> >wsutil/nstime.c:226:46: note: expanded from macro 'TIME_T_MAX'
> >#define TIME_T_MAX ((time_t) (~ (time_t) 0 - TIME_T_MIN))
> > ^~
> >wsutil/nstime.c:223:36: note: expanded from macro 'TIME_T_MIN'
> >: ~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1)))
> >   ^
> > 
> > Looking a bit further in the code, I became a bit confused on what is
> > going on in nstime.c. There is a magic "fixup" constant
> 
> Not all that magic - all but 6 hours of it are explained in the
> comment (if anybody either 1) knows where those 6 hours came from or
> 2) where I miscalculated so that there are no 6 hours to explain,
> please feel free to submit a change to the comment to Gerrit for
> review).
> 
> (The code and the comment assume familiarity with 1) UN*X time stamps
> and 2) Windows FILENAME time stamps, where the former measure some
> form of "seconds-since-the-Epoch" plus fractions of a second, with the
> Epoch being January 1, 1970, 00:00:00 UTC, and with "some form of
> "seconds-since-the-Epoch"" involving different ways of dealing with
> leap seconds, including POSIX's "if we close our eyes, stick our
> fingers in our ears, and pretend they don't happen, maybe that'll
> work", and the latter measure
> 100-nanosecond-units-since-the-FILETIME-Epoch, with the Epoch being
> what would be January 1, 1601 in the proleptic Gregorian calendar,
> 00:00:00 "GMT".
> 
> The constant is just the delta between the epochs.)
> 
> > and some special handling for the largest and smallest time_t values.
> 
> Right before the offending lines is the comment:
> 
> /* The next two lines are a fix needed for the
>broken SCO compiler. JRA. */
> 
> (where I'm guessing "JRA" is Jeremy Allison).
> 
> > The comments suggest that it is based on Samba code,
> 
> Yes - older Samba code.
> 
> > but their latest version[1] is much simpler:
> 
> Probably because they don't care about SCO's compiler any more.

Probably because SCO compilers are fixed by now. This page suggests GCC
for opensource projects, I think we can remove the workaround too:
http://osr507doc.sco.com/en/DevSysoview/Ccompil.html

> I'm not sure we should care much about it, either, and can just go
> with something based on the current Samba code (but with the comment
> explaining the mixup constant, which the Samba code doesn't bother to
> do), as long as the new code doesn't fail in cases where the current
> code would succeed ("succeed" means "calculates the correct seconds
> value").
> 
> >#ifndef TIME_T_MIN
> >/* we use 0 here, because (time_t)-1 means error */
> >#define TIME_T_MIN 0
> >#endif
> 
> There's nothing about (time_t)-1 that inherently means "error" rather
> than "December 31, 1969, 23:59:59 UTC".

Right, the "error" refers to the return value of mktime().

> >/*
> > * we use the INT32_MAX here as on 64 bit systems,
> > * gmtime() fails with INT64_MAX
> > */
> >#ifndef TIME_T_MAX
> >#define TIME_T_MAX MIN(INT32_MAX,_TYPE_MAXIMUM(time_t))
> >#endif
> 
> If the Samba people want Bad Things to happen on 64-bit systems in
> 2038, they're more than welcome to do so.  I'd prefer *not* to do so
> in Wireshark, even at the expense of some UN*X time in the very very
> very far future causing problems.

See the comment on gmtime(), they use that, but we do not. So we do not
need this restriction.

> So I'd go with
> 
>   #define TIME_T_MIN _TYPE_MINIMUM(time_t)
> 
> and
> 
>   #define TIME_T_MAX _TYPE_MAXIMUM(time_t)
> 
> _TIME_MINIM

[Wireshark-dev] Minimum supported library versions?

[Peter Wu]

Hi,

While working on the libgcrypt code in the SSL dissector
(https://code.wireshark.org/review/9572), I noticed that some
code can be slightly simplified by using a newer version (1.5.0,
released June 2011[1]).

Gerald told me at SF that we aim to support 5 years old libraries
(correct me if I am wrong). Shall we use bump the library requirements
for the 2.0 release too? (glib2, gcrypt, ...)?

Is there a list of the real requirements, including versions? (wiki?
configure.ac is a bit harder to provide an overview.)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: http://upstream.rosalinux.ru/versions/libgcrypt.html
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] asn2wrs documentation?

[Peter Wu]

Hi Tomáš,

On Tue, Sep 15, 2015 at 02:29:02PM +, Kukosa Tomáš wrote:
> Unfortunately asn2wrs can not help with it.
> Changing  TYPE_ATTR does not change called dissection function. It 
> changes just field type.
> The field ber.64bit_uint_as_bytes comes from function 
> dissect_ber_integer64() of packet-ber.c.
> 
> Maybe the dissect_ber_integer64() should check whether the field has the 
> FT_BYTES type and then it could use the original field instead of the 
> ber.64bit_uint_as_bytes.

This is done now since yesterday
(https://code.wireshark.org/review/10539), now it suffices to use this
for INTEGER types:

#.TYPE_ATTR
RSAPublicKey/modulus TYPE = FT_BYTES  DISPLAY = BASE_NONE

> Another possibility would be to define own dissector function for the 
> RSAPublicKey fields instead of calling default dissect_ber_integer(). 
> E.g. something like this:
> 
> #.FN_BODY  RSAPublicKey/modulus
>gint8 ber_class;
>gboolean pc, ind;
>gint32 tag;
>guint32 len;
> 
>offset = dissect_ber_identifier(actx->pinfo, tree, tvb, offset, 
> _class, , );
>offset = dissect_ber_length(actx->pinfo, tree, tvb, offset, , );
>   /* integer octets are at the offset */
>offset += len;
> #.END

Yes, this is something I will use, thanks! For integers I think that the
"ind" part is not needed (can be NULL) as integers are not using the
indefinite length encoding?

> There is not better asn2wrs document available. The best documentation 
> are examples in the asn1 directory.

Those examples unfortunately have no explanation either. For example,
there is a FIELD_ATTR member that is used in some places, how does it
differ from TYPE_ATTR? Any idea what the IMPORT_TAG is used for (it is
only used in one place)?

Thanks,
Peter

> Best regards,
>Tomas
> 
> 
> On 15.9.2015 13:46, Peter Wu wrote:
> > Hi,
> >
> > I am working on improving dissection support of the subjectPublicKey
> > field in X.509 Certificates[1]. Right now these opaque BIT STRING types
> > are shown as a sequence of bytes, but I would like to dissect the other
> > fields (like modulus and exponent for RSA and public key y for DSA).
> > (This work is a prerequisite for a new method of specifying RSA private
> > key files in the SSL preferences without having to list address+port.)
> >
> > These numbers (RSA modulus, DSA y, DSS-Params p, q, g) are larger than
> > 64-bit and therefore are forced to be displayed as FT_BYTES. The problem
> > that now occurs is that the original field is lost
> > (ber.64bit_uint_as_bytes is used instead).
> >
> > To tackle that problem, I started using TYPE_ATTR, but since the fields
> > are still dissected as ber_integer, it does not help. I think I can use
> > "IMPORT_TAG", but it is not documented on the wiki[2].
> >
> > Those who are familiar with the asn2wrs script, is it possible to update
> > the wiki? Are there other documentation resources available?
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] asn2wrs documentation?

[Peter Wu]

Hi,

I am working on improving dissection support of the subjectPublicKey
field in X.509 Certificates[1]. Right now these opaque BIT STRING types
are shown as a sequence of bytes, but I would like to dissect the other
fields (like modulus and exponent for RSA and public key y for DSA).
(This work is a prerequisite for a new method of specifying RSA private
key files in the SSL preferences without having to list address+port.)

These numbers (RSA modulus, DSA y, DSS-Params p, q, g) are larger than
64-bit and therefore are forced to be displayed as FT_BYTES. The problem
that now occurs is that the original field is lost
(ber.64bit_uint_as_bytes is used instead).

To tackle that problem, I started using TYPE_ATTR, but since the fields
are still dissected as ber_integer, it does not help. I think I can use
"IMPORT_TAG", but it is not documented on the wiki[2].

Those who are familiar with the asn2wrs script, is it possible to update
the wiki? Are there other documentation resources available?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: 
https://git.lekensteyn.nl/peter/wireshark/commit/?h=lkn/x509-subjectpublickey-v2
 [2]: https://wiki.wireshark.org/Asn2wrsAuxiliary
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Use of variadic macros

[Peter Wu]

Hi,

Use of variadic macros has been discussed in the past
(https://www.wireshark.org/lists/wireshark-dev/201209/msg00142.html),
but at that time it was dropped because it was deemed not supported well
enough across compilers.

Now apparently commit v1.11.3-rc1-2203-geee21a6 added
proto_tree_add_float_format_value which uses variadic macros again and
nobody has complained so far. I also want to use variadic macros in
https://code.wireshark.org/review/10685 because it is natural for format
strings.

GCC 4.4.7/5.2.0 and, Clang 3.0/3.7 and icc 13.0.1 have no issues with
variadic arguments using this test snippet:

#include 
#define FOO(fmt, ...) printf(fmt, #__VA_ARGS__, __VA_ARGS__)
int main() {
  return FOO("%s test %d\n", 1);
}

at http://gcc.godbolt.org/ with '-Wall -std=c89 -xc.

Are there any objections on removing the variadic arguments restriction?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Improving the SSL keys dialog, how to handle migrations?

[Peter Wu]

Hi,

So far SSL/DTLS private RSA key files were entered in an UAT dialog
(ssl_keys) using address, port, protocol, keyfile and password.

Since the public key part of a private key is sufficient to match SSL
sessions for decryption (https://code.wireshark.org/review/10766), I
want to remove the former fields.

The address+port mapping to SSL can already be substituted by Decode
As... SSL.

The port to app_handle (subprotocol) mapping is problematic (see
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10984#c12) and I
would like to remove it here, but I can imagine that some users want to
override the app_handle anyway. For those use cases, I am considering a
new Decode As setting (ssl.tcp_port, ssl.udp_port). (Limitation: since
you can only override per port, setting tcp/443 to spdy instead of http
might not have the intended effect.)

How should I handle the UAT change? For simple preferences there is
prefs_register_obsolete_preference, but there is nothing for UATs AFAIK.
Maybe I can use Wireshark 2.0 as an excuse to break backwards
compatibility for this setting? Alternative option is to create a new
"ssl_keys2" file and import from "ssl_keys" if it does not already
exist (but this makes the code more ugly).

Suggestions are welcome!
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Improving the SSL keys dialog, how to handle migrations?

[Peter Wu]

On Sat, Oct 03, 2015 at 07:05:50PM +0200, Pascal Quantin wrote:
> Hi Peter,
> 
> Some general comments in-line. I'm not a user of SSL/DTLS dissectors so I
> do not have any real suggestion for your proposals.
> 
> Le 3 oct. 2015 6:53 PM, "Peter Wu" <pe...@lekensteyn.nl> a écrit :
> >
> > Hi,
> >
> > So far SSL/DTLS private RSA key files were entered in an UAT dialog
> > (ssl_keys) using address, port, protocol, keyfile and password.
> >
> > Since the public key part of a private key is sufficient to match SSL
> > sessions for decryption (https://code.wireshark.org/review/10766), I
> > want to remove the former fields.
> >
> > The address+port mapping to SSL can already be substituted by Decode
> > As... SSL.
> 
> Is it really similar? It only allows you to configure SSL for a given port,
> right? Isn't there the risk a port number being reused for non SSL
> communication with another address?

In the current implementation it is similar, even if the UI is
suggesting otherwise. That is why I am suggesting removal of it.
The address+port is only used for matching private keys (previously
tracked via the "SslService" struct)

The port is also a hint for TCP/UDP dissectors and additionally lets the
SSL dissector know that the port is handled by the configured protocol
(say, HTTP).

> > The port to app_handle (subprotocol) mapping is problematic (see
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10984#c12) and I
> > would like to remove it here, but I can imagine that some users want to
> > override the app_handle anyway. For those use cases, I am considering a
> > new Decode As setting (ssl.tcp_port, ssl.udp_port). (Limitation: since
> > you can only override per port, setting tcp/443 to spdy instead of http
> > might not have the intended effect.)
> >
> > How should I handle the UAT change? For simple preferences there is
> > prefs_register_obsolete_preference, but there is nothing for UATs AFAIK.
> > Maybe I can use Wireshark 2.0 as an excuse to break backwards
> > compatibility for this setting? Alternative option is to create a new
> > "ssl_keys2" file and import from "ssl_keys" if it does not already
> > exist (but this makes the code more ugly).
> 
> Creating a ssl_keys2 file seems to be a seamless approach for users. But
> would it be complex to write? The deadline for 2.0 is soon...

It does not look trivial. The two patches that are now in Gerrit are
preparatory work (use RSA public key instead of address + port for
matching), the UI/UAT part needs more work.

The current UAT dialog is broken anyway, moving fields with tab does
not work and empty entries can be saved, bypassing UAT callbacks.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] FILETIME to nstime_t conversions gives a warning

[Peter Wu]

Hi,

I am getting these compile warnings using Clang 3.7.0:

wsutil/nstime.c:235:25: warning: shifting a negative signed value is 
undefined [-Wshift-negative-value]
time_t l_time_min = TIME_T_MIN;
^~
wsutil/nstime.c:223:36: note: expanded from macro 'TIME_T_MIN'
: ~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1)))
   ^
wsutil/nstime.c:236:25: warning: shifting a negative signed value is 
undefined [-Wshift-negative-value]
time_t l_time_max = TIME_T_MAX;
^~
wsutil/nstime.c:226:46: note: expanded from macro 'TIME_T_MAX'
#define TIME_T_MAX ((time_t) (~ (time_t) 0 - TIME_T_MIN))
 ^~
wsutil/nstime.c:223:36: note: expanded from macro 'TIME_T_MIN'
: ~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1)))
   ^

Looking a bit further in the code, I became a bit confused on what is
going on in nstime.c. There is a magic "fixup" constant and some special
handling for the largest and smallest time_t values.

The comments suggest that it is based on Samba code, but their latest
version[1] is much simpler:

#ifndef TIME_T_MIN
/* we use 0 here, because (time_t)-1 means error */
#define TIME_T_MIN 0
#endif

/*
 * we use the INT32_MAX here as on 64 bit systems,
 * gmtime() fails with INT64_MAX
 */
#ifndef TIME_T_MAX
#define TIME_T_MAX MIN(INT32_MAX,_TYPE_MAXIMUM(time_t))
#endif

/* 64 bit time (100 nanosec) 1601 - cifs6.txt, section 3.5, page 30, 4 byte 
aligned */
typedef uint64_t NTTIME;

and the conversion method[2]:

/**
put a 8 byte filetime from a time_t
This takes GMT as input
**/
_PUBLIC_ void unix_to_nt_time(NTTIME *nt, time_t t)
{
uint64_t t2;

if (t == (time_t)-1) {
*nt = (NTTIME)-1LL;
return;
}

if (t == TIME_T_MAX || t == INT64_MAX) {
*nt = 0x7fffLL;
return;
}

if (t == 0) {
*nt = 0;
return;
}

t2 = t;
t2 += TIME_FIXUP_CONSTANT_INT;
t2 *= 1000*1000*10;

*nt = t2;
}

Shouldn't we do the same then? (Guy?)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

 [1]: https://github.com/samba-team/samba/blob/master/lib/util/time.h#L31
 [2]: https://github.com/samba-team/samba/blob/master/lib/util/time.c#L136
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Use of variadic macros

[Peter Wu]

On Thu, Oct 01, 2015 at 10:15:12AM -0700, Guy Harris wrote:
> 
> On Oct 1, 2015, at 9:53 AM, Alexis La Goutte <alexis.lagou...@gmail.com> 
> wrote:
> 
> > Yes, there is a "warning" with GCC from some month...
> > 
> > ../../epan/proto.h:2740:54: warning: anonymous variadic macros were 
> > introduced in C99 [-Wvariadic-macros]
> 
> Perhaps we need to turn on the "use C99" flag for some compilers,
> including, but not limited to, GCC-compatible compilers, to suppress
> warnings or even errors.

The feature seems supported even in c90 mode on gcc 5.2.0 and clang
3.7.0. After reading the gcc manual page, I've decided to settle with
-Wno-variadic-macros.

Patch is at https://code.wireshark.org/review/10781
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

[Peter Wu]

Hi Bernard,

On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
> The  package for vivid 64 bit works without issue though.
> 
> I just compiled 2.01 from source and it didn't crash.

Can you please post the outptu of:

tshark -G currentprefs | grep gui.layout_type

If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
crashes, then maybe some memory is scribbled. Can you try to reproduce
the issue with a clean configuration? Example:

HOME=/tmp/wshome wireshark
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Automated Windows build setup? (Chocolatey?)

[Peter Wu]

Hi,

Has there been any progress/work on an automated Windows environment
setup? On Debian/Ubuntu it is as easy as "apt-get build-dep wireshark".
Chocolatey seems the way to go, although it does not seem to check file
integrity.

Attached is what I use to provision a clean Windows 7 x64 VM with
Chocolatey installed (rename to .cmd). Now I am kind of stuck with
getting Qt5(.3.1) automatically installed for x64 msvc2013, Chocolatey
has no such package (only for x86).

Does anyone have a better automated tool to setup a Wireshark
development environment for Windows? The last message I see about a
script is from 2013
(https://www.wireshark.org/lists/wireshark-dev/201312/msg00041.html).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
@echo off
Z:

:: 2015-11-04
:: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

::chocolatey feature enable -n allowGlobalConfirmation

:: 2.2.1 Powershell 2.0 is required, win7 includes is already.

:: 2.2.2
:: TODO Install chocolaty

echo 2.2.3 MSVC
:: approved version:12.0.21005.1 (2014-11-24)
:: unapproved version:  12.0.31101.0 (2015-06-24)
cinst -y VisualStudioCommunity2013 -version 12.0.31101.0

:: 2.2.4 Qt
:: TODO file not found ?!!!
::cinst -y qt-sdk-windows-x86-msvc2013_opengl -version 5.3.2
::cinst -y qt-sdk-windows-x64-msvc2012_opengl -version 5.3.2
:: svn co https://anonsvn.wireshark.org/wireshark-win32-libs/trunk/packages/ 
wireshark-win32-libs
:: svn co https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/ 
wireshark-win64-libs

echo 2.2.5 Cygwin
cinst -y cygwin -version 2.2.1
:: what about cyg-get or sed asciidoc ... -source cygwin?
cinst -y winflexbison -version 2.4.3.20140715

echo 2.2.6 Python2
cinst -y python2 -version 2.7.10

echo 2.2.7 Git (optional)
cinst -y git -version 2.6.2

:: 2.2.8 Install and prepare sources
:: Assume git at Z:\wireshark\

:: README.cmake step 0
echo README.cmake step 0 cmake (minver 3.1.3)
cinst -y cmake -version 3.1.3

:: 2.2.9 set env / README.cmake step 1
::wsenv.cmd

:: README.cmake step 2+3
::cd \wireshark
::mkdir build
::cd build

:: README.cmake step 4
::cmake -G "Visual Studio 12 Win64" ..

:: README.cmake step 5
::msbuild /m /p:Configuration=RelWithDebInfo wireshark.sln
set CYGWIN=nodosfilewarning
set WIRESHARK_BASE_DIR=Z:\
::set WIRESHARK_TARGET_PLATFORM=win32
set WIRESHARK_TARGET_PLATFORM=win64
::set QT5_BASE_DIR=C:\Qt\5.4.1\5.4\msvc2013_opengl
set QT5_BASE_DIR=C:\Qt\Qt5.3.0\5.3\msvc2013
set PLATFORM=x64

:: Need vcvarsall as last because it uses "goto:eof"
::"\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Automated RPM-based-Linux build setup? (was Re: Automated Windows build setup? (Chocolatey?))

[Peter Wu]

On Wed, Nov 25, 2015 at 02:51:18PM -0800, Guy Harris wrote:
> 
> On Nov 25, 2015, at 2:44 PM, Guy Harris <g...@alum.mit.edu> wrote:
> 
> > On Nov 25, 2015, at 11:01 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> > 
> >> Has there been any progress/work on an automated Windows environment
> >> setup? On Debian/Ubuntu it is as easy as "apt-get build-dep wireshark".
> > 
> > Speaking of automated build setups:
> > 
> > A quick look at the DNF man page on Fedora 23 doesn't seem to
> > indicate that there's any equivalent to build-dep, i.e. nothing to
> > find out what are the *source* packages for the dependencies of a
> > binary package, and installing *them*.
> > 
> > For RPM, is there not a way to say "what packages are required to
> > build this possibly-not-installed package?"
> > ("Possibly-not-installed" is significant here - somebody might not
> > have Wireshark installed from the repository, and might want to
> > build it from source without having to build and install all its
> > dependencies from source.)
> > 
> > I.e., for a package in the repository (whether it's installed or
> > not), what packages are mentioned in the BuildRequires entries for
> > that package?
> 
> Actually, that's *not* necessarily what we want; what we *really* want
> is probably "what packages are mentioned in the BuildRequires entries
> in the packaging/rpm/SPECS/wireshark.spec.in file in the Wireshark
> source directory?", as the packaged Wireshark for your OS might
> require different packages from what the Wireshark source you're
> trying to build does (for example, if the packaged Wireshark uses GTK+
> but you want to build a 2.x release).
> 
> That would require the ability to parse an RPM spec file - and to
> expand some or all of @AC_MIN_VERSION@, @GLIB_MIN_VERSION@,
> @QT_MIN_VERSION@, @GTK3_MIN_VERSION@, and @GTK2_MIN_VERSION@ without
> having the autotools installed, as the point of that setup is to
> install stuff automatically, including the autotools.

For a CentOS6 VM I used tools/install_rpms_for_devel.sh to find
dependencies, that was mostly sufficient for me. There are some other
deps that were not installed though, but cmake warned me about it. Those
extra packages (for GTK+ 2) are:

 portaudio-devel libnl3-devel krb5-devel geoip-devel libcap-devel
 gnutls-devel 

on top of:

 yum -y install autoconf automake libtool gcc flex bison python perl \
  glib2-devel libpcap-devel zlib-devel lua-devel c-ares-devel \
  gtk3-devel gtk2-devel qt-devel gcc-c++ fop asciidoc git

I also had to install epel-release for something (bash-completion),
maybe it was also needed for one of the above packages.

Usage of "apt-get build-dep" relied on the existing packaging of Debian.
That is a good start to discover most dependencies, if there is anything
missing (libssh), it is reported during the cmake/configure step. I
guess something like this also applies to RPM (though distro-supplied
RPM packages packages seem really ancient, at least for Cent OS).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

[Peter Wu]

On Sun, Jan 10, 2016 at 11:52:39AM +0100, Bálint Réczey wrote:
> Hi,
> 
> 2016-01-09 16:40 GMT+01:00 Peter Wu <pe...@lekensteyn.nl>:
> > Hi Bernard,
> >
> > On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
> >> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
> >> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
> >> The  package for vivid 64 bit works without issue though.
> >>
> >> I just compiled 2.01 from source and it didn't crash.
> >
> > Can you please post the outptu of:
> >
> > tshark -G currentprefs | grep gui.layout_type
> >
> > If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
> > crashes, then maybe some memory is scribbled. Can you try to reproduce
> > the issue with a clean configuration? Example:
> >
> > HOME=/tmp/wshome wireshark
> I have reproduced the issue in a clean Wily VM.
> And did short triaging:
> 
> #4  0x5653770ef3e3 in main_widgets_rearrange () at
> /home/vagrant/wireshark-2.0.1+g59ea380/ui/gtk/main.c:3491
> 3491g_assert_not_reached();
> (gdb) p prefs.gui_layout_type
> $1 = layout_unused
> 
> Recompilation does not help and the preferences file is not created.
> 
> The Qt version and tshark start fine.

Can you try this fix (for master, but should be backported too):
https://code.wireshark.org/review/13154

It also means that somehow the gui.layout_type field was set to 0... But
the default on master-2.0 is:

epan/prefs.c:3032:prefs.gui_layout_type = layout_type_5;

Does Ubuntu include a default prefs file having gui.layout_type:0?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe