On Jul 7, 2010, at 4:53 PM, Ian Schorr wrote:
> You're right - that's not a new issue in 33458. 33457 has the same problem.
What version of 10.5 are you running? Is it 10.5.8 (the last Software Update),
possibly with Security Updates?
That problem has shown up in
https://bugs.wiresh
You're right - that's not a new issue in 33458. 33457 has the same problem.
-Ian
On Thu, Jul 8, 2010 at 4:21 AM, Guy Harris wrote:
> Did the build before 33458 work on PPC? I suspect not - that's an issue of
> the libraries with which wireshark-bin is built, and wireshark-bin (i.e., the
> ac
Guy Harris skrev 2010-07-07 20:32:
> On Jul 7, 2010, at 11:13 AM, Gerald Combs wrote:
>
>
>> It looks like plugins/asn1/packet-asn1.c has a similar problem.
>>
> Ultimately, packet-asn1.c should probably be made to use the packet-ber.c
> routines.
>
Or be retiered I'm not sure it's u
The Buildbot has detected a new failure of Ubuntu-10.04-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Ubuntu-10.04-x64/builds/257
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: ubuntu-10.04-x64
Build R
Jeff Morriss wrote:
> Gerald Combs wrote:
>> Shouldn't we remove recursion from try_get_ber_length or at least throw
>> an exception when we run into, say, 5 levels of nesting?
>
> I don't know enough to say what's a valid depth.
>
> In looking at the sample captures I have, I only got to a depth
David Aggeler wrote:
> In my opinion the numerous checks for check_col() in the dissectors.are
> superfluous (and confusing).
> All col_set_() functions in column-utils.c correctly check for the
> precondition.
> And the precondition is better placed in column-utils.c. Once done,
> removing
Jeff Morriss wrote:
> Gerald Combs wrote:
>> morr...@wireshark.org wrote:
>>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33464
>>>
>>> User: morriss
>>> Date: 2010/07/07 08:52 AM
>>>
>>> Log:
>>> Fix infinite recursion reported in
>>> https://bugs.wireshark.org/bugzilla/show
Gerald Combs wrote:
> morr...@wireshark.org wrote:
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33464
>>
>> User: morriss
>> Date: 2010/07/07 08:52 AM
>>
>> Log:
>> Fix infinite recursion reported in
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4984 : In
>> try_g
On Jul 7, 2010, at 11:13 AM, Gerald Combs wrote:
> It looks like plugins/asn1/packet-asn1.c has a similar problem.
Ultimately, packet-asn1.c should probably be made to use the packet-ber.c
routines.
___
Sent via:Wiresha
I was always wondering, why I would need to have *two* objects for an
item containing a subtree. Doing debugging I realized, that its one and
the same object.
and both types (proto_tree/proto_item) origin in proto_node. That makes
much more sense.
Any objection to use proto_item_append_text(
On Jul 6, 2010, at 6:26 PM, Ian Schorr wrote:
> r33458 Intel 64-bit now works for me. A couple of recent builds,
> including 33452, did not (32-bit did and still does).
>
> r33458 PPC crashes for me, with:
>
> 2010-07-07 11:31:06.785 defaults[24422:10b]
> The domain/default pair of (kCFPrefere
morr...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33464
>
> User: morriss
> Date: 2010/07/07 08:52 AM
>
> Log:
> Fix infinite recursion reported in
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4984 : In
> try_get_ber_length() make sure we
In my opinion the numerous checks for check_col() in the dissectors.are
superfluous (and confusing).
All col_set_() functions in column-utils.c correctly check for the
precondition.
And the precondition is better placed in column-utils.c. Once done,
removing the export would be the logical
Peter Gordon wrote:
> tshark can be used to display fields using the -T option.
> If the same field occurs a number of times within a protocol,
> only one value ( the last ) gets displayed.
>
> As far as I can see the error looks like it comes from the
> routine proto_tree_write_fields.
>
> The
Anders Broman wrote:
>
> Hi,
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33100
> Broke this usage of tshark:
>
> tshark -i eth2 -w /tmp/sip.log -R sip -f "((net 10.80.28.96/27 and not iphost
> 10.80.28.106) or net 10.80.29.128/25)" -z proto,colinfo,sip.Event,sip.Event
>
tshark can be used to display fields using the -T option.
If the same field occurs a number of times within a protocol,
only one value ( the last ) gets displayed.
As far as I can see the error looks like it comes from the
routine proto_tree_write_fields.
The -T pdml option gives the correct ou
On Jul 6, 2010, at 11:52 PM, Guy Harris wrote:
> Yeah, yeah, yeah. We just needed more toxoplasmosis:
>
> http://www.slate.com/id/2259350/pagenum/all/
>
> (U.S. 12%, Ghana 92%).
P.S. No, I'm not seriously suggesting that the US lost because of relative
toxoplasmosis levels. I don't ev
Hi,
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33100
Broke this usage of tshark:
tshark -i eth2 -w /tmp/sip.log -R sip -f "((net 10.80.28.96/27 and not iphost
10.80.28.106) or net 10.80.29.128/25)" -z proto,colinfo,sip.Event,sip.Event -z
proto,colinfo,sip.Contact,sip.Cont
Hi,
I've been toying with the idea of speeding up filtering by saving the
"Protocols in frame" string in the frame data structure a
g_string_chunk could be used to reduce the memory fotprint. When entering a
filter the matching protocol(s) could be found(?)
Then when the rescanning of packets is
19 matches
Mail list logo
