On Tue, Nov 4, 2014 at 3:52 PM, Sara fahman fflloorr...@gmail.com wrote:
I'm trying to learn how this function works and I have some questions (I
placed them below its following definition).
static void
ssl_parse_uat(void)
{
wmem_stack_t *tmp_stack;
guint i;
https://code.wireshark.org/review/527 has been bouncing around since
March; I think the current version is ready to go (and it's only a
handful of lines changed) but I'd appreciate if somebody else could
take a look before it falls off the edge of the map for 4th time.
Cheers,
Evan
The two most recent seem to be missing bugs that I can see:
http://buildbot.wireshark.org/trunk/builders/Clang%20Code%20Analysis/builds/3001
http://buildbot.wireshark.org/trunk/builders/Clang%20Code%20Analysis/builds/3002
___
Those lines were added earlier this year by Guy Martin (who I've
explicitly copied on this email). The justification in the commit
message at the time was:
If an mp2t packet contains one full subpacket and the fragment of
another one, it happens that the first subpacket will set src or dst to
an
:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=45fb37718e4d887b2a4087f5e5996cbe2e3a3a0b
Submitter: Evan Huus (eapa...@gmail.com)
Changed: branch: master
Repository: wireshark
Commits:
45fb377 by Evan Huus (eapa...@gmail.com):
Fix lua bindings to handle timestamp
On Mon, Sep 29, 2014 at 11:48 AM, Jeff Morriss
jeff.morriss...@gmail.com wrote:
On 09/29/14 08:58, Evan Huus wrote:
Hmmm, the buildbot lua test suite is still failing even with this
change, and it's no longer clear to me what the problem is. Hadriel,
do you have any ideas off the top of your
Since it looks like PIDL is also using git, how do people feel about
using git submodules instead of maintaining our own copy of PIDL?
On Fri, Sep 26, 2014 at 3:02 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Fri, Sep 26, 2014 at 3:19 PM, Alexis La Goutte
alexis.lagou...@gmail.com wrote:
On Fri, Sep 26, 2014 at 9:12 PM, Evan Huus eapa...@gmail.com wrote:
Since it looks like PIDL is also using git, how do people feel about
using git submodules instead of maintaining our own copy of PIDL?
How
On Fri, Sep 26, 2014 at 3:59 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 09/26/14 15:19, Alexis La Goutte wrote:
On Fri, Sep 26, 2014 at 9:12 PM, Evan Huus eapa...@gmail.com wrote:
Since it looks like PIDL is also using git, how do people feel about
using git submodules instead
Anybody know why they started? It happened on one of my commits, but
as far as I can tell the error is
'C:\cygwin\bin\python2' is not recognized as an internal or
external command,
which doesn't look related to my changes...
On Thu, Sep 25, 2014 at 2:48 PM, Gerald Combs ger...@wireshark.org wrote:
On 9/25/14 10:59 AM, Graham Bloice wrote:
On 25 September 2014 18:54, Evan Huus eapa...@gmail.com
mailto:eapa...@gmail.com wrote:
Anybody know why they started? It happened on one of my commits, but
as far as I
There is a script in git called macosx-setup.sh which will take a
while to run but should install all the needed tools, dependencies,
etc.
On Tue, Sep 23, 2014 at 4:45 PM, Anders Broman a.broma...@gmail.com wrote:
Hi,
I just got may hands on a MAC book Pro, how do you set it up to build
On Wed, Sep 10, 2014 at 5:16 PM, Martin Kaiser li...@kaiser.cx wrote:
Thanks for fixing this, I missed the buildbot error.
Would there be any chance to include OS X in the petri dish? I tried
this before pushing and saw no issues on Windows and Linux.
It would be difficult because Amazon AWS
://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=f9bfa976e67da2f8065f172de9ed06fad61762a8
Submitter: Evan Huus (eapa...@gmail.com)
Changed: branch: master
Repository: wireshark
Commits:
f9bfa97 by Evan Huus (eapa...@gmail.com):
Explicitly lengthen some constants to 64 bits
On Wed, Sep 3, 2014 at 2:11 PM, bugzilla-dae...@wireshark.org wrote:
Jeff Morriss jeff.morriss...@gmail.com changed bug 10442
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10442
What Removed Added Status UNCONFIRMED RESOLVED Resolution --- FIXED
*Comment # 3
On Sep 2, 2014, at 2:13, Roland Knall rkn...@gmail.com wrote:
Hi
I have a more general question: At what point do you stop carrying about
false-positives with a heuristic filter?
Historically it's been when people stop filing bug reports. I haven't seen
any bug reports of type my
Unfortunately it's been written in stone at this point. There is
basically no way to modify history for a widely-distributed project
like this (amending that commit would cause all sorts of conflicts for
everybody who has a copy of the current git repository).
The best we can do is probably add a
On Sun, Aug 31, 2014 at 6:27 PM, Evan Huus eapa...@gmail.com wrote:
On Sun, Aug 31, 2014 at 6:24 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 31, 2014, at 3:10 PM, Gerald Combs ger...@wireshark.org wrote:
docbook/Makefile.nmake was copied from docbook/Makefile.am in g7e4b82a.
It looks like
On Sun, Aug 31, 2014 at 6:24 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 31, 2014, at 3:10 PM, Gerald Combs ger...@wireshark.org wrote:
docbook/Makefile.nmake was copied from docbook/Makefile.am in g7e4b82a.
It looks like the chmods were added in g7d7a541, perhaps to make sure
the
On Wed, Aug 27, 2014 at 5:55 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 27, 2014, at 2:28 PM, Evan Huus eapa...@gmail.com wrote:
I still get warnings-turned-errors when building with cmake with this change:
../../asn1/kerberos/packet-kerberos-template.c:299:9: error:
'krb5_init_context
On master, cmake seems to still be building wireshark for gtk and
qtshark for qt. Should that be wireshark for qt and
wireshark-gtk or wireshark-legacy for gtk?
___
Sent via:Wireshark-dev mailing list
I still get warnings-turned-errors when building with cmake with this change:
../../asn1/kerberos/packet-kerberos-template.c:299:9: error:
'krb5_init_context' is deprecated: use GSS.framework
[-Werror,-Wdeprecated-declarations]
Is there anything I need to tweak in the cmake files somewhere?
On
On Wed, Aug 27, 2014 at 5:28 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 08/27/14 16:57, Evan Huus wrote:
On master, cmake seems to still be building wireshark for gtk and
qtshark for qt. Should that be wireshark for qt and
wireshark-gtk or wireshark-legacy for gtk?
Or wireshark
Gerald, dunno if this is possible or not, but the Gerrit integration
probably shouldn't be marking bugs as FIXED when they've already been
resolved into some other state...
Don't think it's a big deal though, just seems odd.
Evan
-- Forwarded message --
From:
Probably they are simply not installing the hook - none of our tooling
sets it up by default that I'm aware of.
On Mon, Aug 25, 2014 at 1:06 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
When reviewing some submissions on Gerrit, I've noted a few with trailing
whitespace. The git
On Mon, Aug 25, 2014 at 1:21 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 25 August 2014 18:17, Graham Bloice graham.blo...@trihedral.com wrote:
On 25 August 2014 18:11, Juan Jose Martin Carrascosa jua...@rti.com
wrote:
I think that you are talking about my just committed changes.
If things are working normally, it will get picked up automatically.
On Mon, Aug 25, 2014 at 3:37 PM, Stalley, Sean sean.stal...@intel.com wrote:
Hello All,
I have a trace that I would like to add to the buildbot for regression
testing. I uploaded it here:
http://blog.qt.digia.com/blog/2014/08/20/adding-lgpl-v3-to-qt/
I don't *think* this affects us, but I haven't thought about it too hard.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:
Frankly, conversation structures shouldn't have per-packet data in
them at all; this was probably the easiest way to fix the fuzz
failure, but it really seems odd to me that it even needs to be done.
Thoughts?
On Tue, Aug 19, 2014 at 4:20 PM, Wireshark code review
Guy, how are you finding these last four or five API abuses? Do you
have some sort of super-checkAPIs or are you just doing a lot of
manual code review?
On Mon, Aug 18, 2014 at 3:44 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Mon, Aug 18, 2014 at 4:31 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 18, 2014, at 12:46 PM, Evan Huus eapa...@gmail.com wrote:
Guy, how are you finding these last four or five API abuses? Do you
have some sort of super-checkAPIs or are you just doing a lot of
manual code review
On Mon, Aug 18, 2014 at 5:06 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 08/18/14 16:45, Evan Huus wrote:
On Mon, Aug 18, 2014 at 4:31 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 18, 2014, at 12:46 PM, Evan Huus eapa...@gmail.com wrote:
Guy, how are you finding these last four
Looks like we now work on Wine?
https://www.winehq.org/wwn/373#Why%20a%20WPcap%20wrapper?
Evan
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
On Fri, Aug 15, 2014 at 3:36 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 15 August 2014 20:17, Jeff Morriss jeff.morriss...@gmail.com wrote:
Hi folks,
One thing I've noticed about the Petri-Dish flag in Gerrit is that every
time I set it to +1 I get an error saying needs code
On Fri, Aug 15, 2014 at 4:07 PM, Gerald Combs ger...@wireshark.org wrote:
On 8/15/14 12:17 PM, Jeff Morriss wrote:
Hi folks,
One thing I've noticed about the Petri-Dish flag in Gerrit is that every
time I set it to +1 I get an error saying needs code review. Since
Chris just noticed and
On Tue, Aug 12, 2014 at 2:20 PM, Sponaugle, Cindy J
cindy.j.sponau...@boeing.com wrote:
is the source code for Wireshark considered to be EAR regarding export
controlled information? We are wanting to classify our software and we have
some source code developed using Wireshark. If we send
There have been repeated fuzzing failures over the last day that
haven't resulted in bugs. Result of the bugzilla upgrade?
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:
On Aug 10, 2014, at 21:43, Ed Beroset bero...@mindspring.com wrote:
-Original Message-
From: Kevin Cox kevin...@kevincox.ca
Sent: Aug 9, 2014 4:05 PM
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] How to support wireshark
On Aug 10, 2014, at 7:06, Bálint Réczey bal...@balintreczey.hu wrote:
Hi Evan,
2014-08-10 4:41 GMT+02:00 Evan Huus eapa...@gmail.com:
http://buildbot.wireshark.org/trunk/builders/Clang%20Code%20Analysis/builds/2911/steps/check-abi/logs/stdio
I took a quick look at the recent check-abi
.
Bug:8734
Change-Id: I4c456b45939c00a9d1122406891f704fa037349c
Reviewed-on: https://code.wireshark.org/review/3183
Reviewed-by: Evan Huus eapa...@gmail.com
Reviewed-by: Michael Mann mman...@netscape.net
Actions performed:
from 345a1d2 ISIS: Fix reachability IPv4
Per this comment, seems like it would be a good idea:
https://blog.wireshark.org/2014/07/wireshark-1-12-officially-released/comment-page-1/#comment-3385
Don't know much about the Windows installer though, this may not be possible?
http://buildbot.wireshark.org/trunk/builders/Clang%20Code%20Analysis/builds/2911/steps/check-abi/logs/stdio
I took a quick look at the recent check-abi buildbot failure, which
appears to be manpage related:
wireshark.pod around line 3525: Non-ASCII character seen before
=encoding in
On Mon, Aug 4, 2014 at 5:26 AM, Graham Bloice graham.blo...@trihedral.com
wrote:
On 4 August 2014 07:34, Alexis La Goutte alexis.lagou...@gmail.com
wrote:
Hi Evan,
On Mon, Aug 4, 2014 at 5:08 AM, Evan Huus eapa...@gmail.com wrote:
Gerrit currently displays the status of the Petri-Dish flag
One of the issues that's been popping up a lot recently is how to handle
packets that contain multiple records. The reason both those words are
in quotes is because there's some broader context and applications:
- Putting each application-layer PDU into its own record regardless of
higher-level
and display filter to actually *use* the data. If there's
consensus that this method of storing the data makes sense then I'll add
it, and you're free to use it however you want.
regards,
Roland
On Mon, Aug 4, 2014 at 9:56 PM, Evan Huus eapa...@gmail.com wrote:
One of the issues that's been popping
On Aug 4, 2014, at 17:11, Roland Knall rkn...@gmail.com wrote:
On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus eapa...@gmail.com wrote:
Right now you can't filter on field combinations that must appear together
in one of those application frames: if fieldA appears in frame 1, and fieldB
On Aug 4, 2014, at 17:21, Roland Knall rkn...@gmail.com wrote:
Am 04.08.2014 um 23:16 schrieb Evan Huus eapa...@gmail.com:
On Aug 4, 2014, at 17:11, Roland Knall rkn...@gmail.com wrote:
On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus eapa...@gmail.com wrote:
Right now you can't
On Sun, Aug 3, 2014 at 1:40 PM, Guy Harris g...@alum.mit.edu wrote:
I've noticed, on occasion, that sometimes the CMake builds on the UN*X
buildbots get warnings that the autotools builds don't.
Recently, I tried to figure out what was different about the CMake builds;
after some fixes that
On Sun, Aug 3, 2014 at 2:10 PM, Guy Harris g...@alum.mit.edu wrote:
On Aug 3, 2014, at 11:01 AM, Evan Huus eapa...@gmail.com wrote:
On Sun, Aug 3, 2014 at 1:40 PM, Guy Harris g...@alum.mit.edu wrote:
I've noticed, on occasion, that sometimes the CMake builds on the UN*X
buildbots get
On Sun, Aug 3, 2014 at 6:20 PM, Gerald Combs ger...@wireshark.org wrote:
On 8/3/14, 11:34 AM, Evan Huus wrote:
On Mon, May 13, 2013 at 7:54 PM, Gerald Combs ger...@wireshark.org
mailto:ger...@wireshark.org wrote:
On 5/10/13 1:47 PM, Evan Huus wrote:
Hi Gerald
I
Gerrit currently displays the status of the Petri-Dish flag in the
change-summary list as a PD column. I don't think it's particularly
useful, and it makes it harder to tell at a glance whether a change has
been verified or not (since the two columns are right next to each other so
you can't as
On Aug 1, 2014, at 5:12, Peter Wu pe...@lekensteyn.nl wrote:
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
On Fri, Aug 1, 2014 at 1:58 PM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
On 08/01/14 13:54, Guy Harris wrote:
On Aug 1, 2014, at 2:00 AM, Peter Wu pe...@lekensteyn.nl wrote:
On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl
On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org wrote:
On 8/1/14 9:08 AM, Jeff Morriss wrote:
On 07/13/14 14:05, Alexis La Goutte wrote:
On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org
On Fri, Aug 1, 2014 at 7:03 PM, Gerald Combs ger...@wireshark.org wrote:
On 8/1/14 3:58 PM, Evan Huus wrote:
On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org
mailto:ger...@wireshark.org wrote:
On 8/1/14 9:08 AM, Jeff Morriss wrote:
On 07/13/14 14:05, Alexis La
/
for me using cmake).
On Fri, Aug 1, 2014 at 9:00 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=6b11cd97f2153bb015ade6efd0592de85457
Submitter: Evan Huus (eapa...@gmail.com)
Changed: branch
This issue has been bugging me for a while, but I also haven't been able to
come up with a satisfactory solution.
On Thu, Jul 31, 2014 at 4:56 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
FWIW this issue also makes it impossible to run parts of the test suite
from an out-of-tree build, which can be problematic.
On Thu, Jul 31, 2014 at 4:56 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Tue, Jul 29, 2014 at 6:47 PM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
On 07/29/14 15:39, darkjames...@darkjames.pl wrote:
On Tue, Jul 29, 2014 at 09:18:18PM +0200, darkjames...@darkjames.pl
wrote:
Hi,
On Tue, Jul 29, 2014 at 08:33:57PM +0200, Martin Kaiser wrote:
I'm confused
On Sat, Jul 26, 2014 at 2:11 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 14, 2012, at 6:40 AM, jma...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40498
User: jmayer
Date: 2012/01/14 06:40 AM
Log:
Optionally build cmake, document why we
On Thu, Jul 24, 2014 at 2:42 PM, Bálint Réczey bal...@balintreczey.hu
wrote:
Hi Jakub,
2014-07-22 0:52 GMT+02:00 darkjames...@darkjames.pl:
Hi,
On Sat, Jul 12, 2014 at 02:27:06AM +0200, B??lint R??czey wrote:
I plan using ASAN for all programs which would catch (among others)
On Thu, Jul 24, 2014 at 4:35 PM, Kevin Cox kevin...@kevincox.ca wrote:
Hello All,
While working on the new Ceph dissector I made a mistake using
value_string_ext (herein evs) where I declared them 'const' which was
causing an error when they were put in a read-only segment of the
On Mon, Jul 21, 2014 at 2:22 AM, Anders Broman a.broma...@gmail.com wrote:
Den 21 jul 2014 02:34 skrev Evan Huus eapa...@gmail.com:
On Sun, Jul 20, 2014 at 8:25 PM, Guy Harris g...@alum.mit.edu wrote:
On Jul 20, 2014, at 5:04 PM, Evan Huus eapa...@gmail.com wrote:
I don't really
I don't really get this - it happens inconsistently that the fast
allocator takes longer to run than the block allocator. The fast
allocator does much less work, and runs substantially faster than the block
allocator everywhere I've tested it.
I don't know what glib's timing mechanism is like,
On Sun, Jul 20, 2014 at 8:25 PM, Guy Harris g...@alum.mit.edu wrote:
On Jul 20, 2014, at 5:04 PM, Evan Huus eapa...@gmail.com wrote:
I don't really get this - it happens inconsistently that the fast
allocator takes longer to run than the block allocator. The fast
allocator does much less
It should be as simple as
git review –d 3139
# make change
git commit -a --amend
git review
There's nothing special about changes uploaded by other users, so once you've
got the change in a branch (which is what -d does) the rest of the process is
pretty standard.
On Jul 20, 2014, at 22:49,
Hi GC, the current method to contribute lua dissectors is to create an account
on our wiki, and add them either as a link or an attachment to the page:
http://wiki.wireshark.org/Contrib
Evan
On Jul 17, 2014, at 2:45, wangguochao wangguocha...@cn.panasonic.com
wrote:
Dear Wireshark team:
Hi Maksym, please file bugs in our bug tracker:
https://bugs.wireshark.org/bugzilla/
It would also be helpful if you could check if the bug is still present in more
recent versions (such as the 1.12 release candidate).
Evan
On Jul 17, 2014, at 3:54, Maksym Galemin maksym.gale...@hydrix.com
.
Is the dissector written by pure Lua included? I hope we can share the
pure Lua dissector.
Yes, absolutely! That is exactly the kind of thing this page is for. There
is even a section for it already (Protocol Dissectors under Lua
Plugins).
Evan
Regards,
Kenjiro
Evan Huus writes:
One of the things we
be better so the version on the wiki doesn't get stale.
I don't think uploading many files is good idea.
[1] https://github.com/nak3/jgroups-wireshark-dissector
Regards,
Kenjiro
Evan Huus writes:
On Sun, Jul 13, 2014 at 8:14 PM, Kenjiro Nakayama nakayamakenj...@gmail.com
wrote:
One
On Fri, Jul 11, 2014 at 12:42 PM, Bill Meier wme...@newsguy.com wrote:
I've been working with the current 'pre-commit' and have noticed the
following issues:
1. Using the current pre-commit which calls checkAPIs, etc, it
doesn't seem possible to make changes to
certain files (e.g.,
On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org wrote:
On 7/7/14 9:10 PM, Evan Huus wrote:
On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte
alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote:
On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa
The biggest win, I think, would be if we can avoid calling free_chain at
all because tvbs are always allocated in the right scope and so get freed
automatically. I think this would involve touching every place that creates
new tvbs backed with glib memory though...
I will try and think about this
On Fri, Jul 11, 2014 at 12:42 PM, Bill Meier wme...@newsguy.com wrote:
I've been working with the current 'pre-commit' and have noticed the
following issues:
1. Using the current pre-commit which calls checkAPIs, etc, it
doesn't seem possible to make changes to
certain files (e.g.,
On Fri, Jul 11, 2014 at 5:12 PM, Bálint Réczey bal...@balintreczey.hu
wrote:
Hi All,
Please provide the input data for letting others reproduce the results
or perform the performance tests on pcap files already available to
the public.
I'm not a fan of implementing custom memory management
On Fri, Jul 11, 2014 at 4:08 PM, Evan Huus eapa...@gmail.com wrote:
The biggest win, I think, would be if we can avoid calling free_chain at
all because tvbs are always allocated in the right scope and so get freed
automatically. I think this would involve touching every place that creates
On Fri, Jul 11, 2014 at 6:07 PM, Anders Broman a.broma...@gmail.com wrote:
Den 11 jul 2014 23:13 skrev Bálint Réczey bal...@balintreczey.hu:
Hi All,
Please provide the input data for letting others reproduce the results
or perform the performance tests on pcap files already available
(sorry Balint for the double-post, I don't know why my reply button
dropped the mailing list)
-- Forwarded message --
From: Evan Huus eapa...@gmail.com
Date: Fri, Jul 11, 2014 at 9:05 PM
Subject: Re: [Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits]
master b6d20a2
On Fri, Jul 11, 2014 at 9:08 PM, Evan Huus eapa...@gmail.com wrote:
(sorry Balint for the double-post, I don't know why my reply button
dropped the mailing list)
-- Forwarded message --
From: Evan Huus eapa...@gmail.com
Date: Fri, Jul 11, 2014 at 9:05 PM
Subject: Re
We don't recommend it, we don't even advertise it in the docs, almost no
dissectors use it... Is there something wrong with it?
Evan
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:
On Wed, Jul 9, 2014 at 10:06 PM, mman...@netscape.net wrote:
I finished the conversion of proto_tree_add_text calls that were acting
as subtree labels into proto_tree_add_subtree[_format]. This removed
almost 4000 calls in the dissector directory (over 4000 if you include the
plugins) and
On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com
wrote:
On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com wrote:
On Sat, Jul 5, 2014 at 2:46 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
https://code.wireshark.org
On Sat, Jul 5, 2014 at 2:46 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=599b880e4c53613c243b0a39548968f34cdce0e3
Submitter: Guy Harris (g...@alum.mit.edu)
Changed: branch: master
Repository:
Currently we have Capture-Interfaces and Capture-Options which go to
different tabs of the same dialogue. Makes sense to merge them into one
entry?
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 30 juni 2014 23:19
To: Wireshark Developer List
Subject: [Wireshark-dev] Have tshark discard state when doing ring-buffer
capture
I was kind of expecting this change to generate more
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?
Additionally, it is not indexed. There is a
I was kind of expecting this change to generate more controversy, so I'll
give it another few days but if nobody objects I'll merge it then.
https://code.wireshark.org/review/2669
I don't currently plan on putting it in 1.12 so that we have a full dev
cycle to work out any subtle implications,
Good suggestion, and relatively easy to do. Code for review available at
https://code.wireshark.org/review/2693
Evan
On Sun, Jun 29, 2014 at 7:43 AM, Toralf Förster toralf.foers...@gmx.de
wrote:
/mew wonders if wireshark should print a warning if a http traffic goes
over port 443 (eg a TRAC
default to this (if ringbuffering is
enabled) or should it be an additional flag? If so, which flag?
Evan
[1] https://code.wireshark.org/review/2669
On Sun, Jun 22, 2014 at 8:47 PM, Evan Huus eapa...@gmail.com wrote:
On Sun, Jun 22, 2014 at 7:34 PM, Jakub Zawadzki darkjames...@darkjames.pl
stream_number still needs to be set to 1, not 0...
On Thu, Jun 26, 2014 at 1:47 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=b97d70d2a68418f74628a5ae3f3a1434233f13a5
Submitter: Gerald Combs
and related changes
be cherry-picked?
I don't know, possibly? Michal would probably have a better idea.
On 6/26/14 10:54 AM, Evan Huus wrote:
stream_number still needs to be set to 1, not 0...
On Thu, Jun 26, 2014 at 1:47 PM, Wireshark code review
code-review-do-not-re...@wireshark.org
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
With this change, the comment at wiretap/libpcap.c:769 is stale since it
still references 64KB. Not a major issue, but makes me wonder where else in
the code we've accidentally hardcoded that assumption... I guess we'll find
out :)
On Wed, Jun 25, 2014 at 4:27 PM, Wireshark code review
I would merge it with the main AUTHORS file (if there are any names
different) and remove it.
On Tue, Jun 24, 2014 at 10:13 PM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
I just noticed that there's an AUTHORS file in wiretap/. It looks old and
significantly incomplete/out of date.
I would *really* prefer we didn't do this.
On Mon, Jun 23, 2014 at 11:30 AM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9079e3ad1d32c594309a52ccef5936d11a93a55d
Submitter: Anders Broman
...@balintreczey.hu:
Hi,
2014-06-23 17:54 GMT+02:00 Evan Huus eapa...@gmail.com:
I would *really* prefer we didn't do this.
Me, too. Going this way makes maintaining Wireshark really hard. And
for 1% speed increase in a very specific case
Well even small changes adds up...
I'd think Sip would
On Mon, Jun 23, 2014 at 1:50 PM, Anders Broman a.broma...@gmail.com wrote:
Den 23 jun 2014 19:08 skrev Evan Huus eapa...@gmail.com:
I have nothing against the change in general, as long as we do it by
adding only the original .gperf file to git and run gperf during build to
generate C
On Mon, Jun 23, 2014 at 4:22 PM, Jakub Zawadzki darkjames...@darkjames.pl
wrote:
Hello Evan,
On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
Storing generated files in source control makes maintenance and patch
review much harder and puts extra requirements on us to keep things
On Mon, Jun 23, 2014 at 4:32 PM, Pascal Quantin pascal.quan...@gmail.com
wrote:
Hi all,
Le 23/06/2014 22:22, Jakub Zawadzki a écrit :
Hello Evan,
On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
Storing generated files in source control makes maintenance and patch
review
Perhaps this is a discussion we should have had at Sharkfest, but it's come
up now. Oh well.
My objections to generated code in git are two-fold: practical and
philosophical.
Practically, it's painful to have to run make twice to test ASN.1 changes.
It's painful to review diffs full of #line
101 - 200 of 824 matches
Mail list logo
