Hi List!
I've added a proposal for an automatic update functionality to the Wiki.
Please comment!
Regards, ULFL
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
I try this out as well. Thank you. On 11/7/06, Kukosa, Tomas <[EMAIL PROTECTED]> wrote:
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 fo
Hi
I have a question about wth->frame_buffer. Does the plugin library
(i.e the code that I am writing) have to initialize this buffer or is
it done by wireshark internally. in what case will this buffer be
empty. Currently my program is crashing becase the frame buffer is not
initialized properly
On Wed, Nov 08, 2006 at 04:59:56PM -0800, Stephen Fisher wrote:
> On Wed, Nov 08, 2006 at 04:48:58PM -0800, Stephen Fisher wrote:
>
> > One way that you can fix the warning is by manually assigning numbers
> > to the enumerated values in gtkvumeter.h:
>
> A cleaner fix would be to just reverse
On Wed, Nov 08, 2006 at 04:48:58PM -0800, Stephen Fisher wrote:
> One way that you can fix the warning is by manually assigning numbers
> to the enumerated values in gtkvumeter.h:
A cleaner fix would be to just reverse the parameter order:
CLAMP (scaling, GTK_VUMETER_SCALING_LINEAR, GTK_VUMETER
On Wed, Nov 08, 2006 at 11:07:15PM +0100, Ulf Lamping wrote:
> Joerg Mayer wrote:
> > gtkvumeter.c:946: warning: comparison of unsigned expression < 0 is
> > always false
> >
> CLAMP is called with three variables of type GtkVUMeterScaling
> > gtkvumeter.c:1144: warning: comparison of unsigned
LEGO wrote:
> what about #defining them so they trigger an error?
>
Although this would be a nice solution, I don't see a way to do this -
it will conflict with the existing function declarations IMHO.
I would be more than glad if we could do it that simple ...
Regards, ULFL
_
Gerald Combs wrote:
> That's correct. Checking for updates would be pretty easy if we could
> connect to the server, issue a request, and feed the response to
> read_prefs_file(). It'd be even easier if we could do so from a thread
> instead of a separate process.
>
And probably less memory
Hi I am trying to test my code in the wiretap directory.When I run tethereal on my binary file it crashes randomly.The core points here--
Loaded symbols for /lib/libresolv.so.2#0 0x0038fbfd in wtap_buf_
That's correct. Checking for updates would be pretty easy if we could
connect to the server, issue a request, and feed the response to
read_prefs_file(). It'd be even easier if we could do so from a thread
instead of a separate process.
In regard to Ulf's comment about threads not working we
Hmmm, I don't understand both.
Joerg Mayer wrote:
> gtkvumeter.c:946: warning: comparison of unsigned expression < 0 is
> always false
>
CLAMP is called with three variables of type GtkVUMeterScaling
> gtkvumeter.c:1144: warning: comparison of unsigned expression < 0 is
> always false
>
CLAM
The "cd.." will make epan would working directory. So it copies the
mkstemp.c and strptime.c files from the root directory to the epan
directory. (Odd but it does not copy the header file) I confimed this
by deleting the files in epan, and the script copied them again.
So, by deduction, it seems
Bill,
Here is what I got in the build output;
cd ..
..\tools\lemon\lemon t=..\tools\lemon\lempar.c dtd_grammar.lemon
flex -odtd_parse.c dtd_parse.l
flex -odtd_preparse.c dtd_preparse.l
flex radius_dict.l
xcopy ..\mkstemp.c . /d
xcopy ..\strpt
Hi,
I copied what seems to have been done in the binary distribution.
Anyway just to check things I moved everything to
C:\wireshark_source_00_99_4(no spaces in path)
and tried another build, but I got exactly the same result with
mkstemp.c strptime.c not being found.
Regards
RT
> -Ori
However I believe that what Gerald is talking about is using threads
for asyncronously executing upgrades.
I do not think that the very linking to the thread libraries causes
performance degradation.
If on a single processor you must continiuously switch contexts
between the main thread and the r
yes.
we used to have 2 threads in the old ethereal for a short period.
one thread for the main application and a second thread that was
dedicated to only update/redraw teh statistics taps once every few
seconds.
this did cause a quite significant degradation in performance/speed of
ethereal whic
Hi,
It's only now that I see it
> Robert Trybis wrote:
> > I am in C:\Program Files\wireshark which is where I installed the
> > sources using SVN and I am using the commands you mentioned;
You've actually put the sources where the installation is going to be?
For one that is considered poor sty
I think you need to look further back into the nmake output. You should
see this:
--
cd ..
..\tools\lemon\lemon t=..\tools\lemon\lempar.c dtd_grammar.lemon
flex -odtd_parse.c dtd_parse.l
flex -odtd_p
I have got the path correct for XCOPY, I get "invalid number of
parameters" if I run it from the command line.
Could I move mkstemp.c and strptime.c , by hand - where should I put
them?
I feel I am very close to getting this working.
Regards
RT
> -Original Message-
> From: [EMAIL PROTEC
is xcopy in the PATH?
On the command line type xcopy.
The PATH to add on WinXP might be C:\WINNT\system32\ instead of
C:\Windows\system32\
Lars
Robert Trybis wrote:
> I am in C:\Program Files\wireshark which is where I installed the
> sources using SVN and I am using the commands you mentioned;
On Wed, Nov 08, 2006 at 02:52:16PM +0100, Ulf Lamping wrote:
> Someone may have a look?
Looks like some function had a forward declaration that was incompatible
with the later generated function (the forward declaration wasn't
declared static, the autogenerated function was).
ciao
Joerg
--
I am in C:\Program Files\wireshark which is where I installed the
sources using SVN and I am using the commands you mentioned;
nmake -f Makefile.nmake distclean
nmake -f Makefile.nmake all
The files mkstemp.c and strptime.c both exist in C:\Program
Files\Wireshark
Regards
RT
> --
This patch adds support for correct computation of
variable length DCCP checksums as specified in
RFC 4340, section 9.
Previously wireshark was unable to compute these
checksums, only full-coverage checksums could be
validated.
This patch
* makes checksum computation dependent
Hi List!
Someone may have a look?
Regards, ULFL
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Robert Trybis wrote:
> I have tried again after deleting the wireshark directory and getting a
> clean copy of 00.99.4. Under XP the build ends prematurely with the
> lines given below.
>
>
Both files should be copied by epan\Makefile.nmake:
mkstemp.c: ..\mkstemp.c
xcopy ..\mkstemp.c . /d
Steve,
> > This patch (r19733) breaks the dissection of X.400 and X.500
> > protocols, and probably other things besides. I think that the
> > heuristic is incorrect.
>
> Oops, sorry about that. Do you know where I can get a copy of the
> standard so I can fix the heuristic in a better way?
No p
I have tried again after deleting the wireshark directory and getting a
clean copy of 00.99.4. Under XP the build ends prematurely with the
lines given below.
Any ideas why these files appear to be missing and how to work round it?
I did not go through the process of doing the automated library do
On Wed, Nov 08, 2006 at 09:52:26AM +0100, Jaap Keuter wrote:
> I'm all for that. I personally don't like extending Wireshark into the
> realm of trace file analyser.
Actually adding new file formats is quite ok, as long as there is some
"real use" for it for more than just a handful of users. Also
Hi everyone, I have a question, I´ve being told that wireshark has an option that shows the Quality of Sevice of each call, but not in the RTP Stream´s Window. I mean, somewhere in a protocol´s data or protocol´s header.
My problem is that I´m doing my measures in a specific point of the trace
Gerald Combs wrote:
> 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.
>
Sorry, but I don't really understand the relationship - can you explain
what you mean?
Robert Trybis wrote:
>
>
>>> Can anybody tell me how to undo everything that has been done by
>>> Nmake -f Makefile.nmake all
>>> ?
>>>
>>>
>> Go back to the beginning, like so
>> nmake -f Makefile.nmake distclean
>> then build again
>> nmake -f Makefile.nmake all
>>
>
> I did the
Missing bits;
tvbparse.c
tvbuff.c
unicode-utils.c
value_string.c
xdlc.c
xmlstub.c
inet_aton.c
inet_pton.c
inet_ntop.c
mkstemp.c
fatal error C1083: Cannot open source file: 'mkstemp.c': No such file or
directory
strptime.c
fatal error C1083: Cannot open source file: 'strptime.c': No such file
or di
> > Can anybody tell me how to undo everything that has been done by
> > Nmake -f Makefile.nmake all
> > ?
> >
>
> Go back to the beginning, like so
> nmake -f Makefile.nmake distclean
> then build again
> nmake -f Makefile.nmake all
I did the clean as above then tried to build again it failed
On Wed, 8 Nov 2006, Robert Trybis wrote:
> Hello,
>
> Peter hit the nail on the head, it's the Windows PATH variable.
> The cygwin installation does not set an environment variable to allow
> python to be found. Also all the stuff that accumulates in the PATH
> environment variable can confuse thi
Hello,
Peter hit the nail on the head, it's the Windows PATH variable.
The cygwin installation does not set an environment variable to allow
python to be found. Also all the stuff that accumulates in the PATH
environment variable can confuse things, though I don't think the length
is important.
A
Ulf Lamping wrote:
>> 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 NTF
Hi,
I'm all for that. I personally don't like extending Wireshark into the
realm of trace file analyser.
Thanx,
Jaap
On Wed, 8 Nov 2006, Kukosa, Tomas wrote:
> Hello,
>
> I use a little bit differen solution for a similar problem.
> Sometimes I need to dissect proprietray protocols from tracesf
37 matches
Mail list logo
