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
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
> 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
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
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:
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
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
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
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
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
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
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()?
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
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
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
*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
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
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
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
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
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
21 matches
Mail list logo