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

ake builds. So either apply a similar change to the autotools build > or use cmake to build (see README.cmake). > > Ciao > Jöarg > > On Fri, Dec 20, 2013 at 01:20:37PM +0200, Kaul wrote: > > Doesn't happen on a fully updated Fedora 19, just on my Fedora 20: >

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

Doesn't happen on a fully updated Fedora 19, just on my Fedora 20: CC libgtkui_a-addr_resolution_dlg.o In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0, from /usr/include/gtk-3.0/gtk/gtkwindow.h:33, from /usr/include/gtk-3.0/gtk/gtkdialo

Re: [Wireshark-dev] [Wireshark-commits] rev 54161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-pdcp-lte.c

Still no go: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9568 : Compilation failure: packet-pdcp-lte.c:1211:12: error: variable 'key' set but not used [-Werror=unused-but-set-variable] Build Information:r54164 -- packet-pdc

Re: [Wireshark-dev] Build instability

+ another failure that's fixed now - and I've managed to get Wireshark to compile! Woohoo! and thanks for the fixes. Y. On Tue, Dec 10, 2013 at 11:44 PM, Kaul wrote: > Also fixed, now epan/dissectors/packet-smpp.c is completely broken. > This should fix it: > svn diff epa

Re: [Wireshark-dev] Build instability

); static guint get_smpp_pdu_len(packet_info *pinfo, tvbuff_t *tvb, int offset); static int dissect_smpp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void* data _U_); On Tue, Dec 10, 2013 at 10:59 PM, Kaul wrote: > And the above has been fixed. > Regretfully, replaced by a

Re: [Wireshark-dev] Build instability

And the above has been fixed. Regretfully, replaced by another compilation failure: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9543 Y. On Tue, Dec 10, 2013 at 8:19 AM, Kaul wrote: > Above compilation failure has been fixed. > Regretfully, only to be replaced by another compi

Re: [Wireshark-dev] Build instability

Above compilation failure has been fixed. Regretfully, only to be replaced by another compilation failure: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9538 On Mon, Dec 9, 2013 at 2:49 PM, Kaul wrote: > Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the >

Re: [Wireshark-dev] To display reserved fields or not display reserved fields, that is the question...

t; > > > *From:* wireshark-dev-boun...@wireshark.org [mailto: > wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul > *Sent:* Monday, 9 December 2013 02:54 > > *To:* Developer support list for Wireshark > *Subject:* [Wireshark-dev] To display reserv

Re: [Wireshark-dev] Build instability

Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9529 on the issue. On Sun, Dec 8, 2013 at 9:52 PM, Jakub Zawadzki wrote: > 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 > >

Re: [Wireshark-dev] Build instability

Mehrtens wrote: > On 12/08/2013 04:30 PM, Kaul wrote: > > Hi all, > > > > I've been trying to enhance a specific dissector for two weeks now. > > Since I'm afraid of diverging the code (although I'm working on a > > specific dissector), I update my

[Wireshark-dev] To display reserved fields or not display reserved fields, that is the question...

Should I: proto_tree_add_text(seg_param_tree, tvb, offset, 2, "reserved"); offset += 2; or: offset += 2; /* reserved */ What is better? (Regretully I'm working on SCSI, whose creators LOVED sprinkling reserved bytes everywhere!). Do we have a standard? (perhaps worth having a global param for

[Wireshark-dev] Build instability

Hi all, I've been trying to enhance a specific dissector for two weeks now. Since I'm afraid of diverging the code (although I'm working on a specific dissector), I update my code base often (~ once a day). Regretfully, 5 times (in 2 weeks!) this has resulted in compilation failure. I'm pretty sur

Re: [Wireshark-dev] Compilation failure - privileges.c: In function 'relinquish_special_privs_perm' - ignoring return value of 'setresgid', declared with attribute warn_unused_result [-Werror=unused-r

On Mon, Aug 20, 2012 at 11:11 PM, Evan Huus wrote: > On Mon, Aug 20, 2012 at 3:49 PM, Kaul wrote: > > Recently (~2 days or so ago?), I've failed to compile wireshark, on > F17/x64: > > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -DINE

[Wireshark-dev] Compilation failure - privileges.c: In function 'relinquish_special_privs_perm' - ignoring return value of 'setresgid', declared with attribute warn_unused_result [-Werror=unused-resul

Recently (~2 days or so ago?), I've failed to compile wireshark, on F17/x64: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -DINET6 -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES "-D_U_=__attribute__((unused))" -D_FO

Re: [Wireshark-dev] Some questions on RPC dissectors (for a new Gluster dissector)

On Fri, Apr 20, 2012 at 6:08 PM, Niels de Vos wrote: > Hi all, > > Bug 5773 was opened as an RFE for implementing a dissector for Gluster. > The Gluster 'protocol' consists out of several RPC-programs, each with > their own set of procedures. > > There are some questions I would like to ask: > >

[Wireshark-dev] Keyboard scan codes

Hi, I was wondering if there is somewhere in Wireshark code definition for keyboard scan codes. I was hoping to re-use if such exists. I'm looking for 101/102 AT keyboard scan codes, specifically (was hoping RDP or VNC would have them, but did not find it, neither did Telnet). I don't think what X

Re: [Wireshark-dev] Wireshark crashes on tvb_get_const_stringz()

On Tue, Mar 20, 2012 at 3:19 PM, Jakub Zawadzki wrote: > On Tue, Mar 20, 2012 at 03:04:23PM +0200, Kaul wrote: > > I might have used tvb_get_const_stringz() incorrectly, yet I don't think > > Wireshark should crash: > > Program received signal S

[Wireshark-dev] Wireshark crashes on tvb_get_const_stringz()

I might have used tvb_get_const_stringz() incorrectly, yet I don't think Wireshark should crash: Program received signal SIGSEGV, Segmentation fault. tvb_get_const_stringz (tvb=0x1c01b60, offset=10, lengthp=0x9) at tvbuff.c:2548 2548 *lengthp = size; I'm not entirely sure why it crashes yet or wh

[Wireshark-dev] Incomplete SSL dissection (when not on standard port)

I sniff traffic on port 8443, which is SSL based. Unless I add to HTTP dissector that port, as SSL based, de-segmentation of SSL records fails (meaning, if it began from the middle of one TCP packet and ends in another, it is not dissected properly). 'Decode As' is what I've used before trying the

[Wireshark-dev] SASL layer dissection - generic dissector?

Is there some ideas for dissecting SASL based authentication generically? I've seen some in LDAP, but I'm sure others can benefit it as well. I couldn't even understand if there is such a thing as 'generic SASL', as it appears most of it is left to the protocol implementation, but still... Otherwis

[Wireshark-dev] Correct and efficient way of displaying bit fields?

I'm struggling for some time now with displaying bitfields, I'm sure there must be something I'm overlooking, or it's just a bit difficult to do in Wireshark. I have a 32bit, little endian field, which I'd like to parse the bits (as set/not set): Example: 05 00 00 00 1 0 0 0 Feature A - set

Re: [Wireshark-dev] core dump on starting wireshark (latest SVN update 39266?)

It was actually the ~/.wireshark/recent_common that caused this - and when you'll look at it, it's obvious why - though I have no clue how I got to this situation. Y. On Wed, Oct 5, 2011 at 10:23 PM, Stephen Fisher wrote: > On Wed, Oct 05, 2011 at 10:07:36PM +0200, Kaul wrote:

Re: [Wireshark-dev] core dump on starting wireshark (latest SVN update 39266?)

On Wed, Oct 5, 2011 at 4:25 PM, Bill Meier wrote: > On 10/5/2011 4:57 AM, Kaul wrote: > > >> It worked before the massive updates of last night (which I'm not sure >> unrelated). It's a bit more difficult to dissect in SVN, so hopefully >> som

[Wireshark-dev] core dump on starting wireshark (latest SVN update 39266?)

(gdb) bt #0 0x00316b8482a0 in g_markup_escape_text () from /lib64/libglib-2.0.so.0 #1 0x004629b6 in welcome_filename_link_new (menu_item=0x1a04d30, label=read_sleb128: Corrupted DWARF expression. ) at main_welcome.c:626 #2 main_welcome_add_recent_capture_file (widget_cf_name=0x185e90

[Wireshark-dev] Display multiple frames (of multiple TCP segments) in COL_INFO

Hi, I've tried to mimic what the SSL dissector does, which is able to display multiple PDUs information in the COL_INFO ('Application Data, Application Data, Application Data' for example). It only partially works: If I have a packet which has: 1. The last part of a PDU which started in previous p

Re: [Wireshark-dev] Latest SVN (r38309) doesn't compile (packet-6lowpan.c)

Strange indeed. I don't recall ever touching that dissector. Sorry for the noise. Y. On Tue, Aug 2, 2011 at 4:42 PM, Bill Meier wrote: > On 8/2/2011 6:47 AM, Kaul wrote: > >> Fedora15/x64, r38309: >> >> packet-6lowpan.c: In function 'dissect_6lowpan_frag_f

[Wireshark-dev] Latest SVN (r38309) doesn't compile (packet-6lowpan.c)

Fedora15/x64, r38309: packet-6lowpan.c: In function 'dissect_6lowpan_frag_first': packet-6lowpan.c:2125:25: error: 'save_fragmented' undeclared (first use in this function) packet-6lowpan.c:2125:25: note: each undeclared identifier is reported only once for each function it appears in packet-6lowp

Re: [Wireshark-dev] New GCC, new option required?

- I've also tried to provide fixes for some (until I got both tired and unable to fix those that result from the ASN.1 definitions) in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5858. - CLANG static analyzer was also quite helpful in finding issues. It just takes hours to compile wireshark

Re: [Wireshark-dev] Crash in capture_dlg.c:1890 (latest SVN)

Looks good, thanks. 2011/4/28 Stig Bjørlykke > On Thu, Apr 28, 2011 at 10:29 AM, Kaul wrote: > > When trying to run wireshark, then - capture -> options from SVN 36928, > > F15beta/x86_64: > > I think this was introduced in revision 36741. > Try the fix in revi

[Wireshark-dev] Crash in capture_dlg.c:1890 (latest SVN)

When trying to run wireshark, then - capture -> options from SVN 36928, F15beta/x86_64: #0 0x003be1a36415 in raise () from /lib64/libc.so.6 #1 0x003be1a37d2b in abort () from /lib64/libc.so.6 #2 0x003be1a723b3 in __libc_message () from /lib64/libc.so.6 #3 0x003be1a788aa in mall

[Wireshark-dev] Failure to run pidl for dce-rpc MAPI dissector

I'm trying the following: [ykaul@ykaul mapi]$ pwd /home/ykaul/wireshark/epan/dissectors/pidl/mapi [ykaul@ykaul mapi]$ ls -ltr total 316 -rw-rw-r--. 1 ykaul ykaul 228274 Apr 27 11:01 mapitags_enum.h -rw-rw-r--. 1 ykaul ykaul 8410 Apr 27 11:01 response.cnf.c -rw-rw-r--. 1 ykaul ykaul 3684 Apr 27

Re: [Wireshark-dev] how to remove/unregister a dissector?

On Tue, Apr 26, 2011 at 9:57 PM, Chris Maynard wrote: > George Nychis writes: > > > Another alternative, is to remove packet-smb* from the build. > > In most cases, to remove unwanted protocol dissectors from the build, > delete the > relevant packet-*.c files from epan/dissectors/Makefile.common

[Wireshark-dev] Trying to fix gcc's 'set but not used' errors on Whireshark

Hi, I'm trying to fix gcc 4.6's 'variable set but not used' errors that wireshark compilation currently produces, via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5858 . I've already fixed quite a few of them. Most are trivial, those that weren't I've remarked in the attachment comments. -

[Wireshark-dev] Compilation failure (mv: cannot stat `.deps/privileges.Tpo': No such file or directory)

r36767, Fedora 15/x64 beta, gcc (GCC) 4.6.0 20110419 (Red Hat 4.6.0-5) : make[2]: Entering directory `/home/ykaul/wireshark/wsutil' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I/usr/local/include '-DPLUGIN_DIR="/usr/local/lib/wireshark/plugins/1.5.2"' -DINE

[Wireshark-dev] Build failure: k12.c:275:11: error: variable 'actual_len' set but not used [-Werror=unused-but-set-variable]

r36676, under F15/x64, gcc (GCC) 4.6.0 20110413 (Red Hat 4.6.0-4) libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I/usr/local/include -DPLUGIN_DIR=\"/usr/local/lib/wireshark/plugins/1.5.2\" -Werror -DINET6 "-D_U_=__attribute__((unused))" -g -O2 -Wall -W -Wextra -Wdeclaration-after-stateme

[Wireshark-dev] Request to review https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4334 and https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5495

I'd appreciate if someone could review and, if approved, check in the above patches. They fix some VNC encoding errors and add some more parsing. Especially the hextile is a bit problematic - it works on single packet hextile encoding only (as no de-sgementation support is available - I have a part

[Wireshark-dev] UDP desegmentation - how to?

Can I use something like tcp_dissect_pdus() for UDP packets? Specifically, Kerberos over UDP - I think we can get the PDU length from the packet and get a complete PDU. ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] [work in progress / stuck] improved dissection for VNC (correct hextile encoding, correct desegmentation)

On Mon, Dec 13, 2010 at 11:29 PM, Christopher Maynard < chris.mayn...@gtech.com> wrote: > Kaul writes: > > > Hi,Attached please find an incomplete, work-in-progress improved > dissection of > the VNC protocol. > > Hi Kaul, I think it would be better to open a bug re

Re: [Wireshark-dev] [work in progress / stuck] improved dissection for VNC (correct hextile encoding, correct desegmentation)

On Wed, Dec 15, 2010 at 4:29 PM, Jeff Morriss wrote: > Kaul wrote: > > 3. Corrected hextile encoding parsing. It's quite wrong the way it's > > done today (see 2nd rectangle in packet 23 of the attached sample > > capture). It completely ignored the fact that the h

[Wireshark-dev] Can someone review https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5372 ?

I keep hitting this bug in my tests. I've provided a partial patch to the bug but also a more general patch to the issue. TIA, Y. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wiresha

Re: [Wireshark-dev] Some more question on TCP desegmentation

On Wed, Dec 1, 2010 at 8:22 AM, Andreas wrote: > Am 30.11.2010 13:05, schrieb Kaul: > > 1. If only some of the segments (say, first 50 out of 70), will I get > that > > partial PDU, or just the original TVB (the first packet, essentially)? > > Don't know what y

[Wireshark-dev] Some more question on TCP desegmentation

1. If only some of the segments (say, first 50 out of 70), will I get that partial PDU, or just the original TVB (the first packet, essentially)? 2. I'm fighting hard with LDAP not being de-segmented properly, only to find out that in tcp_dissect_pdus(), pinfo->can_desgement is false. What could be

[Wireshark-dev] Strange desegmentation code in packet-ssl?

Any idea why isn't the SSL dissector using the straightforward desgementation facilities available by Wireshark? It is left over from ancient times? It seems like a complex piece of work, instead of nicely using the PDUs dissection infrastructure - and I believe that SSL is a classic protocol for t

Re: [Wireshark-dev] Build broken in asn1/x721 (r34777)?

On Thu, Nov 4, 2010 at 5:57 PM, Kaul wrote: > > > On Thu, Nov 4, 2010 at 5:35 PM, Jeff Morriss wrote: > >> Kaul wrote: >> > So how *do* I build Wireshark now? It seems to affect the normal build: >> >> You shouldn't be building anything in the asn1 d

Re: [Wireshark-dev] Build broken in asn1/x721 (r34777)?

On Thu, Nov 4, 2010 at 5:35 PM, Jeff Morriss wrote: > Kaul wrote: > > So how *do* I build Wireshark now? It seems to affect the normal build: > > You shouldn't be building anything in the asn1 directory unless you mean > to be (generally to rebuild those dissectors).

Re: [Wireshark-dev] Build broken in asn1/x721 (r34777)?

eshark/epan/dissectors' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/ykaul/wireshark/epan' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ykaul/wireshark' make: *** [all] Error 2 On Thu, Nov 4, 2010 at 5:20 PM, Jeff Morriss wrote:

[Wireshark-dev] Build broken in asn1/x721 (r34777)?

Trying to re-build the ASN1 dissectors (is 'make' within the ASN1 the right way to do it?) breaks: Making all in x721 make[1]: Entering directory `/home/ykaul/wireshark/asn1/x721' python ../../tools/asn2wrs.py \ \ -p dummy \ -c ./dummy.cnf \ -s ./packet-dummy-template \ -D . \

Re: [Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)

On Tue, Oct 26, 2010 at 5:59 PM, Anders Broman wrote: > Kaul skrev 2010-10-25 23:55: > > > > On Mon, Oct 25, 2010 at 3:30 PM, Jaap Keuter wrote: > >> Hi, >> >> I see no problem here. It loads fine in Wireshark 1.4.1. >> >> What I do see, and which

Re: [Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)

ssapi in multipart_media_type table and in media_type table so it'll recognize it specifically) - bu I still get the exception (because of the missing CR-LF-CR-LF expected?). RFC 1847, section 2.2 seems to show an example - with double CRLF. TIA, Y. Thanks, > Jaap > > On Sun, 24

[Wireshark-dev] Wireshark or protocol bug? (HTTP MIME multipart)

I'm trying to add dissection of Kerberos encrypted HTTP sessions. Mostly, it's OK (got the headers parsed correctly, would file a BZ for this patch soon). However, when I'm trying to work with the body, which is a MIME multipart, it fails with exception. The reason seems to be that it does not have

Re: [Wireshark-dev] Stripping Dissectors from wireshark.

On Fri, Oct 22, 2010 at 4:32 PM, Hadriel Kaplan wrote: > > In wireshark, select "analyze" -> "enabled protocols..." and uncheck > everything you don't need. (though you will need to keep the lower layers > dissected - e.g., for HTTP you'd need to keep Ethernet, IP, TCP selected, > and possibly IPv

[Wireshark-dev] packet-daap.c issues (bugs?)

1. (line 180) tagsize is an int, probably should be an unsigned int (it's a length of a tag). Not sure what happens if a negative value is fetched, but doesn't look right. 2. (line 187) it verifies tvb_offset_exists(tvb, offset) - but then fetches values from 4 and 8 bytes after offset. Probably sh

Re: [Wireshark-dev] Usage of MS protocol documentation in Wireshark

On Tue, Sep 7, 2010 at 11:00 PM, Ed Beroset wrote: > > > > -Original Message- > >From: Eloy Paris > >Sent: Sep 7, 2010 3:11 PM > >To: wireshark-dev@wireshark.org > >Subject: Re: [Wireshark-dev] Usage of MS protocol documentation in > Wireshark > > > >On 09/07/2010 02:20 PM, Stephen Fishe

[Wireshark-dev] Usage of MS protocol documentation in Wireshark

Is it OK to use MS protocols documentation (concrete example - http://msdn.microsoft.com/en-us/library/cc207842.aspx) to enhance Wireshark? Seems so from the notice in the page, but wanted to verify in the list first. TIA, Y. ___

[Wireshark-dev] reduce the size of packet_info

I've just looked at packet_info structure (epan/packet_info.h) and it's huge - everybody keeps something there. 1. I wonder how many times its allocated/de-allocated in a capture - reducing its size (and perhaps creating a pool of pinfo's) might help in performance. I suspect we have 1 per packet,

Re: [Wireshark-dev] clang analysis

On Tue, May 4, 2010 at 10:55 PM, Stephen Fisher wrote: > On Sat, May 01, 2010 at 10:57:51PM +0300, Kaul wrote: > > > I've ran clang static analyser on SVN latest and got the following: > > > Obviously, there's little chance I can fix all of them. I can try fix &g

[Wireshark-dev] missing break in packet-ssl.c

I began fixing packet-ssl.c a bit, according to the clang analyzer output and one of its warnings was alarming: In ssl_looks_like_valid_pct_handshake(), it appears there's a missing break: case PCT_MSG_CLIENT_HELLO0x01: 3907 /* version follows msg byte, so verify that this is valid */ 3908 versio

Re: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?

egards > Anders > Yes, I've just discovered that. And indeed, changing the value in packet-kerberos.c seems to solve the issue. Y. > > -- > *From:* wireshark-dev-boun...@wireshark.org [mailto: > wireshark-dev-boun...@wireshark.org] *On Behalf

[Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?

It appears like MS extensions for Kerberos pre-auth type constants, such as: #define KRB5_PA_PAC_REQUEST -128 /* = 0xFF80 = (gint32)((gint8)0x80) MS extension */ are wrong - should be 128 (which is 0x80 btw), for example, based on a capture I've done and on http://download.microsoft.c

[Wireshark-dev] clang analysis

Hi, I've ran clang static analyser on SVN latest and got the following: Bug Summary Bug TypeQuantityDisplay? All Bugs2769 Dead store Dead assignment1692 Dead increment998 Dead initialization25 Dead nested assignment32 Logic errors Null dereference21 Use of uninitialized value1 Obviously, there's

Re: [Wireshark-dev] RFC: sorted value_string + bsearch

2010/4/12 Jakub Zawadzki > Hi, > > In wireshark there are some large value_string arrays. > Some developers keep them sorted, some don't :) > Sort how? In some cases, wouldn't it make more sense to put the more commonly used string near the top and perform a normal search? I agree it makes sense

Re: [Wireshark-dev] Must build all?

This would be useful to have in some documentation (readme.developer?). Y. On Sun, Apr 11, 2010 at 8:33 AM, Jaap Keuter wrote: > Hi, > > You never said on what platform you develop. > In case of *nix, that depends on where your dissector lives. For a > plugin it's just 'make'. For a buildin one

Re: [Wireshark-dev] How do I call the pkcs1 dissection from another dissector?

On Fri, Mar 26, 2010 at 11:49 PM, Anders Broman wrote: > > > -- > *From:* wireshark-dev-boun...@wireshark.org [mailto: > wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul > *Sent:* den 24 mars 2010 07:51 > > *To:* Developer support list

Re: [Wireshark-dev] Status of enhancement patch [BUG 4610]

Same question, different bug - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422 TIA, Y. On Sat, Mar 27, 2010 at 6:26 PM, Anders Broman wrote: > Committed revision 32306. > > -- > *From:* wireshark-dev-boun...@wireshark.org [mailto: > wireshark-dev-boun...@wi

Re: [Wireshark-dev] How do I call the pkcs1 dissection from another dissector?

reshark > Subject: Re: [Wireshark-dev] How do I call the pkcs1 dissection from > another dissector? > > Kaul wrote: > >> > >> > >> On Fri, Mar 12, 2010 at 12:21 AM, Jeff Morriss >> <http://jeff.morriss.ws>@gmail.com <http://gmail.com>> wrote:

Re: [Wireshark-dev] How do I call the pkcs1 dissection from another dissector?

On Fri, Mar 12, 2010 at 12:21 AM, Jeff Morriss wrote: > Kaul wrote: > > find_dissector("pkcs-1") doesn't seem to be the correct way to do it. > > How do I do it? > > There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How do I > > call it?

[Wireshark-dev] r32134 - "...I hope strtok_s is portable" - no, it isn't

Broke my Linux (Fedora 12, x64) build. Y. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mail

Re: [Wireshark-dev] [PATCH][RFC] show number of segments which were used in the desgementation

n Tue, 2 Mar 2010 09:32:24 +0200, Kaul wrote: > > Attached non-elegant patch shows, in addition to the already shown total > > number of bytes, the number of segments that were used to desegment a > > message. > > It may not be very efficient (and I'm open to suggestions on

[Wireshark-dev] [PATCH][RFC] show number of segments which were used in the desgementation

Attached non-elegant patch shows, in addition to the already shown total number of bytes, the number of segments that were used to desegment a message. It may not be very efficient (and I'm open to suggestions on how to enhance it) but it works. diff against SVN r32082. TIA, Y. reassemble.c.dif

[Wireshark-dev] How do I call the pkcs1 dissection from another dissector?

find_dissector("pkcs-1") doesn't seem to be the correct way to do it. How do I do it? There's a PKCS1 blob I want the PKCS#1 dissector to dissect. How do I call it? I can create a TVB for it, of course. TIA, Y. ___ Sent via:

[Wireshark-dev] enum or #define?

Which one is better? option 1: #define SSL_HND_HELLO_REQUEST 0 #define SSL_HND_CLIENT_HELLO 1 ... or perhaps, option 2: enum { SSL_HND_HELLO_REQUEST, SSL_HND_CLIENT_HELLO, }; ... and then (in both cases): const value_string ssl_31_handshake_type[] = { { SSL_HND_HELLO_REQU

Re: [Wireshark-dev] constify some functions in proto.c / tvbuff.c

Thanks in advance, Y. On Mon, Jan 25, 2010 at 11:23 PM, Kaul wrote: > On Mon, Jan 25, 2010 at 10:41 PM, Jaap Keuter wrote: > >> Hi, >> >> Note that this patch pushes more than just consts, but also changes in the >> VNC >> dissector and packet-redc as a PIDL

Re: [Wireshark-dev] constify some functions in proto.c / tvbuff.c

of course . I just wanted to get feedback if the 'constifying' will be accpetable - I'll submit it as a patch-per-file appropriately, when it's ready, and via bugzilla. Thanks, Y. > Thanks, > Jaap > > > Kaul wrote: > > Re-attaching diff - now without conflicts. &

Re: [Wireshark-dev] Failing to get my tree to show - problem solved, but I don't understand why

from the packet info*. Everything works beautifully afterwards (attached changed code - mainly the addition in lines 290-297 - which fetch the per packet information and use it.) I'd still be happy to understand why this works now (also as a lesson for others). Y. On Wed, Jan 20, 2010 at 1

Re: [Wireshark-dev] Failing to get my tree to show

On Tue, Jan 19, 2010 at 1:09 AM, Guy Harris wrote: > > On Jan 16, 2010, at 10:39 AM, Kaul wrote: > > > From README.developer: > > "Wireshark distinguishes between the 2 modes with the proto_tree pointer" > > I'll look at rewriting that to clarif

Re: [Wireshark-dev] Failing to get my tree to show

On Sat, Jan 16, 2010 at 4:30 AM, Guy Harris wrote: > > On Jan 15, 2010, at 1:50 PM, Kaul wrote: > > > Hi, > > > > I'm trying to write a new dissector, and failing miserably getting my > tree to show, because the tree I'm getting in my dissect_PROTONAME()

[Wireshark-dev] Failing to get my tree to show

Hi, I'm trying to write a new dissector, and failing miserably getting my tree to show, because the tree I'm getting in my dissect_PROTONAME() is always NULL, not sure why. I'm dissecting over TCP, with (regretfully) my own desegmentation: packets 1-3 are syn, syn-ack, ack. packet 4 is a start of

[Wireshark-dev] How to parse a protocol with two different PDU types in a single connection?

Hello, I have a protocol that begins with a PDU of type A ('link' state), then switches after it performed some negotiation to a PDU type B ('data' state). I've tried something similar to: conversation = find_conversation(pinfo->fd->num, &pinfo->src, &pinfo->dst, pinfo->ptype, pinfo->srcport, pinf

Re: [Wireshark-dev] Next releases

On Fri, May 15, 2009 at 9:27 PM, Gerald Combs wrote: > Next week I plan on releasing 1.2.0rc1 and 1.0.8. The 1.2.0rc1 release > will include creating a /trunk-1.2 branch in SVN. If you need me to > postpone the branch or release, please let me know. > > I've started working on the release notes (

[Wireshark-dev] proto_tree_add_uint() taking the value from the packet, not from the value param?

>From readme.developer, it appears the value to be displayed by proto_tree_add_uint should be the 'value' param: proto_tree_add_uint(tree, id, tvb, start, length, value) However, I'm trying something like: proto_tree_add_uint(subrect_tree, hf_vnc_hextile_subrect_width, tvb, *offset, 1, 3); And I'm

[Wireshark-dev] Splitting packet_info struct for performance reasons?

I was astounded with the huge size of packet_info structure. I believe in 99% of the cases, there is no need for many of the fields within the structure. Wouldn't it make sense, for performance reasons, to leave the most usable ones within it, and create a pointer to an extra structure with the oth

[Wireshark-dev] Compilation fails on Kerberos issues

SVN, on XP SP3, using VC 2008EE. Commented-out: PCRE_DIR, GNUTLS_DIR, KFW_DIR, NETTLE_DIR, LUA_DIR and it fails to compile: Creating library libwireshark.lib and object libwireshark.exp dissectors.lib(packet-kerberos.obj) : error LNK2019: unresolved external symbol _krb5_kt_cl...@8 referenced in

[Wireshark-dev] SOLVED: Re: Issue with 1.1.2 and latest SVN (27315) - on Win32 - Wireshark is not displayed

The issue was that in the recently used files there were some files on the network path - that was unavailable anymore. After 10 minutes Wireshark loaded, I've cleared the list and now it loads fine. Not sure if we should do something about it or not. On Wed, Jan 28, 2009 at 9:58 AM, Kaul

[Wireshark-dev] Issue with 1.1.2 and latest SVN (27315) - on Win32 - Wireshark is not displayed

For some reason, when I'm launching Wireshark (both 1.1.2 and SVN 27315, on XP, SP3), after it is done with all the dissector loading stuff, the UI disappears - and does not appear. The process is still alive, with one thread, not doing much. Process Explorer of it: ... kernel32.dll!FindFirstFileW

Re: [Wireshark-dev] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

Anyone had a chance to look at this patch? On Sun, Jan 4, 2009 at 12:29 AM, Kaul wrote: > Attached please find a patch that enables to heuristically find VNC traffic > on non-standard ports. > > (it also adds some if(tree) ... around some proto_tree_add_item() > functions) >

Re: [Wireshark-dev] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

Attached please find a patch that enables to heuristically find VNC traffic on non-standard ports. (it also adds some if(tree) ... around some proto_tree_add_item() functions) Y. On Sun, Dec 28, 2008 at 11:50 PM, Stephen Fisher wrote: > On Sun, Dec 28, 2008 at 11:34:55PM +0200, Kaul wr

[Wireshark-dev] packet-vnc.c - DEST_PORT_VNC macro - is it even needed?

It seems to be used to check according to very specific destination ports, if we should dissect the messages as client to server or server to client messages. I'm not sure why not just compare the current destination port with the one we've saved in the conversation. This will avoid erroneous disse

Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

t's obviously incomplete, in the sense that SASL buffers probably may be bigger than my above 4*64K, but it fixes my issue and leaves room for fixing it in a general manner. Comments are welcome, Y. On Thu, Jun 12, 2008 at 11:53 PM, Kaul <[EMAIL PROTECTED]> wrote: > Oh, that may explai

Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

SVN 25443 - same behavior. On Thu, Jun 12, 2008 at 11:49 PM, Jaap Keuter <[EMAIL PROTECTED]> wrote: > Hi, > > Can you test the last buildbot build? You can find it here: > http://www.wireshark.org/download/automated/win32/ > > Thanx, > Jaap > > Kaul wrote: > &

Re: [Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

(tvb, 0); *if*( sasl_len<2 ){ *goto* *this_was_not_sasl*; } *if*( sasl_len>*65535* ){ *goto* *this_was_not_sasl*; } Apparently, the above assumption is wrong. Y. On Thu, Jun 12, 2008 at 11:40 PM, Kaul <[EMAIL PROTECTED]>

[Wireshark-dev] Failure to dissect long SASL wrapped LDAP response

Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP response. Regretfully, I cannot share the capture, but the first packet that is not desgemented or dissected in any way (just shows as TCP payload) is (pa

Re: [Wireshark-dev] LDAP GUID display bug?

Well, this is exactly the bug - that it disregards the endianness of it. On Feb 12, 2008 6:08 PM, Lars Friedrichs <[EMAIL PROTECTED]> wrote: > Hi Kaul, > > that is simply network byte order vs. host byte order. on the network all > numbers are transfered big endian style so th

[Wireshark-dev] LDAP GUID display bug?

Running 0.99.7, on Windows, capturing Active Directory LDAP communication, there's some wrong display of GUIDs (object type objectGUID). For example, what on the wire looks like (hex) 25 ff 7e 7d 1a f2 a2 49... should be 7d7eff25-f21a-49a2-... (I think the rest is like the wire). However, I see tha

[Wireshark-dev] [PATCH] packet-sctp.c: rename SERIAL_NUMBER_LENGTH to SCTP_SERIAL_NUMBER_LENGTH to fix compilation failure

On Windows, with both MSVC 2005 express and MSVC 2008 express, compilation fails due to redefinition of SERIAL_NUMBER_LENGTH. Changed it to SCTP_SERIAL_NUMBER_LENGTH to avoid the collision. packet-sctp.c.diff Description: Binary data ___ Wireshark-dev m

Re: [Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

Fisher <[EMAIL PROTECTED]> wrote: > On Tue, Dec 11, 2007 at 09:01:13AM +0200, Kaul wrote: > > > Thanks, I've tried that, but it didn't help. Can you tell me where > > your hmac.h and/or des.h files are located? > > I actually don't seem to have those files.

Re: [Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

Thanks, I've tried that, but it didn't help. Can you tell me where your hmac.h and/or des.h files are located? On Dec 11, 2007 12:31 AM, Stephen Fisher <[EMAIL PROTECTED]> wrote: > On Sun, Dec 02, 2007 at 10:05:16PM +0200, Kaul wrote: > > I can't compile latest S

[Wireshark-dev] packet-dlm compilation errors

In addition to the inability to compile Wireshark (at least on my Windows) for at least a week, due to problem with include files in kerberos, I'm now also getting: packet-dlm3.c packet-dlm3.c(557) : error C2065: 'uint16_t' : undeclared identifier packet-dlm3.c(557) : error C2146: syntax error : mi

[Wireshark-dev] Compilation failure: cannot open include file: 'hmac.h' (packet-isakmp.c) / 'des.h' (packet-kerberos.c)

I can't compile latest SVN for the last two days or so, getting: packet-kerberos.c(74) : fatal error C1083: Cannot open include file: 'des.h': No such file or directory ... packet-isakmp.c(50) : fatal error C1083: Cannot open include file: 'hmac.h': No such file or directory ... packet-dcerpc-nt

Re: [Wireshark-dev] Wireshark 0.99.7pre1 is now available

development branch to 0.99.7 before release. > > Please test the last svn version if it really helps. > > Tomas > > > -- > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Kaul > *Sent:* Friday, November 23, 2007 9:24 AM

Re: [Wireshark-dev] Wireshark 0.99.7pre1 is now available

It crashes on reassembling a segmented XML (over HTTP - I reckon an RSS feed). I thought all along it had something to do with my (yet unaccepted) changes to packet-http.c and req_resp_hrds.c , so didn't want to bother the list with it, but it just happened with a clean install of the binary as wel

  1   2   >