The Buildbot has detected a new failure of OSX-10.5-ppc on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-ppc/builds/1518
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-ppc
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2859
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2856
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
On Jul 7, 2009, at 1:02 PM, Stephen Fisher wrote:
> Yes.
(Actually, the ANSI C standard doesn't mandate that a null pointer
have all its bits zero, so there's no guarantee that, for example,
memset(xxx, 0, yyy) will set pointers to null.
However, null pointers are implemented, on all platfo
The Buildbot has detected a new failure of Ubuntu-7.10-x86-64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Ubuntu-7.10-x86-64/builds/1223
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: ubuntu-7.10-x86
Bui
Yes. Also, since you changed the allocator to zero out the data at
allocation time (g_new0), you don't need to set any of the pointers to
NULL either.
On Mon, Jul 06, 2009 at 03:37:42PM +, etx...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28955
Hi,
Indeed. The Windhose dynamic linking system is so broken you can't use data
from
one DLL in another. That was what it boiled down to.
Thanx,
Jaap
Anders Broman wrote:
> Hi,
> I think there is a problem to export DATA to plugins, I think some one
> explained it a (long)while ago
> But I
On Tue, Jul 07, 2009 at 10:46:52AM -0700, Alex Lindberg wrote:
> I am creating an extended protocol plugin that requires extending a
> value_string array that exists in epan/dissectors/packet-foo.c file
> defined like:
>
> static const value_string foo_name_vals[] = {
> ? {? 0, "Foo Name 1" },
I am creating an extended protocol plugin that requires extending a
value_string array that exists in epan/dissectors/packet-foo.c file defined
like:
static const value_string foo_name_vals[] = {
{ 0, "Foo Name 1" },
{ 1, "Foo Name 2" },
{ 2, "Foo Name 3" },
{ 0, NULL }
};
This arra
On 7. juli. 2009, at 18.49, Bill Meier wrote:
> Right: I would guess that all the value_strings used in the plugins
> are
> defined in the plugin and that this is also true for true_false
> strings
> used in plugins
I was looking at eap_code_vals[], defined in epan/dissectors/packet-
eap.c (
Stig Bjørlykke wrote:
> On 7. juli. 2009, at 18.02, Bill Meier wrote:
>
>
> I know value_string's are used in plugins, so it should be possible.
> But I'm no windows user so I have to say pass on this one...
>
>
Right: I would guess that all the value_strings used in the plugins are
defin
Hi,
I think there is a problem to export DATA to plugins, I think some one
explained it a (long)while ago
But I don't remember exactly what the problem was - something with Windows and
dll:s
Reagrds
Anders
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-d
On 7. juli. 2009, at 18.02, Bill Meier wrote:
> Also: given the typedef for true_false_strings, I'm curious as to the
> rationale for the changes like the following:
>
> WS_VAR_IMPORT const true_false_string tfs_true_false;to
> WS_VAR_IMPORT const true_false_string tfs_true_false[];
D
Stig Bjørlykke wrote:
> On Tue, Jul 7, 2009 at 4:48 PM, Bill Meier wrote:
>> Stig Bjørlykke wrote:
>>> Does r28985 fix this issue?
>> I'll give it a try; (Maybe that's the real problem).
>
> If this works I have a patch for all plugins dissectors.
>
>
The compile of packet-esl still fails with
The Buildbot has detected a new failure of Solaris-10-SPARC on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Solaris-10-SPARC/builds/1934
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: solaris-10-sparc
Build
The Buildbot has detected a new failure of OSX-10.5-ppc on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-ppc/builds/1504
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-ppc
Build Reason:
Bui
On Tue, Jul 7, 2009 at 4:48 PM, Bill Meier wrote:
> Stig Bjørlykke wrote:
>> Does r28985 fix this issue?
> I'll give it a try; (Maybe that's the real problem).
If this works I have a patch for all plugins dissectors.
--
Stig Bjørlykke
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2843
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
Stig Bjørlykke wrote:
> On Tue, Jul 7, 2009 at 4:26 PM, wrote:
>> Various fixes:
>> 1. For some reason: using an using the external tfs_yes_no doesn't work in
>> a plugin;
>
> Does r28985 fix this issue?
>
>
I'll give it a try; (Maybe that's the real problem).
(On a separate note & FYI: I
On Tue, Jul 7, 2009 at 4:26 PM, wrote:
> Various fixes:
> 1. For some reason: using an using the external tfs_yes_no doesn't work in a
> plugin;
Does r28985 fix this issue?
--
Stig Bjørlykke
___
Sent via:Wireshark-d
Hey,
Daryl Straszheim wrote:
> We had written a set of private plugin dissectors under wireshark-1.0.4.tar.gz
> We had patched the top level makefiles to add our plugin directories to the
> different lists.
> Now we're trying to upgrade the code base to wireshark-1.2.0.tar.gz.
>
> I see in sever
Stig Bjørlykke wrote:
> On 27. juni. 2009, at 12.31, etx...@wireshark.org wrote:
>
>> Directory: /trunk/epan/dissectors/pidl/mapi/
>> ChangesPath Action
>> +1 -1 mapi.cnf Modified
>> +1 -1 request.cnf.c Modified
>> +1 -1 response.cnf.cModified
>
On Mon, Jul 06, 2009 at 06:35:13PM +, etx...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28961
>
> User: etxrab
> Date: 2009/07/06 11:35 AM
>
> Log:
> From Kovarththanan Rajaratnam:
> More "Cleanup header_field_info definitions"
>
> Directory: /t
The Buildbot has detected a new failure of Windows-XP-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-XP-x86/builds/6473
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-xp-x86
Build Reason
The Buildbot has detected a new failure of Windows-XP-Win64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-XP-Win64/builds/856
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-xp-win64
Build R
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2840
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2838
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
Hello All,
I have the following problem that iam trying to work out with the help of
Wireshark
1. I have log files that keep getting updated with SS7 traces being captured
on ATM links.
2. Using text2pcap the files are being processed and viewed in the
wireshark.
As the files keep getting updat
28 matches
Mail list logo