Hello Tomer,
W dniu 2018-11-08 10:46, Guy Harris napisał(a):
On Nov 8, 2018, at 12:52 AM, Dario Lombardo wrote:
On Wed, Nov 7, 2018 at 5:39 PM Tomer Bar
wrote:
i want to expose the validation of the display filter and use it like
service?
any idea?
Do you want to do it programmatically (
W dniu 2018-10-19 16:51, Jeff Morriss napisał(a):
Is it just me or is there no reason for ett[] arrays:
/* Setup protocol subtree array */
static gint *ett[] = {
&ett_PROTOABBREV
to be static?
It seems to me that making it static is just wasting space (keeping the
array around
Hi,
W dniu 2018-09-18 16:56, Maynard, Chris napisał(a):
While investigating the transum-related crash, I had suspected some
unregistered hf's and ran the various tools like checkhf.pl. I then
noticed that a number of dissectors seemed to have changed a bit from
what I was used to before (...)
Hello,
W dniu 2018-07-02 22:33, Jeff Morriss napisał(a):
It's an idea that's been tossed around since at least 2006[1]. Someone
(Jakub?) had played around with it but eventually gave up;
unfortunately I
can't find the reference to that.
It seems I did one in 2012,
https://www.wireshark.org
Hello,
W dniu 2018-05-13 17:15, Eugène Adell napisał(a):
I'm facing a problem on my development server (Ubuntu 16.04 hosted on
VMWARE) when trying to compile Wireshark. It was working with older
versions (2.0 for example), but now it's like the compilation will
never
end.
I installed/updated a
W dniu 2018-03-15 13:24, Peter Wu napisał(a):
> I was looking at memleaks as reported by LSAN while running the
> decryption test suite, there are quite a number of occurrences.
Can register_tap_listener() return enum code (one of: success, not
found,
wrong filter)?
You will get rid of memleak,
Hi Peter,
W dniu 2018-03-15 13:24, Peter Wu napisał(a):
I was looking at memleaks as reported by LSAN while running the
decryption test suite, there are quite a number of occurrences.
One of them is tap (return value of register_tap_listener) which is a
GString which seems unnecessary since it
Hello,
W dniu 2018-02-02 23:45, Gerald Combs napisał(a):
I think we've fixed the major issues identified by Stig, Jim, and
others so I'd like to release 2.5.0 on February 6.
In oss-fuzz queue currently there are few crashes, and one inifite loop.
Should it be a blocker for a release?
Regards,
Hello Martin,
W dniu 2017-12-09 14:52, Martin Mathieson via Wireshark-dev napisał(a):
There have been some failures recently, e.g.
https://buildbot.wireshark.org/petri-dish/builders/Windows%20Petri%20Dish%20x64/builds/1123/steps/compile_1/logs/stdio
That build took over 21 minutes, and near the
Hello Paul,
W dniu 2017-12-03 18:39, Paul Offord napisał(a):
I setup the environment with:
(cut)
set QT5_BASE_DIR=QT5_BASE_DIR=C:\Qt\5.9.3\msvc2015_64
Please try:
QT5_BASE_DIR=C:\Qt\5.9.3\msvc2015_64
___
Sent via:W
W dniu 2017-11-22 18:02, Pascal Quantin napisał(a):
There was indeed an experimental packet editor, but it was very limited
(basically as far as I can remember it could edit values like what you
could do with an hex editor, but was not a generic encoder for any
given
protocol).
It was a litt
Hello Adam,
W dniu 2017-09-25 07:05, Adam Baxter napisał(a):
It's failing on extcap.
make[2]: Entering directory '/wireshark/extcap'
(...)
CC udpdump.o
udpdump.c: In function 'setup_listener':
udpdump.c:126:9: error: variable 'timeout' has initializer but
incomplete
type
struct time
Hi Peter,
W dniu 2017-08-28 18:50, Peter Wu napisał(a):
This can especially problematic for services like Cloudshark and
Webshark (by Jakub). The former is not yet affected since it does not
use 2.4 code (yet?) but the latter seems theoretically vulnerable as it
has a setconf API function (I was
Hello,
W dniu 2017-06-27 05:33, Guy Harris napisał(a):
On Apr 29, 2011, at 12:52 AM, Jakub Zawadzki
wrote:
On Thu, Apr 28, 2011 at 11:24:08PM -0700, Guy Harris wrote:
I wouldn't to it by checking for a particular version, though -
I'd just check for inflatePrime() and, if it
Hello,
W dniu 2017-01-08 15:30, Alexis La Goutte napisał(a):
for disable when code will be review, we can help you to add this
"feature"
About sharkd for me, it is different because sharkd is for a web
wireshark
(like CloudShark)
If this will get some "merge points" for sharkd, it's my mai
Hi,
W dniu 19.08.2015 16:45, yves baumes napisał(a):
My first one would be: how do I get the header_field_info structure
instance from its structure id? Here is what I'm trying to achieve:
static int hf_instr_id = -1;
[...]
{ &hf_instr_id,
{ "Instrument Identifier", "my_proto.instr_i
Hi,
On Sat, Jun 21, 2014 at 10:12:48PM +0200, Jakub Zawadzki wrote:
> If we're in topic of optimizing 'slower' [de]allocations in common functions:
>
> - tvb allocation/deallocation (2.5%, or 3.4% when no filtering)
>
>243,931,671 * ???:tvb_new
Hi,
On Sun, Jun 29, 2014 at 01:43:39PM +0200, Toralf Förster wrote:
>
> /mew wonders if wireshark should print a warning if a http traffic goes
> over port 443 (eg a TRAC temporarily configured at that port instead of
> 80) but is not encrypted, currently those packets are marked as "SSL"
> but t
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 in
> sync. I'd rather the computer do the extra work :)
But in the same time, we can
On Sun, Jun 22, 2014 at 05:45:45PM -0400, Evan Huus wrote:
> On Sun, Jun 22, 2014 at 5:25 PM, Jakub Zawadzki
> wrote:
>
> > 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
> >
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 (so
> stateless is actually slightly slower than stateful) but it seems to work
> in
t; Submitter: Anders Broman (a.broma...@gmail.com)
> > Changed: branch: master
> > Repository: wireshark
> >
> > Commits:
> >
> > b6d20a2 by Jakub Zawadzki (darkja...@darkjames.pl):
> >
> > Optimize reseting epan_dissect_t when filtering.
> >
> &g
Hello,
On Tue, Jun 10, 2014 at 05:06:24PM +, Anders Broman wrote:
> >From: wireshark-dev-boun...@wireshark.org
> >[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
> >
> >HAVE_SSE42 is used in two places:
> >
> > 1) wsutil/ws_mempbrk_sse42.c, where it controls whether t
On Mon, Jun 09, 2014 at 07:32:49PM +0200, Toralf Förster wrote:
> spotted by cppcheck
>
> Signed-off-by: Toralf Förster
> ---
> wsutil/sha1.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/wsutil/sha1.c b/wsutil/sha1.c
> index fcafd2b..081881a 100644
> --- a/wsutil
Hi,
On Wed, Jun 04, 2014 at 11:24:59AM +, Anders Broman wrote:
> I did a test with
> static inline const guint8*
> guint8_pbrk(const guint8* haystack, size_t haystacklen _U_, const guint8
> *needles, guchar *found_needle)
> {
> const guint8 *result = (const guint8 *)strpbrk(ha
Hi,
On Tue, Jun 03, 2014 at 08:37:49AM +, Anders Broman wrote:
> How do I go about compiling Wireshark with sse4.2 enabled? If I understand
> correctly I should add GCC flag -march=native somewhere?
Anders, just to let you know your libc is already using sse4.2 and it shows up
in your profi
Hi,
On Tue, May 13, 2014 at 02:19:51PM -0400, Kevin Cox wrote:
> I was attempting to dissect a 64 bit bitfield and was wondering what the
> best/preferred method was. I saw a question on ask.wireshark.org[0]
> which had a single answer the said to use a text field.
>
> [0]
> http://ask.wireshark
Hi,
On Mon, Feb 17, 2014 at 05:07:04PM -0500, Evan Huus wrote:
> 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_
On Sun, Feb 09, 2014 at 10:48:44AM +0100, Toralf Förster wrote:
> Furthermore I wonder why an undefined value in epan/crypt/airpdcap_interop.h
> (around line 98) :
>
> #ifndef ntohs
> #undef ntohs <--
> #define ntohs(value)g_ntohs(value)
> #endif
>
> has to be undef agai
On Tue, Jan 21, 2014 at 08:01:15AM -0500, Evan Huus wrote:
> On Tue, Jan 21, 2014 at 2:40 AM, Guy Harris wrote:
> >
> > On Jan 20, 2014, at 5:59 PM, Evan Huus 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
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 the DISSECTOR_ASSERT since a is not a valid unicode string.
>
> Comments in t
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
> case)
Still magic numbers are always saved in current host endianess ;|
So if you (
On Mon, Dec 30, 2013 at 01:51:28PM -0500, mman...@netscape.net wrote:
> print.c - hf_ fields from from frame and data dissectors in order to output
> data values.
Move it to ui/ ?
___
Sent via:Wireshark-dev mailing list
On Sun, Dec 29, 2013 at 03:41:05AM -0800, Guy Harris wrote:
>
> On Dec 18, 2013, at 4:46 AM, Matthias Lang
> wrote:
>
> > 1. The manpage (tshark.pod) for 'tshark' says reading from stdin isn't
> > allowed. But it actually works fine. Manpage says:
> >
> >| =item -r EinfileE
> >|
> >
Hello,
I removed isprint.h file, and replaced all isprint() using this hack
to g_ascii_isprint().
I've also simplify: isascii && isprint() to g_ascii_isprint()
This changes seems correct, but please review.
Still we have lot of isprint() calls (some in Qt) which I
think should be using g_ascii
Hello,
On Sat, Dec 21, 2013 at 11:27:27AM +0100, Joerg Mayer wrote:
> converting a dissector to the new proto tree api is still unnecessarily
> complex (and I managed to break all buildbots in the course).
> I've attached a diff between the result of the conversion script output
> and the currentl
On Fri, Dec 20, 2013 at 11:59:20AM -0800, Michael Lum wrote:
> Okay, thanks for the responses.
>
> I started to make some changes but its probably more than I have time for.
>
> But in case I pick it up I had a question about the ENC_ values from proto.h.
>
> This is what I have from SVN:
>
> #
On Fri, Dec 20, 2013 at 10:46:29AM -0800, Michael Lum wrote:
> Is there a goal to remove g_iconv calls from Wireshark.
Nope, it's not a goal (at least not for me).
Goals are two:
1/ To support more encodings in epan, which will make it easier for people to
use
2/ Thanks to 1/ more calls can be
On Sat, Nov 23, 2013 at 02:23:54PM -0500, mman...@netscape.net wrote:
> Is proto_field_is_references still a valid function?
>
> In looking at the intent, it either looks completely useless or should be
> used on almost all dissectors.
My old mail about proto_field_is_references()
http://www.w
On Sat, Dec 14, 2013 at 07:44:02PM -0500, mman...@netscape.net wrote:
>
> There is a bug in Wireshark when a dissector has an hf_ variable of type
> FT_INT64 and the requested length of the field is < 8 bytes. There is no
> accounting for the sign bit (which has led dissectors to come up with t
Hi,
On Mon, Dec 16, 2013 at 05:48:12PM +0100, Martin Kaiser wrote:
> is it allowed to add an FT_BYTES hf entry with len==0 to the protocol
> tree?
>
> E.g.
>
> proto_tree_add_bytes_format_value(tree, hf_myproto_myval,
>tvb, offset, 0, NULL, format, ...)
>
> The idea would be to allow filte
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 it into a macro so that the compiler will catch format-string
> mismatches (which have be
On Wed, Dec 11, 2013 at 09:17:00PM +0100, Joerg Mayer wrote:
> On Wed, Dec 11, 2013 at 08:38:30AM +0100, Joerg Mayer wrote:
> > I'd like to move the plugins/ directory into epan/dissectors/. They provide
> > just more dissectors and depend on epan anyway.
> > Are there good reasons not to do that m
On Mon, Dec 09, 2013 at 04:20:58PM +0100, Joerg Mayer wrote:
> Isn't UNICODE a bit to broad a name here? Wouldn't STR_UTF8 be a better
> name as there are different unicode encodings around?
Well I'd rather avoid using any unicode encoding name here, because some people
can think:
"Hey, I'm us
On Sun, Dec 08, 2013 at 11:08:39PM +0100, Martin Kaiser wrote:
> sorry for causing problems with the DVB-CI decryption test.
Don't worry. It's DTLS failing not DVB-CI ;-)
Sorry.
___
Sent via:Wireshark-dev mailing list
Arc
On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
> Thanks for the automated build links - I guess I'll watch them more closely
> and only sync when my platform passes.
>
> Interesting - I'm pulling from trunk and still fail on that. Perhaps it
> wasn't fixed entirely, or I have to do some cle
On Sat, Dec 07, 2013 at 04:53:51PM -0800, Guy Harris wrote:
>
> On Dec 7, 2013, at 7:02 AM, darkja...@wireshark.org wrote:
>
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53826
> >
> > User: darkjames
> > Date: 2013/12/07 03:02 PM
> >
> > Log:
> > Add string encoding for
On Sat, Dec 07, 2013 at 04:50:10PM +, Graham Bloice wrote:
> Started testing builds with VS 2013 Pro (nmake build), complaints about
> redefinitions:
>
> C:\Program Files (x86)\Windows Kits\8.1\include\um\ws2tcpip.h(531) : error
> C2373: 'ws_inet_pton' : redefinition; different type modifiers
On Sat, Dec 07, 2013 at 10:58:35AM -0500, Evan Huus wrote:
> On Sat, Dec 7, 2013 at 7:20 AM, Jakub Zawadzki
> wrote:
> > Hi,
> >
> > I renamed base_display_e to field_display_e, and added new enums to
> > field_display_e,
> > but I wonder if it's corre
Hi,
I renamed base_display_e to field_display_e, and added new enums to
field_display_e,
but I wonder if it's correct approach.
For FT_ABSOLUTE_TIME we're using seperate enum
(absolute_time_display_e), so maybe FT_STRING* should also have own enum
string_display_e ?
Anyway, dissecotrs using p
On Wed, Dec 04, 2013 at 02:50:37PM +, Kukosa, Tomas wrote:
> I have updated Ply in our SVN (rev 53782) to the current version.
> Please check if it helps and works with Python 3.
I run make in asn/ and I hit one error in isdn-sup
/usr/bin/python ../../tools/asn2wrs.py \
-b -k \
Hi Tomas,
On Tue, Dec 03, 2013 at 10:49:35PM +, Kukosa, Tomas wrote:
> I have found that it is the known Ply issue
> http://code.google.com/p/ply/issues/detail?id=30
>
> I will look whether it is better to fix yacc.py or to change our asn2wrs.py
For me we could also force using python2 in as
Hi,
On Tue, Dec 03, 2013 at 11:56:23PM +0100, Joerg Mayer wrote:
> On Tue, Dec 03, 2013 at 08:59:26PM +, darkja...@wireshark.org wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53765
> >
> > User: darkjames
> > Date: 2013/12/03 08:59 PM
> >
> > Log:
> > struct _d
Hi,
I hit this problem when trying to regenerating few ASN dissectors:
/usr/bin/python ../../tools/asn2wrs.py \
-E -b -L \
-p dap \
-c ./dap.cnf \
-D . \
dap.asn DirectoryAccessProtocol.asn
ASN.1 to Wireshark dissector compiler
Traceback (most recent call
On Thu, Nov 28, 2013 at 01:40:31PM -0800, Guy Harris wrote:
>
> On Nov 28, 2013, at 1:39 PM, Jakub Zawadzki wrote:
>
> > On Tue, Nov 19, 2013 at 07:15:54PM +0100, Jakub Zawadzki wrote:
> >> htons(), htonl(), htonll() is kinda easier to write and looks prettier for
>
On Tue, Nov 19, 2013 at 07:15:54PM +0100, Jakub Zawadzki wrote:
> htons(), htonl(), htonll() is kinda easier to write and looks prettier for me
> than hton16, hton32, hton64().
It seems that such change would get us to have name conflict with
(at least on Linux),
../../wsutil/pint.h
On Sat, Nov 23, 2013 at 02:23:54PM -0500, mman...@netscape.net wrote:
> I was leaning more towards useless because I can't think of a scenario where
> tree (is already) != NULL, yet a dissector would be called without having its
> proto field referenced.
I don't understand this. For example 'fra
On Thu, Nov 21, 2013 at 08:46:06AM -0500, Evan Huus wrote:
> I don't see any specific reason to keep the proto_ variables private,
> so I have no objection to making them available. All of the protocols
> involved in this case already have separate header files anyways.
I'd rather use proto_get_id
Hello Alexis, Peter,
Looking at r53416 [1] diff, I found two things in packet-ssl.c strange
2861 dissect_ssl3_hnd_hello_ext_status_request_v2(tvbuff_t *tvb, proto_tree
*tree,
2869 while (list_len-- > 0)
2870 offset += dissect_ssl3_hnd_hello_ext_status_request(tvb, tree,
offset, TR
On Mon, Nov 18, 2013 at 03:34:44PM -0800, Guy Harris wrote:
> I think using the number of bits is cleaner, but going that way everywhere,
> not just in those macros, *would* be a major change (mechanical, but still a
> change).
I only want to make wtap-int.h use pint.h macros,
htons(), htonl(),
Hello,
Right now we have the similar set of macros inside wtap-int.h & pint.h.
I'd like to merge wtap-int.h macros to pint.h
The main difference is in naming of 64-bits version.
In pint.h it ends with 64 (pntoh64, pletoh64) in wtap it ends with ll
(pntohll, pletohll, phtonll, phtolell, htolell)
On Sat, Nov 16, 2013 at 11:12:22PM +0100, Jakub Zawadzki wrote:
> (...) Still it seems to be quite complicated for one bitswap variable...
> (revert?).
I've added bitswap_buf_inplace() in r53374, r53375
This seems to
On Sat, Nov 16, 2013 at 12:25:53PM -0800, Guy Harris wrote:
>
> On Nov 16, 2013, at 1:54 AM, buildbot-no-re...@wireshark.org wrote:
>
> > The Buildbot has detected a new failure on builder Windows-7-x64 while
> > building Wireshark (development).
> > Full details are available at:
> > http://bui
Hello Anders,
On Thu, Nov 14, 2013 at 04:14:02PM +, Anders Broman wrote:
> The following tshark parameters " -Y diameter -z
> proto,colinfo,diameter.Experimental-Result-Code,diameter.Experimental-Result-Code"
> yields no result where as
> -Y diameter -z proto,colinfo,diameter.Result-Code,dia
On Wed, Nov 13, 2013 at 05:14:19PM -0500, mman...@netscape.net wrote:
> A related question - Is packet_info->phdr == &capture_file->phdr?
> That would allow me to get the data I need always from packet_info* and not
> need the capture_file*
Not always, packet_info->phdr points to currently dissec
Hi,
On Wed, Nov 13, 2013 at 08:15:12AM -0500, 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 argument.
I'm not sure if it's
Hi Alexis,
On Sun, Nov 10, 2013 at 11:35:02AM +0100, Alexis La Goutte wrote:
> On Sat, Nov 9, 2013 at 1:39 PM, Jakub Zawadzki
> wrote:
> > In few dissectors we're manually disabling some kind of warnings, like
> > in packet-parlay.c
> >
> > #ifdef _MSC_VER
&
Hi,
On Sun, Nov 10, 2013 at 11:50:27AM +0100, Anders Broman wrote:
> The upcoming libpcap 1.5 have support for TPACKET_V3 which seems to
> improve on packet drops at high sped captures.
Finally ;-)
> However some tests on a 1 Gb link with ~900 Mb/s indicates that tcpdump does
> better than dum
Hi,
In few dissectors we're manually disabling some kind of warnings, like
in packet-parlay.c
#ifdef _MSC_VER
/* disable warning: "unreference local variable" */
#pragma warning(disable:4101)
#endif
It's possible to do the same with GCC (4.6) using diagnostics pragmas[1].
Googling around found
On Fri, Nov 08, 2013 at 01:27:40AM +0100, Joerg Mayer wrote:
> On Fri, Nov 08, 2013 at 01:03:47AM +0100, Jakub Zawadzki wrote:
> > After r53150 it works with GCC, at least on my Linux ;-)
>
> And after another commit it also works on my system (32-bit Linux with GCC
> 4.8.2),
On Thu, Nov 07, 2013 at 10:43:26PM +0100, Jakub Zawadzki wrote:
> On Thu, Nov 07, 2013 at 09:52:19PM +0100, Joerg Mayer wrote:
> > On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote:
> > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=5
On Thu, Nov 07, 2013 at 09:52:19PM +0100, Joerg Mayer wrote:
> On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53146
> >
> > User: darkjames
> > Date: 2013/11/07 08:14 PM
> >
> > Log:
> > Add infrastruc
Hi Joerg,
On Mon, Oct 21, 2013 at 11:58:17PM +0200, Joerg Mayer wrote:
> Looks like coverity has a valid complaint:
>
> CID 1109702: Dereference after null check (FORWARD_NULL)
>
> /tshark.c: 2859 ( var_compare_op)
>2856 /* If we're going to print packet information, or we're going to
>
Hi,
> User: eapache
> Date: 2013/10/21 01:07 PM
>
> Log:
> Don't go into a loop if we find a zero-length line. Fixes
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9312
>
> Anders, this may be related to your recent TVB optimizations, since I don't
> think it happened before that? D
On Tue, Oct 15, 2013 at 07:19:34AM +0200, Anders Broman wrote:
> Maynard, Chris skrev 2013-10-15 00:47:
> > Why not add a fence so it's always visible then?
>
> My point is that I don't want to write column info in the VLAN dissector
> to speed up dissection. If it could
> be arranged to only wri
Hi Anders,
Please revert it, dissectors after vlan can be disabled.
If we want to have some lazy COL_INFO calculation - that's fine for me,
but selectively disabling col_add_fstr is NACK for me.
Cheers,
Jakub.
___
Sent via:
Hi,
On Sun, Oct 13, 2013 at 10:17:45AM +0200, Roland Knall wrote:
> I just wanted to bring something by you guys, if it would be worth
> implementing.
>
> I work on the openSAFETY and EPL dissectors. Both are fieldbus
> specific implementations. As such the communicate process images as
> payloa
On Sun, Oct 13, 2013 at 04:43:28PM -0400, Evan Huus wrote:
> On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki
> wrote:
> > About tvb_offset_exists() comment, compute_offset() is not returning
> > exception when offset == tvb->length.
>
> Ah, OK. Should it? When offset =
> On Sun, Oct 13, 2013 at 12:54 AM, wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52578
> >
> > User: eapache
> > Date: 2013/10/13 04:54 AM
> >
> > Log:
[...]
> > All of this is (theoretically) unnecessary - simply checking the offset
> > without
> > worrying abou
On Sat, Oct 12, 2013 at 05:08:04PM -0400, Evan Huus wrote:
> On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus wrote:
> > Now I'm wondering how much of this could be alleviated somehow by a more
> > efficient tree representation...
>
> The answer is apparently lots :)
We've already had similar benchma
On Sun, Sep 29, 2013 at 05:35:59PM -0400, Evan Huus wrote:
> On Sun, Sep 29, 2013 at 3:56 PM, Jakub Zawadzki
> wrote:
> > But back to topic (cause you'll probably see this problem few more times).
> > I don't quite get a point why we need to change everything to wme
On Sun, Sep 29, 2013 at 08:46:23AM -0400, Evan Huus wrote:
> On Sun, Sep 29, 2013 at 8:44 AM, wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52264
> >
> > User: eapache
> > Date: 2013/09/29 12:44 PM
> >
> > Log:
[...]
> > This is one of the first steps towards conv
On Mon, Sep 16, 2013 at 03:17:54PM -0400, Jeff Morriss wrote:
> On 09/16/13 14:57, Guy Harris wrote:
> >
> > On Sep 16, 2013, at 7:20 AM, Anders Broman
> > wrote:
> >
> >> In serv_name_lookup() we call getservbyport() for ports not resolved in
> >> the IANA port list the function
> >> Seems quit
On Mon, Sep 16, 2013 at 06:47:50AM -0400, mman...@netscape.net wrote:
> Is there a way to provide the "unknown string" for the val_to_str call made
> in hf_ registration (ie some derivation of the VALS() macro)?
> There are many proto_tree_add_[u]int_format[_value] calls that are done
> strictly
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
> We already do reassembly and a lot of other stateful work in single-pass
> mode. The only thing two-pass mode provides is the ability to "see the
> future" (for example, saying: this request has a response 5 packets later).
We need two p
On Tue, Aug 27, 2013 at 06:17:13PM -0400, Evan Huus wrote:
> As Anders says, this is because we have no way right now to selectively
> discard it: much of the data is stored in a way that we can only get rid of
> all of it, or none.
I'm not sure why we want to do selectvely discard, I'm fan of 'ge
On Tue, Aug 27, 2013 at 04:37:27PM -0400, Evan Huus wrote:
> We already discard a great deal of state in (single-pass) tshark that we
> keep around in Wireshark (or two-pass tshark).
Really? I'm not so sure about that 'great deal' I think right now
we are only freeing protocol frame data list.
Hi,
>> From: wireshark-dev-boun...@wireshark.org
>> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
>
>> I've run this command on a 10G pcap file.
>
>> ./tshark -r traffic.all -Y "dns.qry.name.len > 50" -w longnames.pcap
>
>> Used memory grows continuously, up to over
On Thu, Aug 22, 2013 at 08:45:06PM +0200, Jakub Zawadzki wrote:
> On Thu, Aug 22, 2013 at 09:16:04AM -0700, Guy Harris wrote:
> >
> > On Aug 22, 2013, at 4:46 AM, Anders Broman
> > wrote:
> >
> > > Should we add code to enable the JIT compiler from dumpcap?
On Fri, Aug 23, 2013 at 10:23:32AM +, Anders Broman wrote:
> > before we change it, should we remember the previous setting and restore it
> > when dumpcap exits?
>
> Preferably yes but I'm not sure it's possible as I think root privileges are
> required to write to the file and I think dump
On Thu, Aug 22, 2013 at 09:16:04AM -0700, Guy Harris wrote:
>
> On Aug 22, 2013, at 4:46 AM, Anders Broman wrote:
>
> > Should we add code to enable the JIT compiler from dumpcap?
>
> Should I add code to enable the JIT compiler to libpcap while I'm at it?
>
> Should the Linux kernel folks ena
On Sat, Aug 17, 2013 at 03:31:47PM +0200, Joerg Mayer wrote:
> Can you commit a conversion tool?
Sure, r51407
> It has begun - good!
The biggest problem during conversation is missing declaration of value_string
or
tfs. It's not portable (in C++) to do forward declaration of structure
(aka http
By the way from ROHC code:
2296 data = (guint8 *)ep_alloc(len);
2299 next_tvb = tvb_new_child_real_data(tvb, data, len, len);
2300 add_new_data_source(pinfo, next_tvb, "Payload");
It's very bad idea to use ep-allocated tvb as data source.
__
On Tue, Aug 13, 2013 at 06:53:42PM +0200, Jakub Zawadzki wrote:
> On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote:
> > Removed in v2:
> >
> > http://www.wireshark.org/~darkjames/proto-new-v2/0001-changes.txt
> > http://www.wireshark.org/~darkjames/pr
On Fri, Aug 16, 2013 at 07:29:17AM +0200, Anders Broman wrote:
> Jakub Zawadzki skrev 2013-08-15 14:04:
> > Few GTK taps are using fd->flags.passed_dfilter as information whether
> > given packet is displayed, this is little broken and might not work as
> > intended.
>
Hi,
On Thu, Aug 15, 2013 at 03:57:07PM +0200, Hardik Patel wrote:
> I am creating dissector plugin. Trace which i have capture is compressed by
> zlib.
>
> I have two option
> 1)write own decompress function using zlib
> 2) to use tvb_uncompress() function of wireshark
>
> Both have issue if com
Hi,
Few GTK taps are using fd->flags.passed_dfilter as information whether
given packet is displayed, this is little broken and might not work as intended.
>From grep:
./ui/gtk/rtp_analysis.c
./ui/gtk/iax2_analysis.c
./ui/gtk/flow_graph.c
flow_graph requres clicking OK to trigger graph_ana
On Wed, Aug 14, 2013 at 02:41:19PM +0200, Alexis La Goutte wrote:
> > Hey, I use it too.I really like it option to modify and save that to file.
> > It can be used to check another protocol value while writing new dissector.
> > http://wiki.wireshark.org/GSoC2013 (Packet Editor)
> >
> > Maybe exper
On Wed, Aug 14, 2013 at 09:26:17AM +0100, Graham Bloice wrote:
> On 13 August 2013 17:53, Jakub Zawadzki wrote:
>
> > On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote:
> > > On Wed, Aug 07, 2013 at 08:10:21PM +0200, Jakub Zawadzki wrote:
> > > > I
Hi,
On Tue, Aug 13, 2013 at 06:15:28PM -0400, Evan Huus wrote:
> Not worth it in my opinion unless the memory savings are significant (I
> suspect they are only in the range of a few-hundred KB).
Yes, something like this.
Exact numbers for few:
proto_names21KB3 insertions(+),
1 - 100 of 441 matches
Mail list logo
