On Wed, Mar 28, 2007 at 04:07:34PM -0400, Maynard, Chris wrote:
> 1) epan/crypt/Makefile.common does not get copied to
> packaging/rpm/BUILD/wireshark-0.99.5/epan/crypt/.
Fixed with revision 21267. We forgot to add it to the distribution
tarball.
Ciao
Joerg
--
Joerg Mayer
Hi Graham,
I followed each and every step faithfully as given in Developer's
guide , but still I am not able to get the source and I get the same error.
I download source from
http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz
separately(without SVN), untarred it thr
Bryant Eastham wrote:
> Gerald Combs wrote:
>
>> /trunk-0.99.2 was copied from /trunk last week. Once the 0.99.2 release
>
>> is made it will be moved to /releases/wireshark-0.99.2. Some time in
>
>> the future we'll start over again by copying /trunk to /trunk-0.99.3.
>
> Sorry to sound like
ronnie sahlberg wrote:
> :-)
>
> Well those files are not supposed to be manually edited/modified
> anyway.
I know, I know, that's the reason of the header comment, but I couldn't
find another way :-(
>
> I can change PIDL to always emit
>
> #ifdef _MSC_VER
> #pragma warning(disable:4005)
> #pr
Hi List!
I've just stumbled over ohloh.net, which do code metrics for various
open source projects.
The Wireshark related pages are at:
http://www.ohloh.net/projects/3805
I found it interesting to look at the "Contributors" tab ...
Unfortunately, the metrics only took into account the code
Hi List!
Just stumbled over "Gtk+ for Mac OS X":
http://developer.imendio.com/projects/gtk-macosx
which is a native port of GTK+ - so you won't need an X server. The
screenshots suggests to be aimed towards bringing a native "The Gimp" to
the MAC.
The project seems to be in early beta (or may
:-)
Well those files are not supposed to be manually edited/modified anyway.
I can change PIDL to always emit
#ifdef _MSC_VER
#pragma warning(disable:4005)
#pragma warning(disable:4013)
#endif
at the head of the file.
Are there any other pramgas you want it to emit as well?
On 3/29/07,
[EMAIL PROTECTED] wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21256
>
> User: sahlberg
> Date: 2007/03/29 12:26 AM
>
> Log:
> update winreg to the latest idl
>
> Directory: /trunk/epan/dissectors/
> ChangesPath Action
> +221 -18 packet-d
On Wed, 28.Mar.07 16:41:59 -0700, Stephen Fisher wrote:
> The dissector file packet-jxta.c has a comment saying that an allocation
> is a memory leak:
>
> if (NULL != found_addr) {
> found_addr->type = AT_URI;
> found_addr->len = strlen(*current_token);
> /* FIXME 20050605 b
On Mar 28, 2007, at 2:28 PM, Bryan Miller wrote:
> Guy, I am in agreement and that is what I anticipate doing with the
> bulk of my
> work. I this particular case the protocol is proprietary and will
> likely not
> become public until 2008.
So is this an extension to an existing protocol, o
The dissector file packet-jxta.c has a comment saying that an allocation
is a memory leak:
if (NULL != found_addr) {
found_addr->type = AT_URI;
found_addr->len = strlen(*current_token);
/* FIXME 20050605 bondolo THIS ALLOCATION IS A MEMORY LEAK! */
found_addr->
checked in
On 3/27/07, Martin Sustrik <[EMAIL PROTECTED]> wrote:
> Hi Ronnie,
>
> here's a patch to AMQP dissector. The only change is that when there are
> seceral AMQP frames in single TCP packet, all of them are referred in
> the info column.
>
> Can you check it in?
>
> Thanks.
> Martin
>
After a deeper analysis of some captures I have I've got to the
conclusion that it is not a good idea. The GT is something different
that what i believed it to be.
I was considering a way to group together TCAP transactions taking
into account that for some of those I've seen responses coming from
On Wed, Mar 28, 2007 at 04:07:34PM -0400, Maynard, Chris wrote:
> 2) Ran into an "undefined reference" problem. Here's the relevant
> output:
>
> gtk/libui.a(ssl-dlg.o)(.text+0x1f3e): In function
> `follow_find_button_cb':
> /home/username/wireshark-0.99.5/packaging/rpm/BUILD/wireshark-0.99.5/gt
Hi,
Looking again the basic problem is asn2wrs not handling constructs like:
--InitiatingMessage ::= SEQUENCE {
-- procedureID
NBAP-ELEMENTARY-PROCEDURE.&procedureID ({NBAP-ELEMENTARY-PROCEDURES}),
-- criticality
NBAP-ELEMENTARY-PROCEDURE.&criticality
([EMAIL PROTECTED]),
-- message
Guy, I am in agreement and that is what I anticipate doing with the bulk of my
work. I this particular case the protocol is proprietary and will likely not
become public until 2008.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
Sent: Wednesda
While attempting to build a Wireshark .rpm on a Red Hat Enterprise Linux
system (Taroon, update 8), I ran into 2 problems:
1) epan/crypt/Makefile.common does not get copied to
packaging/rpm/BUILD/wireshark-0.99.5/epan/crypt/.
To quickly circumvent that problem, I manually copied the file once the
Hi,
I do not know if I do something special to reproduce the problem. My dissector
is filling plenty of expert info using approach like:
guint16 type, assign_length;
proto_item *le, *item;
assign_length = tvb_get_ntohs(tvb, offset);
le = proto_tree_add_text(info_tree, tvb, of
On Wed, Mar 28, 2007 at 06:45:01PM +0800, Jeff Morriss wrote:
> That's why I suggested turning on "-Wno-pointer-sign" (because I don't
> have a better idea and I don't particularly like the idea of just
> casting them all away).
Ok, I can go ahead and remove my casts and add the -Wno-pointer-si
Hmmm... OK, I have yet had to use the M3UA dissector, didn't know
that. Anyway, in SUA/SCCP too, it is possible for the CgPA and CdPA to
be only PC-SSN. So, if SCCP/SUA does set the transport address as GT,
it should also set it to point code if only point code is available.
Perhaps the others have
There still be the IP addresses in net_src/net_dst. It would be much
like M3UA does that replaces ip src and ip dst by the opc and dpc
(which I do not doubt it is ok).
What I wonder about is whether the GT is an address or should it be
just taken as a "port" on a certain address.
On 3/28/07, Abhi
Stephen Fisher wrote:
> Well, since (g)char defaults to unsigned on most platforms,
No, it doesn't. "char" defaults to *signed* on most platforms, because
1) the PDP-11's "movb" instruction sign-extended, so "char" was made
signed on the PDP-11
and
2) the VAX C implementation
In case of SUA, wouldn't this mean pinfo->src and pinfo->dst would no
longer have the IP end-points of the SCTP association? Is yes, is that
desirable?
On 3/28/07, Luis Ontanon <[EMAIL PROTECTED]> wrote:
> Would it be correct to add an AT_SS7_GT to the address types and have
> sccp/sua setting the
Bryan Miller wrote:
> What happens if I add a plug-in for a dissector that already is statically
> linked into Wireshark? Does the plug-in take precedence or will there be a
> conflict?
There is no guarantee of any particular outcome. It depends on the
mechanism the dissectors use to register
Hello all,
I am developing an RPC based dissector and I am getting odd results when I run
it.
It correctly identifies the protocol (based on RPC program and procedure
numbers) for a couple of frames and then begins to display another RPC
protocol (different program number, same procedure number).
On Wed, Mar 28, 2007 at 03:55:38PM +0200, Sebastien Tandel wrote:
> Permissions have not been correctly set on packet-amqp.c
I assume you are referring to the svn:executable property. I have
removed this as SVN revision 21247. Thanks for pointing it out!
Steve
___
Mea culpa if this is a FAQ but I couldn't find reference to this anywhere.
What happens if I add a plug-in for a dissector that already is statically
linked into Wireshark? Does the plug-in take precedence or will there be a
conflict?
Cheers,
Bryan
__
Hi,
Without checking - I think the PDU lacked something in the signature or
something such as that but I'll try to find the time to have another look.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Kukosa, Tomas
Skickat: den 28 mars 2007
Hi,
if those choice statemens are only dummy
the better way is to define those types as PDU in .cnf file.
Then -F option could be removed.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent:
Sorry for the repost. The wiki doesn't mention putting PATCH in the
subject line and I am new here.
I have attached a patch for the protocol hierarchy statistics (-z io,
phs). It's a simple update from a 32 bit unsigned integer to a 64 bit
version. I am a little uncertain about the portability of
Hi Ulf,
>> Maybe we should instead split Makefile.common up into three parts :
>>
>> First part : normal dissectors
>>
>> Second part : ANS2WRS generated dissectors which take extra compile
>> time flags and definitions to suppress artefacts from the compiler.
>>
>> Third part : PIDL generated di
Would it be correct to add an AT_SS7_GT to the address types and have
sccp/sua setting the GTs as pinfo->src & pinfo->dst ???
Isn't the global title an actual (transport) address?
Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
On 3/28/07, Sebastien Tandel <[EMAIL PROTECTED]> wrote:
>
> >>> I dont think it is really realistic to have all autogenerated files
> >>> always compile without any warnings.
> >>> Maybe we should instead split Makefile.common up into three parts :
> >>>
> >>> First part : normal dissectors
> >>>
>
I have attached a patch for the protocol hierarchy statistics (-z
io,phs). Its a simple update from a 32 bit unsigned integer to a 64 bit
version. I am a little uncertain about the portability of the new
include but I tried to follow how it was done else where in the code.
Thanks,
D. Todd Vollmer
>>> I dont think it is really realistic to have all autogenerated files
>>> always compile without any warnings.
>>> Maybe we should instead split Makefile.common up into three parts :
>>>
>>> First part : normal dissectors
>>>
>>> Second part : ANS2WRS generated dissectors which take extra compi
Permissions have not been correctly set on packet-amqp.c
Regards,
Sebastien Tandel
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Manjunath P wrote:
> I have special "Downloading Rights " in my office and my m/c is not behind
> any firewall. I downloaded a tortoise SVN( recent SVN 1.4.3 win32 ).
> When I try to do "svn --version"on my cmd line , I get an error "The
> application has failed to start because c
I have special "Downloading Rights " in my office and my m/c is not behind
any firewall. I downloaded a tortoise SVN( recent SVN 1.4.3 win32 ).
When I try to do "svn --version"on my cmd line , I get an error "The
application has failed to start because cygdb-4.2.dll was not found.
Hi,
I had a quick look at the warnings for NBAP some of the "unused
function" warnings are due
To the "dirty" way hf fields and stuff are auto generated by creating
dummy choice statements for
Opcodes and elements to hand craft them or remove the dummy statements
after copying the auto generated
Ronnie,
> Why do you change all function argumentns to use _U_ ?
>
> _U_ is only used to mark a parameter as unused so that the compiler
> will not emit any warnings "parameter foo is never used".
>
> You only set this _U_ for arguments that are indeed never used inside
> the function to suppres
On Wed, Mar 28, 2007 at 08:21:24AM +, ronnie sahlberg wrote:
> I dont think it is really realistic to have all autogenerated files
> always compile without any warnings.
Which warnings do you have in mind specifically? Why do you think they
can't be avoided?
> Maybe we should instead split Ma
Ulf Lamping wrote:
> Graham Bloice wrote:
>> On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow
>> compilation to proceed due to a warning emitted when compiling
>> packet-parlay.c.
>>
>> The warning was that the number of lines exceed an internal limit
>> (65536) and no more line numb
On 3/28/07, ronnie sahlberg <[EMAIL PROTECTED]> wrote:
> On 3/28/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> > ronnie sahlberg wrote:
> > > I dont think it is really realistic to have all autogenerated files
> > > always compile without any warnings.
> > > Maybe we should instead split Makefile.co
Stephen Fisher wrote:
> On Wed, Mar 28, 2007 at 03:04:27PM +0800, Jeff Morriss wrote:
>> Stephen Fisher wrote:
>>> Almost all of the warnings I've fixed so far are "sign mismatches"
>>> between guint8* and (g)char* :(. 552 of the 795 remaining warnings
>>> outside of the .cnf files are this pr
On 3/28/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> ronnie sahlberg wrote:
> > I dont think it is really realistic to have all autogenerated files
> > always compile without any warnings.
> > Maybe we should instead split Makefile.common up into three parts :
> >
> > First part : normal dissectors
Graham Bloice wrote:
> On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow
> compilation to proceed due to a warning emitted when compiling
> packet-parlay.c.
>
> The warning was that the number of lines exceed an internal limit
> (65536) and no more line number info would be issued.
>
ronnie sahlberg wrote:
> I dont think it is really realistic to have all autogenerated files
> always compile without any warnings.
> Maybe we should instead split Makefile.common up into three parts :
>
> First part : normal dissectors
>
> Second part : ANS2WRS generated dissectors which take ext
Manjunath P wrote:
> Hi ,
> I am having a Windows XP m/c. I hv installed MSVC ExpEd and
> PSDK also. I am getting the foll. error when I try to download
> source through Tortoise SVN.
>
>
> Error: PROPFIND request failed on '/wireshark/trunk'
> Error: PROPFIND of '/wireshark/trunk
Hi ,
I am having a Windows XP m/c. I hv installed MSVC ExpEd and PSDK also.
I am getting the foll. error when I try to download source through Tortoise
SVN.
Error: PROPFIND request failed on '/wireshark/trunk'
Error: PROPFIND of '/wireshark/trunk': could not connect to server
(htt
On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow
compilation to proceed due to a warning emitted when compiling
packet-parlay.c.
The warning was that the number of lines exceed an internal limit
(65536) and no more line number info would be issued.
The only fixes that I can see for
I dont think it is really realistic to have all autogenerated files
always compile without any warnings.
Maybe we should instead split Makefile.common up into three parts :
First part : normal dissectors
Second part : ANS2WRS generated dissectors which take extra compile
time flags and definitio
51 matches
Mail list logo
