Re: [Wireshark-dev] [Wireshark-commits] rev 36988: /trunk/ /trunk/epan/dissectors/: packet-iwarp-mpa.c packet-spnego.c packet-ssl-utils.c /trunk/: tap-iostat.c

2011-05-04 Thread Jakub Zawadzki
On Wed, May 04, 2011 at 04:40:12PM -0600, Stephen Fisher wrote: > On Wed, May 04, 2011 at 09:19:08PM +, darkja...@wireshark.org wrote: > > > Log: > > XXX, should this code use g_try_malloc instead? > > is that inside GTK+ and GLib, > they still use g_malloc, so we can't totally eliminate th

Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem

2011-05-04 Thread Risto Paasila
On 5 May 2011 12:59, Risto Paasila wrote: >> Subject: Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem >> Did I miss something? a arbitrary long field of binary data can not be FT_STRING. /Anders >>> >>>The field that I initially had in question was: >>> >>>  correlationID

Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem

2011-05-04 Thread Risto Paasila
> Subject: Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem > >>> Did I miss something? a arbitrary long field of binary data can not be >>> FT_STRING. >>> /Anders >> >>The field that I initially had in question was: >> >>  correlationID [0] IMPLICIT OCTET STRING (SIZE(14)) >> >>So it sho

[Wireshark-dev] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis

2011-05-04 Thread buildbot-no-reply
The Buildbot has detected a new failure of Visual-Studio-Code-Analysis on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Visual-Studio-Code-Analysis/builds/641 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: vs

[Wireshark-dev] buildbot failure in Wireshark (development) on Windows-7-x64

2011-05-04 Thread buildbot-no-reply
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/1736 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: windows-7-x64 Build Reason:

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Max Dmitrichenko
2011/5/5 Jeff Morriss : > > I did stumble across a (apparently unrelated) problem in that it will fail > if you see a gap while the subdissector is returning > DESEGMENT_ONE_MORE_SEGMENT (as HTTP does until it gets all the headers): in > that case TCP has to assume that the current message is not p

Re: [Wireshark-dev] [Wireshark-commits] rev 36988: /trunk/ /trunk/epan/dissectors/: packet-iwarp-mpa.c packet-spnego.c packet-ssl-utils.c /trunk/: tap-iostat.c

2011-05-04 Thread Stephen Fisher
On Wed, May 04, 2011 at 09:19:08PM +, darkja...@wireshark.org wrote: > Log: > Cleanup: g_malloc can't return NULL, remove checks for them. > > XXX, should this code use g_try_malloc instead? That's a good question and it keeps coming up. I think the main reason we we haven't moved every

[Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets

2011-05-04 Thread Fernandez, Rafael
Hi, I am writing a dissector plugin and I am using tcp_dissect_pdus in order to reassemble packets. However, I am experiencing issues when there are multiple application layer messages in one packet and the last one is not complete. Specifically, I have 5 messages in one TCP packet. There are 5

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Sake Blok
On 4 mei 2011, at 23:33, Jeff Morriss wrote: > Sake Blok wrote: >> On 4 mei 2011, at 22:48, Jeff Morriss wrote: >>> Sake Blok wrote: One case that can cause a problem is when the first segment of a PDU is received out-of-order. Or did your recent work also handle this exception, J

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Jeff Morriss
Max Dmitrichenko wrote: 2011/5/5 Jeff Morriss : I would think desegment_tcp() should be able to handle this by not calling your dissector for an out-of-order segment: it should be able to only call your dissector once it has a completely reassembled (desegmented) PDU. Did you mean using of tc

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Jeff Morriss
Sake Blok wrote: On 4 mei 2011, at 22:48, Jeff Morriss wrote: Sake Blok wrote: On 4 mei 2011, at 22:11, Jeff Morriss wrote: Max Dmitrichenko wrote: Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous w

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Max Dmitrichenko
2011/5/5 Jeff Morriss : > I would think desegment_tcp() should be able to handle this by not calling > your dissector for an out-of-order segment: it should be able to only call > your dissector once it has a completely reassembled (desegmented) PDU. Did you mean using of tcp_dissect_pdus()?

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Sake Blok
On 4 mei 2011, at 22:48, Jeff Morriss wrote: > Sake Blok wrote: >> On 4 mei 2011, at 22:11, Jeff Morriss wrote: >>> Max Dmitrichenko wrote: Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Max Dmitrichenko
2011/5/5 Jeff Morriss : > Sake Blok wrote: >> >> On 4 mei 2011, at 22:11, Jeff Morriss wrote: >> >>> >>> I would think desegment_tcp() should be able to handle this by not >>> calling your dissector for an out-of-order segment: it should be able to >>> only call your dissector once it has a complet

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Jeff Morriss
Sake Blok wrote: On 4 mei 2011, at 22:11, Jeff Morriss wrote: Max Dmitrichenko wrote: Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous was lost. Since I'm trying to decrypt it, I fail with it and bre

Re: [Wireshark-dev] Fragmentation

2011-05-04 Thread Rick Bywater
*David, It sounds like you might have some inside information that I could use. I am developing a dissector which decodes a protocol running on top of UDP. It uses the fragment_add_seq_next to string together all of the packets. It is quite complicated as I often see multiple packets of my proto

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Sake Blok
On 4 mei 2011, at 22:11, Jeff Morriss wrote: > Max Dmitrichenko wrote: >> Hi! >> I'm continue to write dissector for an encrypted protocol. Everything >> works fine until I receive an out-of-order TCP segment, i.e. previous >> was lost. >> Since I'm trying to decrypt it, I fail with it and break

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Jeff Morriss
Max Dmitrichenko wrote: Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous was lost. Since I'm trying to decrypt it, I fail with it and break the whole decryption context. Is there any way to: 1) Detect

Re: [Wireshark-dev] [Wireshark-commits] rev 36978: /trunk/gtk/ /trunk/gtk/: io_stat.c

2011-05-04 Thread Jeff Morriss
Anders Broman wrote: Joerg Mayer skrev 2011-05-03 23:28: On Tue, May 03, 2011 at 04:51:13PM +, etx...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=36978 Log: Do some prep work on GUIManager code, if you enable it it will break as the menus.c chang

Re: [Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Mikko Saarnivala
Oon perjantaina toimistolla. Mikko Max Dmitrichenko wrote: >Hi! > >I'm continue to write dissector for an encrypted protocol. Everything >works fine until I receive an out-of-order TCP segment, i.e. previous >was lost. >Since I'm trying to decrypt it, I fail with it and break the whole >decrypt

[Wireshark-dev] Handling TCP packets reordering

2011-05-04 Thread Max Dmitrichenko
Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous was lost. Since I'm trying to decrypt it, I fail with it and break the whole decryption context. Is there any way to: 1) Detect that this packet is out of