On Mon, Nov 06, 2006 at 08:15:01PM +, ronnie sahlberg wrote:
checked in
Here is the list of warnings it creates on my system:
In file included from packet-acn.c:56:
packet-acn.h:38:1: warning: C++ style comments are not allowed in ISO
C90
packet-acn.h:38:1: warning: (this will be reported
Wireshark is linked against libnetsnmp
libnetsnmp.so.10 = /usr/lib/libnetsnmp.so.10
which is present on my desktop but I see it complaining for
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
On Mon, Nov 06, 2006 at 11:30:12PM +0100, Ulf Lamping wrote:
These places look bogus and should be reverted, unless there are good
reasons that I don't see ...
You know the code much better than I do, so feel free to revert that
stuff! Basically the only thing I tried to make sure was that the
On Tue, Nov 07, 2006 at 09:20:48AM +0100, Radek Vokál wrote:
which is present on my desktop but I see it complaining for
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
Cannot find module
checked in
thanks (and sorry for that since its my code and i should have known better)
On 11/7/06, Albert Chin wrote:
The Solaris C compiler, among others, do not allow anonymous unions.
Patch attached.
--
albert chin ([EMAIL PROTECTED])
On Monday 06 November 2006 11:16 pm, Ulf Lamping wrote:
[EMAIL PROTECTED] wrote:
Please do not confuse the bug that I may have introduced, and the
wireshark/glib bugs.
THERE ARE NO WIRESHARK BUGS THAT YOU'VE FIXED (beside some very
unimportant memory leaks)!!!
and some uninitialized
Jaap Keuter wrote:
Hi,
Checked in.
Thanx,
Jaap
On Mon, 6 Nov 2006, Albert Chin wrote:
Patch attached to convert usage of ntohl() - g_ntohl(). On HP-UX,
ntohl() isn't available unless you -D_XOPEN_SOURCE_EXTENDED but there
are other uses of g_ntohl().
--
albert chin ([EMAIL
Joerg Mayer wrote:
Hmm, the fix is correct, but if we need to links dumpcap with gnutls
just to handle the version stuff, then something more fundamental is
broken with our version stuff. There should be a better solution to
this problem.
FULL ACK!
Regards, ULFL
Joerg Mayer wrote:
Here is the list of warnings it creates on my system:
I've checked in some changes that should fix most, if not all, of them.
In particular:
packet-acn.h:168: warning: type of bit-field 'dummy' is a GCC extension
packet-acn.h:169: warning: type of bit-field 'D' is a GCC
Joerg Mayer wrote:
Hmm, the fix is correct, but if we need to links dumpcap with gnutls
just to handle the version stuff, then something more fundamental is
broken with our version stuff. There should be a better solution to
this problem.
get_epan_compiled_version_info() should probably be
Joerg Mayer wrote:
gtkvumeter.c:946: warning: comparison of unsigned expression 0 is
always false
gtkvumeter.c:1144: warning: comparison of unsigned expression 0 is
always false
I'll have a look probably tomorrow ...
Regards, ULFL
___
As someone that has actually studied the feasibility of making
wireshark multithreaded and what would be required
... Written with tons of globals variables, non thread safe, ...
There are some global variables in the bulk of the codebase, i.e. the
dissectors. There is actually not that many of
Hi list,
He must have missed the memo that we're all gone working on Wireshark. ;)
Thanx,
Jaap
On Tue, 7 Nov 2006, Guy Harris wrote:
Joerg Mayer wrote:
Hmm, the fix is correct, but if we need to links dumpcap with gnutls
just to handle the version stuff, then something more fundamental
Jaap Keuter wrote:
He must have missed the memo that we're all gone working on Wireshark. ;)
So when do we rename the epan directory wpan? :-)
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
Ulf Lamping wrote:
What are the reasons of the following changes in capture_loop.c:
I've backed those out, for the reasons noted; the right way to fix
null-pointer dereferences in routines not defined to accept null
pointers is not to add checks to those routines, it's to avoid passing
those
Radek Vokál wrote:
Wireshark is linked against libnetsnmp
libnetsnmp.so.10 = /usr/lib/libnetsnmp.so.10
which is present on my desktop but I see it complaining for
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module
Thanks for cleaning these up.. I should have caught the bitfields... I'm
not used to all the cross-platform problems (but I'm learning... :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
Sent: Tuesday, November 07, 2006 3:09 AM
To: Developer
Ulf Lamping wrote:
That was a bug in copying the Win32 debug environment together. The mib
files must go to snmp\mibs, not simply mibs
Given Radek's e-mail address (and job title), I suspect he's not running
Windows, so that's probably not the cause of the problem he's seeing. :-)
On Tue, 7 Nov 2006, Guy Harris wrote:
Jaap Keuter wrote:
He must have missed the memo that we're all gone working on Wireshark. ;)
So when do we rename the epan directory wpan? :-)
When hell freezes over!
Oh wait, that already happend when Debian Sarge was released :-
Here is a patch for the ACN dissector. It fixes a bug in
acn_add_expiry() and cleans up some cosmetic things.
Bill Florac
Senior Technical Product Specialist
Electronic Theatre Controls, Inc
3031 Pleasant View Rd
Middleton, WI 53562
608-831-4116 (corp. phone)
acn.patch
Description: acn.patch
Yes.
Currently get descriptor is the only real command from core usb that
is implemented.
Other commands, when implemented, will need to pass other kinds of
data between request and responses.
On 11/7/06, Guy Harris [EMAIL PROTECTED] wrote:
ronnie sahlberg wrote:
checked in
So why is there
Thomas Anders wrote:
Radek Vokál wrote:
Wireshark is linked against libnetsnmp
libnetsnmp.so.10 = /usr/lib/libnetsnmp.so.10
which is present on my desktop but I see it complaining for
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot
I think the most interesting useage would be to do dissection of
packets for very large traces in paralell across all the cores
greatly speeding up the dissection/filtering of packets.
If doing this, it would as a sideeffect also make your useage example
: multiple captures dissected/operated on
Looks good.
The version of Bash I HAD was version 3.1.17(9) this was downloaded from
Cygwin as 3.1-9 (Cygwin has another version 3.2.3-5 which I did not
try).
Followinf your emails I downloaded an earlier version 3.1.17(6) from
Cygwin as 3.1-6 and this has worked. Thanks for the help it looks
what about #defining them so they trigger an error?
On 11/7/06, Ulf Lamping [EMAIL PROTECTED] wrote:
Jaap Keuter wrote:
Hi,
Checked in.
Thanx,
Jaap
On Mon, 6 Nov 2006, Albert Chin wrote:
Patch attached to convert usage of ntohl() - g_ntohl(). On HP-UX,
ntohl() isn't
You can create an emty dir on c:\ and rename it in config.nmake:32
WIRESHARK_LIBS=C:\wireshark-win32-libs
On 11/7/06, Robert Trybis [EMAIL PROTECTED] wrote:
On Windows XP when trying to run the Automated library dowload
the command
nmake -f Makefile.nmake setup
fails if the directory
Hi,
Yeah, that is what he said.
Thing is that it shouldn't happen. What's cygpaths problem?
Thanx,
Jaap
On Tue, 7 Nov 2006, LEGO wrote:
You can create an emty dir on c:\ and rename it in config.nmake:32
WIRESHARK_LIBS=C:\wireshark-win32-libs
On 11/7/06, Robert Trybis [EMAIL PROTECTED]
Robert Trybis wrote:
Under XP I have got as far as trying to build Wireshark 00.99.4.
Unfortunately the build fails because of “env: python: No such file or
directory” when it gets to building dissectors.
I was a bit surprised by this as I got a clean copy of the release and I
am certain
env python produces;
Python 2.4.3 (#1, May 18 2006, 07:40:45)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or License for more information.
Regards
RT
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Graham Bloice
Sent: 07
Robert Trybis wrote:
env python produces;
Python 2.4.3 (#1, May 18 2006, 07:40:45)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or License for more information.
Hmmm, same as mine. Something has gone wrong in the nmake environment
when attempting to invoke python
Hi ,
I am very new to the ethereal source code. I want to add a dissector
that understands my protocol – my_proto.
Problem statement:
I have a binary file my_proto_dump.log. This file has packets received
by my application.
I want ethereal to read from a binary file packets in my_proto
Running python by hand produces packet-ncp222.c (thanks Graham),
but the build then fails later when python runs again.
I have given the latter part of the build output below.
From earlier problems I know some of the source files I have downloaded
don't have Unix style end-of-line, I am using an
Missing bit;
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
'dfilter.lib' is up-to-date
cd ..
cd wslua
NMAKE / -f Makefile.nmake
Microsoft (R) Program Maintenance Utility
Hi,
This stuff is wierd. First cygpath that acts up, now it's env that can't
find python from /usr/bin/ It seems that path isn't working.
Do you have a nondefault cygwin installation? Maybe it's the filesystem
type, what type is it?
Thanx,
Jaap
___
Jaap Keuter wrote:
Hi,
This stuff is wierd. First cygpath that acts up, now it's env that can't
find python from /usr/bin/ It seems that path isn't working.
Do you have a nondefault cygwin installation? Maybe it's the filesystem
type, what type is it?
Thanx,
Jaap
I have had this error, or at least something similar.
It was when I was developing a disector.
For whatever reason, I had to have a fresh clean plugin.c file in the
folder and delete the .obj file everytime.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
I decide trying to continue by hand would be difficult so I commented
python out in config.nmake
This too failed though, results below;
radius_dict.c
radius_dict.l(77) : warning C4005: 'OUT' : macro redefinition
C:\Program Files\Microsoft Visual
Studio\VC98\include\rpcdce.h(23) : see
I let cygwin do its default thing, plus adding in the additional
downloads required for the Wireshark documentation. Then I went back to
an earlier version of Bash. I only installed cygwin to get Wireshark
working so it should be standard.
The file system is NTFS.
Regards
RT
-Original
This isn't a new issue! I haven't been able to use the CYGWIN version
of Python to build WS, since I start with WS around March this year.
I have install the Win32 native version of Python (v2.3), no problem.
-Tim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
I let cygwin do its default thing, plus adding in the additional
downloads required for the Wireshark documentation. Then I went back to
an earlier version of Bash. I only installed cygwin to get Wireshark
working so it should be standard.
The file system is NTFS.
Hi!
I have these
Noticed this yesterday. Figured I'd mention it to see if anyone has an easy
fix.
Select File - Save As...
Enter a file name that exists
Press OK
wireshark give a warning that the file exists.
Select Cancel
Select File - Save As...
No window opens
Wireshark Version == latest
Neha Chahal wrote:
I am very new to the ethereal source code. I want to add a dissector
that understands my protocol – my_proto.
Problem statement:
I have a binary file my_proto_dump.log. This file has packets received
by my application.
What format is that file in?
I want
On 11/7/06, Guy Harris [EMAIL PROTECTED] wrote:
Neha Chahal wrote:
I am very new to the ethereal source code. I want to add a dissector
that understands my protocol – my_proto.
Problem statement:
I have a binary file my_proto_dump.log. This file has packets received
by my
Neha Chahal wrote:
The format of the file is binary
Binary isn't a format for a packet capture; there are several capture
file formats, all of which are binary, but they're not all the same.
What *specific* binary format is it?
Is this some standard format (libpcap format as used by
On 11/7/06, Guy Harris [EMAIL PROTECTED] wrote:
Neha Chahal wrote:
The format of the file is binary
Binary isn't a format for a packet capture; there are several capture
file formats, all of which are binary, but they're not all the same.
What *specific* binary format is it?
Is this some
FYI,
I don't seem to have major problems with the CYGWIN version of Python.
I can build the latest using...
cygwinpython 2.4.3
cygwinbash 3.1.17(9)
microsoft nmake 6.0.0.8167.0
I did have to convert the following files to UNIX format. I expect it
has something to do with the
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Bill Florac
Skickat: den 7 november 2006 23:01
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] Release 00.99.4 missing file?
:
Since this is the first time I tried to build since 0.99.3
Joerg Mayer wrote:
On Tue, Nov 07, 2006 at 09:26:50AM +, ronnie sahlberg wrote:
As someone that has actually studied the feasibility of making
wireshark multithreaded and what would be required
... Written with tons of globals variables, non thread safe, ...
[Good reasons about the
Is there any reason threads shouldn't be enabled by default? It would
make implementing the version checking and windows update features in
the roadmap a bit easier and cleaner.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
Attached is a patch that enables Wireshark to highlight in the tree and
hex display the results of a search. This works for both hex and string
searches in the Find Packet window. This is a feature I've wanted
forever and Ulf opened it as a feature request in bug 776 :).
Steve
Index:
On Tue, Nov 07, 2006 at 05:25:48PM -0800, Stephen Fisher wrote:
Attached is a patch that enables Wireshark to highlight in the tree
and hex display the results of a search. This works for both hex and
string searches in the Find Packet window. This is a feature I've
wanted forever and
Hello,
I use a little bit differen solution for a similar problem.
Sometimes I need to dissect proprietray protocols from tracesfiles not
supported by Wireshark.
I use following way:
1) convert trace file to pcap format with linktype DLT_USERx (x=0-15)
simple conversion tool can be written in
52 matches
Mail list logo
