On Thu, Feb 13, 2014 at 5:49 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 13, 2014, at 2:43 PM, Gerald Combs ger...@wireshark.org wrote:
It looks like we're creating tshark-tap-register.c for both tshark and
tfshark at the same time:
[ 86%] Generating tshark-tap-register.c
[ 86%]
On Thu, Feb 13, 2014 at 4:24 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
It seems that putting $Id$ in files stored in Git is pointless and
discouraged.
Should we remove $Id$ from all the files (and remove the check from
checkAPIs)?
Agreed, they serve no purpose now. I've been removing
On Thu, Feb 13, 2014 at 12:36 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
Speaking of old reviews, anything going on with the Michael Labedzki's
omnivorous-shark one? (https://code.wireshark.org/review/#/c/16)
At one point he was talking with Michael Mann since they were working
on
On Wed, Feb 12, 2014 at 4:07 PM, Pascal Quantin
pascal.quan...@gmail.com wrote:
2014-02-12 21:57 GMT+01:00 Evan Huus eapa...@gmail.com:
Been poking around how other projects use Gerrit and discovered that
openstack has a cron job which automatically expires old reviews [1].
Seems like
On Wed, Feb 12, 2014 at 5:03 PM, mman...@netscape.net wrote:
On a related note, it seems like Gerrit encourages more comments within its
interface when discussing a bug/enhancement then doing it Bugzilla (where
all outside patches used to go through). It was (is) always nice to have a
As per my previous emails, the only questionably-licensed code we have
left is the reed-solomon implementation. It is used only in
packet-dcp-etsi.c.
I have failed to find any other suitably-licensed reed-solomon
implementations, and don't have time to write one myself. As such I
think our best
Ah, the email in the source file was dead so I gave up, but that looks
like the same person, I will try contacting him.
Thanks,
Evan
On Tue, Feb 11, 2014 at 3:53 PM, Didier dgauthe...@magic.fr wrote:
Hi,
On Tue, 11 Feb 2014 13:07:15 -0500, Evan Huus wrote
As per my previous emails, the only
So I finally got the licensecheck passing (woohoo!) and noticed while
I was doing it that the cmake build has been failing for a while:
Traceback (most recent call last):
File
/home/wireshark/builders/trunk/ubuntu1204x64/build/tools/make-tap-reg.py,
line 181, in module
On Wed, Feb 5, 2014 at 9:33 AM, Jeff Morriss jeff.morriss...@gmail.com wrote:
I saw some emails about the -commits emails still being a work in progress
but that was a while ago. Is that still the case?
I just thought I'd mention that I'm not a fan of the current mails where we
only get the
problems
will be the reedsolomon decoding. Still looking for ideas on that
one...
Evan
[1] https://code.wireshark.org/review/#/c/145/
On Wed, Feb 5, 2014 at 4:03 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Wed, Feb 5, 2014 at 12:54 PM, Evan Huus eapa...@gmail.com wrote:
The buildbot
The buildbot is down to reporting only 13 files with license header
problems. Let's get them cleaned up and finally have that step pass :)
---
'diameter/dictionary.dtd'
'wimaxasncp/dictionary.dtd'
These two DTD files both appear to be extracted from C code at some
point in the past. We already
I think just adding it to Gerrit indicates that you want it reviewed,
there shouldn't be a need for any additional flags.
On Sun, Feb 2, 2014 at 7:53 PM, Jelmer Vernooij jel...@samba.org wrote:
Is there a specific reviewer group/person I should add in Gerrit
when proposing changes to the Git
On Fri, Jan 31, 2014 at 7:10 PM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 10:26 AM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014
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://code.wireshark.org/review/wireshark or
https://code.wireshark.org/git/wireshark is the right address to build
the latest wireshark from source code.
(If I
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 2:22 AM, Roland Knall rkn...@gmail.com wrote:
But one clarification. You do not check-out a project with git. This
is a misconception. You clone the complete repository of wireshark
into a local copy.
Wow, that sounds awesome.
Question: What is the current layout/structure of the new code? I
imagine one c file per dissector in epan/dissectors/, but where are
all the other c files? Are the capabilities they add shared only
between your protocols, or might they be useful to other protocols?
How
On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 10:26 AM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 2:22 AM, Roland Knall rkn...@gmail.com wrote:
But one
On Fri, Jan 31, 2014 at 2:33 PM, David Ameiss netsh...@ameissnet.com wrote:
On 01/31/2014 01:03 PM, Evan Huus wrote:
Wow, that sounds awesome.
Question: What is the current layout/structure of the new code? I
imagine one c file per dissector in epan/dissectors/, but where are
all the other
On Fri, Jan 31, 2014 at 3:29 PM, David Ameiss netsh...@ameissnet.com wrote:
On 01/31/2014 02:03 PM, Evan Huus wrote:
On Fri, Jan 31, 2014 at 2:33 PM, David Ameiss netsh...@ameissnet.com
wrote:
On 01/31/2014 01:03 PM, Evan Huus wrote:
Wow, that sounds awesome.
Question: What
On Fri, Jan 31, 2014 at 4:01 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
I use git-review which adds a git review command that does the right
thing with respect to gerrit.
https://github.com/openstack-infra/git-review
I was looking into git-review and it appears things work
On Fri, Jan 31, 2014 at 6:20 PM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jan 31, 2014 at 4:01 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
I use git-review which adds a git review command that does the right
thing with respect to gerrit.
https://github.com/openstack-infra/git
On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 10:26 AM, Evan Huus eapa...@gmail.com wrote:
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 31, 2014, at 2:22 AM, Roland Knall rkn...@gmail.com wrote:
But one
I believe the simpler answer is that the submit type has been set to Merge If
Necessary which means if changes are not submitted exactly on top of the
change they were authored on, Gerrit will produce a merge automatically.
I expect this was done to reduce rebase conflict when the repo is busy
There are currently a couple of different formats people have been
using for Gerrit topic names.
- spaces (bug )
- hyphens (bug-)
- slashes (bug/)
I don't have a particular preference, but we should probably settle on
one to use consistently. The git review helper script I'm trying
On Mon, Jan 27, 2014 at 7:17 PM, Evan Huus eapa...@gmail.com wrote:
Thank you Guy, this is excellent. It's more or less what I was looking
for in [1] back in October (which, coincidentally, links to the bug I
referred to earlier in this thread).
All of these conversations should be condensed
Yes.
On Wed, Jan 29, 2014 at 10:02 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 29, 2014, at 6:47 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=d3bd3965e8df79d63ae6a4ae0f7529db49fd906e
Changed:
We should maybe make tshark -G values part of the test suite? (and
maybe the other tshark -G dumps as well?)
On Mon, Jan 27, 2014 at 12:20 PM, wme...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=54983
User: wmeier
Date: 2014/01/27 05:20 PM
Log:
PM, Jakub Zawadzki darkjames...@darkjames.pl wrote:
On Tue, Jan 21, 2014 at 08:01:15AM -0500, Evan Huus wrote:
On Tue, Jan 21, 2014 at 2:40 AM, Guy Harris g...@alum.mit.edu wrote:
On Jan 20, 2014, at 5:59 PM, Evan Huus eapa...@gmail.com wrote:
In which case is dumb search-and-replace
Sounds neat! You should probably be aware of Pyreshark [1] if you
aren't already. It provides an interface for writing dissectors in
python and hooking them into the main engine, so I believe it's
complementary to your work. It may be worth collaborating with the
author, or even merging the two
On Sun, Jan 26, 2014 at 4:53 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 21, 2014, at 5:01 AM, Evan Huus eapa...@gmail.com wrote:
On Tue, Jan 21, 2014 at 2:40 AM, Guy Harris g...@alum.mit.edu wrote:
On Jan 20, 2014, at 5:59 PM, Evan Huus eapa...@gmail.com wrote:
In which case is dumb
On Sun, Jan 26, 2014 at 5:43 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 26, 2014, at 2:32 PM, Evan Huus eapa...@gmail.com wrote:
OK. I just meant that since tvb_get_string() is currently ASCII, a
dumb search and replace will let us make the API change now without
any regressions. We can
On Tue, Jan 21, 2014 at 2:40 AM, Guy Harris g...@alum.mit.edu wrote:
On Jan 20, 2014, at 5:59 PM, Evan Huus eapa...@gmail.com wrote:
In which case is dumb search-and-replace of tvb_get_string with
tvb_get_string_enc and ENC_ASCII an easy way to make (part of) the API
transition?
Did
There was a bug where Guy and I discussed strings in depth (though I
can't find it at the moment).
I think we'd agreed that the right thing to do is to convert most of
our string functions to handle and return counted strings
(wmem_strbuf_t or something) and then do the replacement as you
On Mon, Jan 20, 2014 at 2:52 PM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
Hi,
On Mon, Jan 20, 2014 at 06:22:37PM +0100, Martin Kaiser wrote:
if I have a tvbuff that starts with 0x86 and I call
a = tvb_get_string_enc(tvb, 0, ENC_ASCII)
proto_tree_add_string(..., a);
I can trigger
On Mon, Jan 20, 2014 at 6:28 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 20, 2014, at 9:22 AM, Martin Kaiser li...@kaiser.cx wrote:
Comments in the code suggest that tvb_get_string() should replace
chars=0x80 with the unicode replacement char, which is two bytes long.
We should also
On Mon, Jan 20, 2014 at 8:27 PM, Guy Harris g...@alum.mit.edu wrote:
On Jan 20, 2014, at 1:49 PM, Martin Kaiser li...@kaiser.cx wrote:
I committed the change to tvb_get_string() in r54864.
I've changed that *not* to map bytes with the 8th bit set to REPLACEMENT
CHARACTER for UTF-8 strings.
We currently have a colour filter for ipx || spx packets included by
default, and recently got a request to differentiate the two (perhaps
disabled by default). See later comments on bug 9552.
To my knowledge we don't currently include any disabled rules by
default, and it doesn't seem worth
Thanks Balint, username was the problem. I swear I'd set one when I
first created the account but I guess not.
Cheers,
Evan
On Wed, Jan 15, 2014 at 6:58 AM, Bálint Réczey bal...@balintreczey.hu wrote:
Hi Evan,
2014/1/15 Evan Huus eapa...@gmail.com:
I have created an account and added an SSH
While poking around gerrit and git-related stuff I came across this
tool which looks like it might make gerrit use easier. Anybody have
experience with it or know if it matches our expected workflow?
https://github.com/openstack-infra/git-review
Evan
I have created an account and added an SSH key, but I am getting
Permission denied (publickey) when trying to clone. Is it working
for anyone else?
On Tue, Jan 14, 2014 at 4:50 PM, Gerald Combs ger...@wireshark.org wrote:
The live Gerrit site is up and running at
Wireshark definitely reads and stores the byte-order from the pcap header when
opening the file. I don't think that is exposed currently, but it should be
relatively easy to do (from wiretap).
On Jan 10, 2014, at 7:33 AM, Michal Labedzki michal.labed...@tieto.com
wrote:
Hello,
Is there
Specifically, see the byte_swapped boolean in wiretap/libpcap.c and
wiretap/pcapng.c
On Fri, Jan 10, 2014 at 9:06 AM, Evan Huus eapa...@gmail.com wrote:
Wireshark definitely reads and stores the byte-order from the pcap header
when opening the file. I don't think that is exposed currently
On Fri, Jan 10, 2014 at 2:21 PM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
Hi,
On Fri, Jan 10, 2014 at 01:33:49PM +0100, Michal Labedzki wrote:
Probably PCAP/PCAPNG have ordering info by magic bytes, but I do not
know how to do that while live capturing (current code work for this
Yes, I've used it on-and-off for quite a while now. It can be quite
useful, though it does have a number of limitations. There is a shell
script in Wireshark trunk tools directory (tools/cppcheck/cppcheck.sh)
which will run cppcheck with a set of flags and other configurations
which I have found
Hi all, a few months ago I mentioned in an email [1] that I would be
writing a Human-Computer Interaction (HCI) term paper on Wireshark's
user interface. Well, after a couple of drafts, and having now
finished that course I am releasing the paper online [2] for the
(hopeful) benefit of the
This was originally filed as bug 9569. The situation is sufficiently
unusual that I really don't know what the best solution is, so I
figured I'd ask for general comments from the list. The company who
created and used the TPNCP protocol (and submitted the packet-tpncp.c
dissector) wants to reuse
On Wed, Dec 18, 2013 at 9:08 PM, Ed Beroset bero...@mindspring.com wrote:
Gerald Combs wrote:
I'm assuming everyone has had a chance to test the Gerrit installation
at test.code.wireshark.org If you haven't, now might be a good time.
Had the chance to, perhaps, but haven't yet. I'm not
On Sun, Dec 15, 2013 at 2:20 PM, Ed Beroset bero...@mindspring.com wrote:
Ed Beroset wrote:
Evan Huus wrote:
The part that's confusing me is that somehow
actx-external.direct_reference seems to be getting a pointer to this
stale ep-allocated buffer, but I can't find anywhere in the call
Alexis's ASAN build recently caught an error in
tvb_bcd_dig_to_wmem_packet_str in which it appears that if the least
significant nibble of the decoded byte is 0xf then we read one element
past the end of the 14-element digit array.
If the most significant nibble is 0xf we treat that as a stop
, but I'm not sure what else to do.
2013/12/17 Evan Huus eapa...@gmail.com
Alexis's ASAN build recently caught an error in
tvb_bcd_dig_to_wmem_packet_str in which it appears that if the least
significant nibble of the decoded byte is 0xf then we read one element
past the end of the 14-element
I was running some valgrind fuzzing and I got a file that produces the
following valgrind trace:
==8013== Invalid read of size 1
==8013==at 0x95F89D0: g_str_hash (ghash.c:1732)
==8013==by 0x95F8058: g_hash_table_lookup (ghash.c:365)
==8013==by 0x65DE56E: call_ber_oid_callback
On Sun, Dec 15, 2013 at 12:33 PM, Ed Beroset bero...@mindspring.com wrote:
Evan Huus wrote:
In one sense the problem is easy to trace: the oid resolution code is
returning the resolved string in an ep-allocated buffer, which is then
getting freed and subsequently used. However, I'm having
I want to change the exit status of the exit_error() function in
test-common.sh from 1 to 255, as that is the value that will prevent
xargs from processing further input. Currently running ... | xargs
./tools/fuzz-test.sh will not stop on an error since xargs will catch
it and just keep going.
I
What benefit does this provide over simply capinfos -t?
On Thu, Dec 12, 2013 at 9:59 PM, g...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=54015
User: guy
Date: 2013/12/13 02:59 AM
Log:
Add a captype file that just reports the type of a capture
I've been exploring a few options for the val_to_str function and
wmem. One of the tangential things I've been trying to achieve is to
make it into a macro so that the compiler will catch format-string
mismatches (which have been a source of bugs in the past). This is
easy to do inefficiently:
On Wed, Dec 11, 2013 at 5:40 PM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
Hi,
On Wed, Dec 11, 2013 at 05:22:31PM -0500, Evan Huus wrote:
I've been exploring a few options for the val_to_str function and
wmem. One of the tangential things I've been trying to achieve is to
make
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9406
Can anybody at all reproduce this one? Gerald, any thoughts on what
fuzzbot-specific config might be causing this?
___
Sent via:Wireshark-dev mailing list
Should all of these null checks be handled in one place (like
call_dissector_through_handle or something)?
Are there specific dissectors where it's valid for data to be NULL?
Even if there are, is it simply less work at this point to pass them a
pointer to an empty struct or some such thing?
called in the first place, so I don't think there's
really anything else that could be done except for adding the extra checks.
- Chris
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: Monday
We already have ENC_ASCII, ENC_UTF8, etc. Perhaps
proto_tree_add_string should just take an encoding value instead?
On Sat, Dec 7, 2013 at 7:20 AM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
Hi,
I renamed base_display_e to field_display_e, and added new enums to
field_display_e,
but I
As a point of reference on this, Ubuntu recommends different formats
depending on the context [1]. They suggest base 2 for RAM sizes (such
as our capture buffer) and base 10 for almost everything else,
including file sizes and network bandwidth.
Without thinking about it too hard this seems
Based on a quick skim it looks like a more powerful version of the
usual if (tree) performance checks. When filtering, tree cannot be
NULL as there must be somewhere for the filtered fields to be
attached, but if you are filtering on HTTP then there is no need to
fill in the Ethernet/TCP/IP fields
they need in the proto_reg_handoff function.
Could making the proto_* variables public be part of the register.c python
script?
Either of those might work too.
-Original Message-
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent
On Thu, Nov 21, 2013 at 3:44 PM, Guy Harris g...@alum.mit.edu wrote:
On Nov 21, 2013, at 12:08 PM, mm...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53489
User: mmann
Date: 2013/11/21 08:08 PM
Log:
Remove ethertype, mpls_label and ppids from
was just thinking it would be simpler to be able to do a straight ==.
-Original Message-
From: Evan Huus eapa...@gmail.com
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Thu, Nov 21, 2013 7:27 am
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53473: /trunk/ui/
/trunk/ui
. Corrections and criticisms more than
welcome, I'm sufficiently tired that I'm sure there must be at least
one inaccuracy somewhere. Now back to schoolwork...
Cheers,
Evan
-Original Message-
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev
and proto id?
the sorted GSList method has always confused me, I'm too tired to make
algorithmic sense of a sorted singly-linked list...)
On Thu, Nov 21, 2013 at 9:59 PM, Evan Huus eapa...@gmail.com wrote:
On Thu, Nov 21, 2013 at 7:02 PM, mman...@netscape.net wrote:
Should there be separate APIs
Rather than doing string comparisons you should just be able to compare the
value directly to the proto_* variable for the relevant protocol. Most of the
necessary ones should already be I'm public headers.
On Nov 21, 2013, at 7:16 AM, mm...@wireshark.org wrote:
What does more generic mean in this context?
On Nov 13, 2013, at 8:15 AM, mman...@netscape.net wrote:
I was looking at making the Decode As functionality more generic, but my
current solution involves having dissectors handle a callback function that
passes in a capture_file* as an
* but the underlying functionality knows exactly
what type of pointer it is), hence the post to -dev.
-Original Message-
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Nov 13, 2013 9:21 am
Subject: Re: [Wireshark-dev
?
-Original Message-
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Nov 13, 2013 10:46 am
Subject: Re: [Wireshark-dev] capture_file* in dissector code
On Nov 13, 2013, at 9:41 AM, mman...@netscape.net wrote:
The ulterior
On Thu, Nov 7, 2013 at 8:34 AM, Alexis La Goutte
alexis.lagou...@gmail.com wrote:
Hi,
When i try to build wireshark-qt with clang (and autotools) i have the
following error message :
dev:~/wireshark-clang/ui/qt$ make
CXX accordion_frame.o
In file included from
On Thu, Nov 7, 2013 at 12:33 PM, mman...@netscape.net wrote:
Should tcp_dissect_pdus() add a data parameter to allow private data that
was passed to a dissector running over TCP to be used by the dissector
itself?
I debated this when removing the pinfo-private data used to pass struct
On Nov 7, 2013, at 3:14 PM, darkja...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53146
User: darkjames
Date: 2013/11/07 08:14 PM
Log:
Add infrastructure for section-initializing protocol hfis (without array).
Looks cool. How is this going to
On Mon, Nov 4, 2013 at 5:12 PM, Guy Harris g...@alum.mit.edu wrote:
On Nov 3, 2013, at 12:31 PM, Evan Huus eapa...@gmail.com wrote:
I remember reading (on this list, I think) an explanation that the UI
of pretty much all modern sniffers is derived from the first such
program which
It appears to be licensed under GPLv3 only, which makes it
incompatible for us to include.
It seems to be included only because links/lynx didn't appear to work
a while ago when building under WIndows. If that is no longer true
then I think we can just remove it with no loss of functionality?
On Sun, Nov 3, 2013 at 10:25 AM, Bálint Réczey bal...@balintreczey.hu wrote:
2013/11/3 Evan Huus eapa...@gmail.com:
It appears to be licensed under GPLv3 only, which makes it
incompatible for us to include.
It seems to be included only because links/lynx didn't appear to work
a while ago
Hi all,
I'm currently taking a class on Human-Computer Interaction, and I'm
going to be writing my term paper on Wireshark's UI. The meat of the
paper is going to be on the current interface and application of
various theoretical frameworks, but I thought it would be useful (and
kind of neat) if
On Thu, Oct 31, 2013 at 5:56 PM, Matthieu Patou m...@samba.org wrote:
On 10/30/2013 12:07 PM, Evan Huus wrote:
On Wed, Oct 30, 2013 at 2:20 PM, Matthieu Patou m...@samba.org wrote:
On 10/30/2013 07:31 AM, Evan Huus wrote:
On Wed, Oct 30, 2013 at 4:14 AM, Matthieu Patou m...@samba.org wrote
On Wed, Oct 30, 2013 at 4:14 AM, Matthieu Patou m...@samba.org wrote:
Hello,
I noticed long time ago that wireshark is parsing the same packet at least 3
tree times.
To make it worse if I go back and forth to the same packet it will be
dissected one more time.
With complex protocols like
On Wed, Oct 30, 2013 at 2:20 PM, Matthieu Patou m...@samba.org wrote:
On 10/30/2013 07:31 AM, Evan Huus wrote:
On Wed, Oct 30, 2013 at 4:14 AM, Matthieu Patou m...@samba.org wrote:
Hello,
I noticed long time ago that wireshark is parsing the same packet at
least 3
tree times.
To make
On Mon, Oct 28, 2013 at 8:03 PM, Ed Beroset bero...@mindspring.com wrote:
Also, if we make the possibly rash assumption that Unicode is the superset,
perhaps we can regularize the addition of new renderings by requiring
conversions to and from Unicode and routines that can create
an array of
On Sun, Oct 27, 2013 at 5:56 PM, morr...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52905
User: morriss
Date: 2013/10/27 09:56 PM
Log:
Fix https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9323 :
Actually handle non-NULL-terminated FT_STRINGs
On Fri, Oct 25, 2013 at 11:56 PM, Joerg Mayer jma...@loplof.de wrote:
On Fri, Oct 25, 2013 at 02:20:55PM -0400, Evan Huus wrote:
I was just wondering why checklicenses.py does not permit any GPL2
licenses, the only GPL-related ones on the list are GPL2+.
This may turn out to be an oversight
I was just wondering why checklicenses.py does not permit any GPL2
licenses, the only GPL-related ones on the list are GPL2+.
If there's a reason we require 2+ and not just 2 then we will have to
add exceptions for epan/dissectors/packet-ieee80211-radiotap-iter.[ch]
which are dual-licensed under
P.S. You can tell which UATs are rarely used, because some of them
were accidentally using wmem for a few weeks and we've had no bugs
reported about assertions :)
On Fri, Oct 25, 2013 at 6:14 PM, eapa...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52854
On Mon, Oct 21, 2013 at 8:41 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 Ed Beroset
Sent: den 19 oktober 2013 20:24
To: wireshark-dev@wireshark.org
Subject:
On Oct 21, 2013, at 4:51 PM, Ed Beroset bero...@mindspring.com wrote:
Joerg Mayer wrote:
On Sun, Oct 20, 2013 at 02:18:19AM +, eapa...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52701
User: eapache
Date: 2013/10/20 02:18 AM
Log:
Don't use
Hello Samba folks. I was poking through the recent changes being
landed to PIDL in Wireshark (thank you for those!) and noticed that
one of the files was being picked up as unlicensed by our buildbot.
Specifically:
'epan/dissectors/pidl/idl_types.h' has non-whitelisted license 'UNKNOWN'
A bit of
On Fri, Oct 18, 2013 at 5:17 PM, mm...@wireshark.org wrote:
Not sure which memory allocation should be used here (using wmem caused
crash), but this revision can at least be easily backported to 1.10 where the
bug was reported.
ephemeral is fine for now - I plan to fix UAT code eventually
without any check, but this is the best I can
think
of right now.
On Sun, Oct 13, 2013 at 12:58:12AM -0400, Evan Huus wrote:
Jeff (and/or anyone else who cares) I'd appreciate a verification that
my logic here is correct, and that I've not accidentally undone your
good work.
I think it's
On Wed, Oct 16, 2013 at 2:40 PM, ger...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52649
User: gerald
Date: 2013/10/16 06:40 PM
Log:
Don't bother checking for clang, just add -Qunused-arguments to the
compiler flags checks.
Directory: /trunk/
It's been failing for a few days now with the same error as is described here:
http://www.qtcentre.org/threads/54326-Visual-Studio-2012-Qt5-0-2-Compilation-Error
Unfortunately the link does not clarify the actual solution, they
reset some configuration and rebuilt and it went away. Anybody more
On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
About tvb_offset_exists() comment, compute_offset() is not returning
exception when offset == tvb-length.
Ah, OK. Should it? When offset == tvb-length I would think that
should be an exception, since no bytes exist
On Fri, Oct 11, 2013 at 1:25 PM, Toralf Förster toralf.foers...@gmx.de wrote:
While uploading a 5 MB rand pkt file to bug
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9264
I was wondering if it is really needed to upload such files - or - if it
would be possible to add only the seed of
On Sat, Oct 12, 2013 at 11:46 AM, Anders Broman a.bro...@bredband.net wrote:
Just looking at performance in general as I got reports that top of trunk
was slower than 1.8.
Thinking about it fast filtering is more attractive as long as loading isn't
to slow I suppose.
It's quite annoying to
On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus eapa...@gmail.com wrote:
On Sat, Oct 12, 2013 at 11:46 AM, Anders Broman a.bro...@bredband.net wrote:
Just looking at performance in general as I got reports that top of trunk
was slower than 1.8.
Thinking about it fast filtering is more attractive
On Sat, Oct 12, 2013 at 6:31 PM, Jakub Zawadzki
darkjames...@darkjames.pl wrote:
On Sat, Oct 12, 2013 at 05:08:04PM -0400, Evan Huus wrote:
On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus eapa...@gmail.com wrote:
Now I'm wondering how much of this could be alleviated somehow by a more
efficient
On Fri, Oct 11, 2013 at 12:41 AM, Anders Broman a.bro...@bredband.net wrote:
In the particular case I'm looking at there is mostly no match in the
heuristics tables except false positives
the same is true for many of the uint table lookups too as there is RTP sent
from a tool simulating many
Jeff (and/or anyone else who cares) I'd appreciate a verification that
my logic here is correct, and that I've not accidentally undone your
good work.
Thanks,
Evan
On Sun, Oct 13, 2013 at 12:54 AM, eapa...@wireshark.org wrote:
301 - 400 of 824 matches
Mail list logo
