On Mon, Jun 23, 2014 at 5:32 PM, Guy Harris g...@alum.mit.edu wrote:
On Jun 23, 2014, at 2:06 PM, Evan Huus eapa...@gmail.com wrote:
As far as I can see, the main arguments for storing generated code in
git are:
- not all platforms have the tools necessary to generate the code
On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman a.broma...@gmail.com wrote:
-- Vidarebefordrat meddelande --
Från: Evan Huus eapa...@gmail.com
Datum: 24 jun 2014 00:14
Ämne: Re: [Wireshark-dev] Storing Generated Code in Git [Was: master
9079e3a: Cheat and try to fix
On Jun 23, 2014, at 23:03, Anders Broman a.broma...@gmail.com wrote:
Den 24 jun 2014 03:18 skrev Evan Huus eapa...@gmail.com:
On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman a.broma...@gmail.com wrote:
-- Vidarebefordrat meddelande --
Från: Evan Huus eapa
After Kurt's recent post I dug up an old patch I'd played with and cleaned
it up a bit. It still needs some work (documentation at the very least) but
[1] should add a -Z option to tshark which turns on stateless dissection.
You lose reassembly and all that, but you should get no memory growth at
On Sun, Jun 22, 2014 at 5:25 PM, Jakub Zawadzki darkjames...@darkjames.pl
wrote:
Hi Evan,
On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote:
The implementation is a bit of a hack in that stateless dissection still
does all the stateful work, it just throws it away after each packet
On Sun, Jun 22, 2014 at 6:05 PM, Joerg Mayer jma...@loplof.de wrote:
On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote:
After Kurt's recent post I dug up an old patch I'd played with and
cleaned
it up a bit. It still needs some work (documentation at the very least)
but
[1
On Sun, Jun 22, 2014 at 6:43 PM, Kurt Knochner
ws.dev.l...@nospam.knochner.com wrote:
Zitat von Joerg Mayer jma...@loplof.de:
What I am thinking about is something like keeping state but only for the
last 1000 (insert your favourite number here) packets and only *then*
throwing it away.
On Sun, Jun 22, 2014 at 7:34 PM, Jakub Zawadzki darkjames...@darkjames.pl
wrote:
On Sun, Jun 22, 2014 at 05:45:45PM -0400, Evan Huus wrote:
On Sun, Jun 22, 2014 at 5:25 PM, Jakub Zawadzki
darkjames...@darkjames.pl
wrote:
On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote
One of the things we discussed at Sharkfest this year was providing a
common location for users to share their lua scripts, colouring rules,
display filter macros, and other useful plugins.
Discussion is still on-going as to whether we will provide a proper git
repository or some other management
On Thu, Jun 19, 2014 at 12:16 PM, Guy Harris g...@alum.mit.edu wrote:
On Jun 19, 2014, at 11:26 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=14824e6adf07a1c3cfb6537ce8723d873ecd0d0f
Another possible improvement, rather than g_mallocing the elements in the
hash table, we could put them in the pinfo pool, which is always freed when
proto_tree_reset or proto_tree_free are called...
On Thu, Jun 19, 2014 at 4:33 PM, Wireshark code review
code-review-do-not-re...@wireshark.org
If they're distinct changes on a single branch (so they're related, but
make sense as individual commits in the final repo) then #2. Gerrit might
warn you, but I think it will let you do it as long as you confirm you mean
it.
On Wed, Jun 18, 2014 at 12:35 AM, Dario Lombardo
Though I would note that if there are large swaths of an API that haven't
been converted yet, that's an indicator that it's not as simple as a
search-and-replace, so please don't just submit large changes like that,
since it will likely break things in a subtle way (since the new/old APIs
behave
We have at least 30 bugs to do with RTP and the analysis/audio player:
https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp
Do we have a plan for the Qt equivalent of this UI? Is it worth doing, or
should we hand it off to the OS's media player (gstreamer or similar) or...?
I would
On Tue, Jun 17, 2014 at 10:10 AM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
On 06/17/14 12:11, Dario Lombardo wrote:
Hi list
I'm having a look at obsolete APIs and I've got those lines from
checkAPI.pl
Warning: Found soft-deprecated APIs in packet-bacapp.c: ep_address_to_str
Warning:
On Mon, Jun 16, 2014 at 8:00 AM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
[I merged a couple of forks of this thread to show more history before
responding.]
On 06/15/14 10:51, Richard Sharpe wrote:
Le 15/06/2014 14:02, Jeff Morriss a écrit :
On Sun, Jun 15, 2014 at 4:31 AM, wsgd
Different projects use Git in different ways (merging vs rebasing etc).
Wireshark's process is semi-documented at
http://wiki.wireshark.org/Development/SubmittingPatches. If you have
specific questions feel free to ask.
On Sun, Jun 15, 2014 at 10:55 AM, Richard Sharpe
On Jun 9, 2014, at 4:02 AM, Anders Broman anders.bro...@ericsson.com wrote:
Hi,
As can be seen we have managed to make a significant improvement from 1.10.6
wireshark 1.10.6 (v1.10.6 from master-1.10)
==44865== Callgrind, a call-graph generating cache profiler
==44865== Copyright (C)
On Wed, Jun 4, 2014 at 12:12 PM, Kevin Cox kevin...@kevincox.ca wrote:
On 04/06/14 10:24, Anders Broman wrote:
One option is to read the bytes from the tvb to a buffer manipulate the
bytes and make a new tvb with the manipulated bytes in the buffer and then
dissect that new tvb.
Like
You should be able to set the WIRESHARK_ABORT_ON_DISSECTOR_BUG environment
variable as documented in the man page.
Evan
On Wed, Jun 4, 2014 at 5:27 PM, Richard Sharpe realrichardsha...@gmail.com
wrote:
Hi,
I am getting all these failed assertions, but I would rather get a
crash so I can
. I guess I should figure out why it needed tweaking in
the first place, but my knowledge of CMake is pretty limited at this point.
H.sivank
Le 3 juin 2014 à 00:21, Evan Huus eapa...@gmail.com a écrit :
On Mon, Jun 2, 2014 at 1:24 PM, hsivank hsiv...@gmail.com wrote:
If libmodule-2.0.dylib
On Tue, Jun 3, 2014 at 1:07 PM, Richard Sharpe realrichardsha...@gmail.com
wrote:
Hi folks,
I have to get a plugin that was developed a while ago converted to wmem.
Is there a single document that describes the conversion process?
There isn't a conversion guide specifically, but
Just create it once in the init routine, rather than when the first uuid is
registered? Then you can guarantee it always exists.
On Tue, Jun 3, 2014 at 2:01 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Tue, Jun 3, 2014 at 2:19 PM, Pascal Quantin pascal.quan...@gmail.com
wrote:
Hi Evan,
2014-06-03 20:09 GMT+02:00 Evan Huus eapa...@gmail.com:
Just create it once in the init routine, rather than when the first uuid
is registered? Then you can guarantee it always exists.
This is what I
I'm trying to get an out-of-tree cmake build set up on a brand new mac.
Cmake and the compiler seem to be working fine, but I'm having issues at
link time. Specifically, I keep getting:
ld: library not found for -lgmodule-2.0
clang: error: linker command failed with exit code 1 (use -v to see
reason those paths aren't making it into the final command
being run...
H.sivank
Le 2 juin 2014 à 18:52, Evan Huus a écrit :
I'm trying to get an out-of-tree cmake build set up on a brand new mac.
Cmake and the compiler seem to be working fine, but I'm having issues at
link time. Specifically
Somebody will review it and either:
- provide comments if it needs work
- +2 and merge it if they like it
- +1 if they like it but want a second opinion
In any case, Gerrit will send you an email when something happens. I see
your review in the queue, but nobody's had a chance to look at it yet.
I assume that there was no other output (no logging or anything)? On my
reading of the dump, most of the time is spent manipulating strings due to
logging from the g_log function. The main caller seems to be
capture_loop_write_packet_cb, so removing the logging call at
dumpcap.c:4051 might be
[
mailto:wireshark-dev-boun...@wireshark.orgwireshark-dev-boun...@wireshark.org]
*On Behalf Of *Evan Huus
*Sent:* den 8 maj 2014 18:24
*To:* Developer support list for Wireshark
*Subject:* Re: [Wireshark-dev] Profiled dumpcap
I assume that there was no other output (no logging or anything)? On my
Is there anybody who knows BER dissection well (specifically BER choice)
who wants to verify for me that [1] is a coherent thing to do and doesn't
break dissection?
Thanks,
Evan
[1] https://code.wireshark.org/review/1530
___
: windows-xp-x86
Build Reason: scheduler
Build Source Stamp: [branch master]
402bbcbd05cf50b2c3db565e54cf9012ab5b5db2
Blamelist: Evan Huus eapa...@gmail.com
BUILD FAILED: failed test.sh
sincerely,
-The Buildbot
in wmem_test.exe. I closed them and it appears to run fine
now. Process Explorer didn't show any unusual memory usage when I ran
the test by hand.
On 5/5/14 6:14 AM, Evan Huus wrote:
I'm really not sure what's causing the wmem test suite to hang like this
(and only on XP...) - the lack of additional
As of gfbd3c937989c7622815d3019538ca4b7d5a58e27 the cmake build fails if
you specify an optional dependency (such as libsbc) and it can't be found.
This is causing the buildbot cmake step to fail, since it specifies both
YAPP and SBC, which are not present.
I'm not sure how autofoo behaves here;
On Apr 26, 2014, at 10:18 PM, mman...@netscape.net wrote:
I have found myself from time to time needing to temporarily disable the
pre-commit hook (ie error is ignorable). The situation I ran into today I
don't think should have been.
I created a patch that removed a header file
On Apr 25, 2014, at 1:18 AM, Jaap Keuter jaap.keu...@xs4all.nl wrote:
On 04/04/2014 10:11 PM, Evan Huus wrote:
On Fri, Apr 4, 2014 at 4:08 PM, Guy Harris g...@alum.mit.edu wrote:
On Apr 4, 2014, at 9:21 AM, Herb Falk h...@sisconet.com
h...@sisconet.com wrote:
No, I just wanted
On Thu, Apr 24, 2014 at 5:47 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 04/23/2014 11:57 AM, Wireshark code review wrote:
URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=fe195c0c978b4b92dc5a77daa6449a7f1314243d
Submitter: Evan Huus (eapa...@gmail.com
On Fri, Apr 25, 2014 at 5:40 PM, Evan Huus eapa...@gmail.com wrote:
On Thu, Apr 24, 2014 at 5:47 PM, Jeff Morriss jeff.morriss...@gmail.com
wrote:
On 04/23/2014 11:57 AM, Wireshark code review wrote:
URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h
On Fri, Apr 25, 2014 at 6:13 PM, Guy Harris g...@alum.mit.edu wrote:
On Apr 25, 2014, at 2:48 PM, Evan Huus eapa...@gmail.com wrote:
I think conceptually what we need is a way to say this item isn't
associated with any bytes at all, so don't do any bounds checks etc.
Negative offsets
at 4:20 AM, Evan Huus eapa...@gmail.com wrote:
The DTLS decryption test has been failing for the last few days
because of this. Not sure what the relation is, but...
When try to look the output of DTLS decryption test, it is empty (and
use HTTP filter..)
env $TS_DC_ENV $TSHARK $TS_DC_ARGS
On Wed, Apr 23, 2014 at 9:11 AM, Anders Broman
anders.bro...@ericsson.com wrote:
In my benchmarks it is measurably slower than GHashTable, but not
excessively
so. Given the additional security it provides this seems like a
reasonable
trade-off (and it is still faster than a
[mailto:wireshark-core-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 22 april 2014 05:36
To: Wireshark core developers
Subject: Re: [Wireshark-core] Hash Tables and Algorithmic Complexity Attacks
On Mon, Apr 21, 2014 at 6:28 PM, Balint Reczey rbal...@gmail.com wrote:
On Apr 22, 2014 12:11 AM
The DTLS decryption test has been failing for the last few days
because of this. Not sure what the relation is, but...
On Sun, Apr 20, 2014 at 8:40 AM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman
anders.bro...@ericsson.com wrote:
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bálint Réczey
Sent: den 17 april 2014 09:59
To: Gerald Combs
Cc: Developer
Is the AsciiDoc WIP change at https://code.wireshark.org/review/#/c/9/
still active or should it be abandoned? It's seen no uploads in 2
months...
Evan
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
On Thu, Apr 17, 2014 at 6:58 PM, Bálint Réczey bal...@balintreczey.hu wrote:
2014-04-17 23:21 GMT+02:00 Evan Huus eapa...@gmail.com:
On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman
anders.bro...@ericsson.com wrote:
-Original Message-
From: wireshark-dev-boun...@wireshark.org
On Tue, Apr 15, 2014 at 1:57 PM, David Ameiss netsh...@ameissnet.com wrote:
I could be wrong, but I could swear that, until recently, conversations
essentially had capture lifetime. So that, from one pass of the capture to
the next, the conversations (and any proto data stored in them)
On Mon, Apr 14, 2014 at 2:49 PM, Gerald Combs ger...@wireshark.org wrote:
On 4/11/14 7:35 PM, mman...@netscape.net wrote:
I've seen a handful of patches submitted to Gerrit with [WIP] in the
title. Obviously this means work in progress, but what does it mean
for reviewers of the patch?
Ya, it's usable in 1.10 though it's not as efficient or featureful. It couldn't
fully replace emem at that point, but for one-off use (backporting?) it should
work just fine.
Switching it back to emem would also probably work with no ill-effects.
Whatever's easier.
Evan
On Apr 10, 2014, at
On Wed, Apr 9, 2014 at 7:49 PM, Guy Harris g...@alum.mit.edu wrote:
Should this chunk of code:
if (tree) {
if (type (payload_length = record_length - 16 - 3)) {
proto_item_set_text(tree, %s Record Layer: Heartbeat
%s,
On Fri, Apr 4, 2014 at 10:30 AM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
Hi,
I might be overlooking something, but I don't see a tvb_get_* function to get
a uint8/16/32/64 that was encoded as a ascii or utf-8 string in the packet.
Is there such a thing?
Instead, it seems the
On Fri, Apr 4, 2014 at 4:04 PM, Guy Harris g...@alum.mit.edu wrote:
On Apr 4, 2014, at 7:30 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
I might be overlooking something, but I don't see a tvb_get_* function to
get a uint8/16/32/64 that was encoded as a ascii or utf-8 string in the
On Fri, Apr 4, 2014 at 4:08 PM, Guy Harris g...@alum.mit.edu wrote:
On Apr 4, 2014, at 9:21 AM, Herb Falk h...@sisconet.com h...@sisconet.com
wrote:
No, I just wanted to understand. It will be a couple of hours work. Tried
to GIT clone and to add in my changes, but it didn't go well.
As far as I know we do attempt to freeze the API for minor versions; I
believe we even have a build script that is supposed to catch such
breakages and report them. I wonder why it did not catch this one?
Evan
On Sat, Mar 29, 2014 at 9:10 AM, Eshed Shaham ashdn...@gmail.com wrote:
Hello,
I
If 5.2 has been out for three years at this point it sounds fine to me.
On Fri, Mar 28, 2014 at 10:29 AM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
Howdy,
Is there any reason not to make wireshark 1.11.x and beyond only use Lua 5.2?
Right now the automated builds are getting built with
I was just poking through packet-ssl.[ch] for change [1] and noticed
that ssl_set_master_secret isn't used. The compiler's not flagging it
because it's in a header file, but I don't see it showing up anywhere
else in the code base.
Remove it? Or is it exposed for 3rd-party plugins that need it?
On Mon, Mar 24, 2014 at 8:55 AM, mman...@netscape.net wrote:
I can't consistently view the code of patches submitted to Gerrit (the
Side-by-Side or Unified links). I've tried on IE8 and 9 as well as Firefox
v28 (all on Windows) and get the same consistently inconsistent results
(some patches
On Mon, Mar 24, 2014 at 11:26 AM, Bill Meier wme...@newsguy.com wrote:
On 3/24/2014 9:21 AM, Evan Huus wrote:
In summary: the diff is computed locally in javascript, and seems to
be worse than O(n) on the size of the underlying file; viewing the
diff for any file 1k lines may be slow
Apparently it tries to be smart and guess the appropriate topic. The relevant
function is [1].
As far as safe goes, I think it is. This is only the Gerrit topic, not target
branch, so the worst that happens is that pushing a new changeset will actually
change the topic on you. You can always
I haven't used it, but git cola seems to be a GUI that supports custom
commands: http://git-cola.github.io
So you should just be able to add buttons for running git review et al.
On Mar 11, 2014, at 11:00 PM, mman...@netscape.net wrote:
My biggest frustration is noted by the statement:
That sounds like it might be a good idea. Do you have captures where
the col_ API is taking a substantial amount of time?
I expect the most expensive part of the col_ API is probably the
formatting calls, but I'm not sure how we'd cache those. I expect we'd
have to do the formatting immediately
If you've got git review installed you can just run that instead of pushing at
all. We've got the config set up so it should just do the right thing.
On Mar 11, 2014, at 11:01 AM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 03/11/14 10:28, Bálint Réczey wrote:
2014-03-11 15:00
On Tue, Mar 11, 2014 at 12:05 PM, Christopher Maynard
christopher.mayn...@gtech.com wrote:
Evan Huus eapache@... writes:
I've been particularly busy of late, so I haven't had any real time to look
into git or gerrit yet, and I'm probably not going to have any time to do so
for a few more
-dev-boun...@wireshark.org] On
Behalf Of Evan Huus
Sent: den 11 mars 2014 17:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Fix bug in GSM MAP, have problems with GIT
On Tue, Mar 11, 2014 at 12:05 PM, Christopher Maynard Christopher.Maynard
at gtech.com wrote:
Evan
On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote:
Git commit ids differ
between different people (each clone may create their one)
Not technically true. If I make a commit with SHA x, push it, and it
gets submitted, then it is true that the final SHA in master will be y
!=
On Tue, Mar 11, 2014 at 4:47 PM, Guy Harris g...@alum.mit.edu wrote:
On Mar 11, 2014, at 1:35 PM, Evan Huus eapa...@gmail.com wrote:
Not technically true. If I make a commit with SHA x, push it, and it
gets submitted, then it is true that the final SHA in master will be y
!= x. However
On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote:
On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote:
Git commit ids differ
between different people (each clone may create their one
On Tue, Mar 11, 2014 at 4:55 PM, Guy Harris g...@alum.mit.edu wrote:
On Mar 11, 2014, at 1:42 PM, Graham Bloice graham.blo...@trihedral.com
wrote:
In any case I don't think this fulfils the initial question. Previously we
could say to users that an issue was fixed in svn r and they
On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote:
On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote:
On Tue
On Tue, Mar 11, 2014 at 5:11 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 11 March 2014 21:06, Evan Huus eapa...@gmail.com wrote:
On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote:
On Tue
On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Mar 11, 2014, at 5:15 PM, Guy Harris g...@alum.mit.edu wrote:
Perhaps we should have a page on some wireshark.org where a user can enter
some identifier for an automated build and an SHA hash for a commit and
On Tue, Mar 11, 2014 at 7:12 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Mar 11, 2014, at 6:42 PM, Gerald Combs ger...@wireshark.org wrote:
Would `git describe` suit your needs?
$ git describe
v1.11.3-rc1-1917-gd3b8084
The current tag is v1.11.3-rc1. There are 1917 commits
I can't seem to submit either of the following two changes:
https://code.wireshark.org/review/#/c/371/3
https://code.wireshark.org/review/#/c/420/1
They both say Submitted, Merge Pending but the submit button is
still active and nothing has happened with either of them.
installation, it
seems, that both patches lack the Verified +1 flag. Setting that and
submitting will do the trick.
regards,
Roland
On Thu, Feb 27, 2014 at 3:19 PM, Evan Huus eapa...@gmail.com wrote:
I can't seem to submit either of the following two changes:
https://code.wireshark.org
On Feb 27, 2014, at 9:19 AM, Evan Huus eapa...@gmail.com wrote:
I can't seem to submit either of the following two changes:
https://code.wireshark.org/review/#/c/371/3
https://code.wireshark.org/review/#/c/420/1
They both say Submitted, Merge Pending but the submit button is
still active
For a quick introduction to git concepts I found Git for Computer
Scientists [1] to also be quite helpful. It assumes you have a basic
working knowledge of things like Directed Acyclic Graphs but it gives
a good understanding of the underlying algorithms and is much shorter
than Pro Git.
[1]
On Tue, Feb 25, 2014 at 12:13 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Jan 28, 2014 at 02:51:19PM +0100, Joerg Mayer wrote:
On Tue, Jan 28, 2014 at 01:14:50PM +0100, Bálint Réczey wrote:
It is in the upper right corner.
The links are pretty small. You are not the first who missed
On Tue, Feb 25, 2014 at 1:39 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Feb 25, 2014 at 10:09:43AM -0800, Gerald Combs wrote:
I haven't found anything obvious in the server logs that would explain
the error, unfortunately.
Since you were able to add your SSH key, does
ssh
Sorry, this was my mistake. I got it into my head that I'd landed the
smb-direct dissector for some reason, when I clearly hadn't.
That kind of day, I guess.
On Tue, Feb 25, 2014 at 2:55 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
On Tue, Feb 25, 2014 at 4:57 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Feb 25, 2014 at 01:48:22PM -0500, Evan Huus wrote:
On Tue, Feb 25, 2014 at 1:39 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Feb 25, 2014 at 10:09:43AM -0800, Gerald Combs wrote:
I haven't found anything obvious
On Tue, Feb 25, 2014 at 5:42 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Feb 25, 2014 at 05:01:55PM -0500, Evan Huus wrote:
It sets up so that git review does the correct push, as well as
setting the gerrit topic to the current branch name (if different from
master) and a few other
On Tue, Feb 25, 2014 at 7:50 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Feb 25, 2014, at 7:06 PM, Joerg Mayer jma...@loplof.de wrote:
jmayer@egg:~/work/wireshark/git(master) git branch newsupdate
jmayer@egg:~/work/wireshark/git(master) git checkout newsupdate
Switched to branch
On Tue, Feb 25, 2014 at 8:39 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Feb 25, 2014, at 8:14 PM, Evan Huus eapa...@gmail.com wrote:
We also have the developer guide ([1] and friends). Ideally this
information would only live in one place, though there doesn't seem
The coverity build is failing again, but it's not at all clear to me
from reading the public log what the problem is.
Anybody know where to get more detailed information on the problem?
Evan
On Tue, Feb 25, 2014 at 8:57 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Feb 25, 2014, at 8:44 PM, Evan Huus eapa...@gmail.com wrote:
I'm all for consolidating the above information - we just need to
decide which of the many places to consolidate *to*. We've been
playing musical
On Mon, Feb 24, 2014 at 5:07 AM, Guy Harris g...@alum.mit.edu wrote:
On Feb 24, 2014, at 1:02 AM, Rahul Rohit rahul.ro...@aricent.com wrote:
I understand the point but just for the sake of curiosity I would like to
know how the value of tree were to be decided i.e. when the value of tree
r50646/ga39e5b9 should definitely be backported - that it isn't on the
list was an oversight on my part.
r50647/g3e8b8f0 is just a comment update - feel free to ignore or
backport depending on which is easier.
On Mon, Feb 24, 2014 at 6:30 PM, Gerald Combs ger...@wireshark.org wrote:
The last
This check was necessary in older versions of Wireshark, but not with
recent versions. The only purpose it serves now is optimization, so
you can safely remove it.
On Sun, Feb 23, 2014 at 5:25 AM, Rahul Rohit rahul.ro...@aricent.com wrote:
Hi,
The moment we enter dissect_xxx(tvb,pinfo,tree)
This came up on a review [1] and I was wondering if there was already
a consensus or if we could easily reach one.
If a dissector checks the captured length and finds that it doesn't
have enough data captured to run its heuristic (assuming there was
enough on the wire for the packet to be valid),
On Sat, Feb 22, 2014 at 7:46 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 22, 2014, at 4:13 PM, Evan Huus eapa...@gmail.com wrote:
If a dissector checks the captured length and finds that it doesn't
have enough data captured to run its heuristic (assuming there was
enough on the wire
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case the patch is simply out of date (I believe it's missing
FT_AX25 and FT_VINES, and possibly others I haven't done a thorough
check).
On Fri, Feb 21, 2014 at
Sounds like a great idea to me.
Evan
On Fri, Feb 21, 2014 at 1:37 PM, Bill Meier wme...@newsguy.com wrote:
It seems to me that it would be nice to be able to disable/enable specific
dissector and heuristic tables.
For example, this would be useful when investigating tcp level issues
for
On Fri, Feb 21, 2014 at 1:43 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Feb 21, 2014, at 1:29 PM, Evan Huus eapa...@gmail.com wrote:
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case
I believe the ;hb=HEAD at least is implied if not specified?
On Fri, Feb 21, 2014 at 4:36 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=4b28a988aaf0f96236f29a352b2a55cfce7f6127
Submitter: Gerald
On Thu, Feb 20, 2014 at 6:52 AM, Bálint Réczey bal...@balintreczey.hu wrote:
Hi All Gerald,
2014-02-01 23:04 GMT+01:00 Evan Huus eapa...@gmail.com:
On Sat, Feb 1, 2014 at 4:58 PM, Toralf Förster toralf.foers...@gmx.de
wrote:
As a follower of the wireshark code I'm wondering if
https
On Thu, Feb 20, 2014 at 7:20 PM, Gerald Combs ger...@wireshark.org wrote:
On 2/20/14 6:21 AM, Bálint Réczey wrote:
2014-02-20 14:36 GMT+01:00 Evan Huus eapa...@gmail.com:
On Thu, Feb 20, 2014 at 6:52 AM, Bálint Réczey bal...@balintreczey.hu
wrote:
Hi All Gerald,
2014-02-01 23:04 GMT+01:00
On Wed, Feb 19, 2014 at 9:37 AM, Rahul Rohit rahul.ro...@aricent.com wrote:
Hi,
If I have two protocols A and B, is it possible to register the handle of
protocol B in the protocol table of A and to register the handle of protocol
A in the
Protocol table of B at the same time.
Absolutely.
You could use proto_tree_add_text but that is strongly recommended
against. Why do you want to explicitly disallow filtering? If the
field is reserved and not important you could just not add any item at
all, and skip that byte entirely...
On Wed, Feb 19, 2014 at 4:17 PM, John Dill
On Wed, Feb 19, 2014 at 5:57 PM, John Dill john.d...@greenfieldeng.com wrote:
Message: 6
Date: Wed, 19 Feb 2014 17:24:11 -0500
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without
After yet another patch submission where this was unclear, I would
like to propose the following change:
tvb_length, tvb_length_remaining, etc. are changed to all operate on
the reported length on the wire
tvb_reported_* are dropped in favor of tvb_captured_* which operate on
the available
Good catch, thanks. Fixed in g7878878
On Fri, Feb 14, 2014 at 9:21 AM, Alexis La Goutte
alexis.lagou...@gmail.com wrote:
1bbe5cf by Evan Huus (eapache@...):
Add correct license headers for reedsolomon code.
I got in contact with the original author (thanks to Didier for digging
up
201 - 300 of 824 matches
Mail list logo
