Abhik Sarkar wrote:
Hello All,
My SVN copy of Wireshark has been, for a while, crashing when I go to
Edit Preferences. I finally decided to get to the bottom of this and
have some very strange observations... but to start at the beginning:
OS: Windows XP Professional
SVN revision: 26908
Log:
From Don Newton:
Set default port of Unistim back to 5000; The Unistim dissector is made a
heuristic dissector.
Comment from the original code:
/* Don't set this to 5000 until this dissector is made a heuristic
one! static guint global_unistim_port = 5000;
It
John Walsh has asked how to configure Wireshark to treat traffic on port
1445 the same as traffic on port 445 (For example: CIFS aka SMB over TCP).
(see http://www.wireshark.org/lists/wireshark-users/200811/msg00167.html)
I've replied that this is currently not possible.
Looking at the code:
Bill Meier wrote:
John Walsh has asked how to configure Wireshark to treat traffic on port
1445 the same as traffic on port 445 (For example: CIFS aka SMB over TCP).
(see http://www.wireshark.org/lists/wireshark-users/200811/msg00167.html)
I've replied that this is currently not possible
I was wrong. Using NBSS as the decode as does work (as Ronnie
noted in his reply to John Walsh).
Bill
It does seem to work, but a quick run-thru with the debugger suggests
that some further analysis is required. Port 445 is certainly
hard-wired in the code ... I'll have to look
Pat Saunders wrote:
I have tried this but no luck !!!
I do file open and navigate to c:\wireshark\wireshark-gtk2\wireshark.exe
It opens wireshark.exe as a folder with subfolders :
Dialog/Icon/RT_MANIFEST/Version
But all the Start Debugging options are greyed out so I cannot debug
Please Help
Pat Saunders wrote:
No - I use file : open : wireshark.exe
I can only debug by attaching to the process - but it was crashing at
startup so the only way I could debug was to let it crash then click the
debug button and use the debugger .
Visual studio 9 greys out the Debugging options.
Pat Saunders wrote:
Hi,
I am using Microsoft Visual 2008 : winXP
I have added a small plug-in but when I start Wireshark.exe
it crashes with a fault address in libwireshark.dll.
I am 75% sure this is due to my plug-in (When I take my
plug-in
Pat Saunders wrote:
Thanks - I have familiarised myself wirh step into etc
How I do debug a process at startup - I know I have to attach to the
wireshark process at startup - but if it crashes at startup : how do I
debug at startup ??
Actually, you should start the process from VS (as
Sean wrote:
2) Microsoft Visual Studio: Which version is better? 2005 or 2008 or 2003?
I'm working under Windows XP Professional SP2, is it OK for wireshark
dissector development?
Use VS2008; that's what is currently used for the Wireshark Windows build.
AFAIK VS2008 should work AOK on
[EMAIL PROTECTED] wrote:
- Fall back to local interfaces when error listing remote interfaces
Looks pretty good
One small note: A quick look suggests that a cancel (or OK with no
fields filled in) of the remote interfaces window should also fall
back to local in the Local/remote
Michael A. McCartney wrote:
I recently switched to MSVC2008EE because latest
Wireshark source builds but fails to run with
application error with MSCV6. MSVC200EE
builds and runs fine for me on WinXP.
For the record:
When building with VC6, the application error is a result of the fact
Joshua (Shiwei) Zhao wrote:
Hi,
I just lost my development setup so I has to rebuild it following the
develop guide for windows OS.
I remember there was 4 steps to prepare cmd.exe, but now there is only
3 steps. I remember that I had to call another file before calling
cvars32.bat. Anyone
Joshua (Shiwei) Zhao wrote:
Hi,
I just started to try making some changes to the code. I'm using MSVC
2005 EE as IDE. But since we're compiling/building it using the gcc
tool, can I debug it in MSVC or should I use gdb? How should I start?
I read the online manual for developers but the
(Updated to remove junk confusing line at end from previous message).
Bill Meier wrote:
Joshua (Shiwei) Zhao wrote:
Hi,
I just started to try making some changes to the code. I'm using MSVC
2005 EE as IDE. But since we're compiling/building it using the gcc
tool, can I debug it in MSVC
[EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=26535
User: wmeier
Date: 2008/10/23 05:42 PM
Log:
Windows build: #include winsock2.h only when needed.
I'll commit a patch later today so that a build using VC6 will
not fail
Bill
Joshua (Shiwei) Zhao wrote:
Thanks a lot! The tips link looks very helpful and I'll read through.
I use VS2005 because it was recommended in the developer doc as the
only available FREE complete version.
Unfortunately, the doc should have been updated to indicate that VS2008
is now the
[EMAIL PROTECTED] wrote:
/*prefs_register_enum_preference(ismacryp_module, ismacryp.encoding,
ismacryp version,
ismacryp version,
version_type,
[EMAIL PROTECTED] wrote:
Hi,
The code is here:
#define PROTO_TAG_ISMACRYP_11 ISMACRYP 1.1
#define PROTO_TAG_ISMACRYP_20 ISMACRYP 2.0
.
/* The ISMACryp protocol version set in preferences menu */
static gint version_type = 11; /* ISMACryp 1.1 */
...
static enum_val_t
There are about 300+ non-generated epan/dissector source files which
include stdio.h and/or stdlib.h
I've successfully done both a Linux and a Windows build with these
includes removed from epan/dissector/...
So, I plan to commit these changes tomorrow (Fri) unless someone
indicates a reason
Just for the record: My original reply to John follows (which I
mistakenly sent only to John).
John Sullivan wrote:
Random *local* include files I would whole heartedly agree, but not
system ones unless you have tested on every single current and
historical system variant.
Certainly a
[EMAIL PROTECTED] wrote:
Hello everyone!
I have a student research project where I got the task to write a plugin for
wireshark. It should be a dissector for the AYIYA protocol. The wireshark
docs recommend to ask the developer mailing list before starting a new
development task.
The
Colin O'Flynn wrote:
The problem is I don't see wpan as an option in the prefrences dialog! Any
hints to what I am doing wrong? It seems fairly simple, however I'm not very
familiar with the Wireshark sources.
The code compiles and works works fine once an #include epan/prefs.h
is added
Maynard, Chris wrote:
It looks suspicious to me but I know nothing about NCP, so perhaps it's
best to file a bug report and then when someone with knowledge of NCP
has a chance to look at it, he can either fix it or close the bug as
invalid if the behavior is correct as is (although if it is
Jeff Morriss wrote:
Q1: Can anyone suggest the appropriate resolution of these conflicts ?
Does that (the registration loss + memory leak) still happen if the
dissectors are new style? I would think that converting them to new
style dissectors should be the answer but I didn't look into
Anders Broman wrote:
(On a somewhat separate note: I see that multiple registrations
happen for udp and tcp port 0.
I'm still looking at these to understand and to see if OK.)
I think this is used when there is no registered port for the protocol
And no reasonable default port
After adding a little validation code to dissector_add I've found that
there are currently at least two cases where multiple dissectors are
registered to the same non-zero tcp or udp port:
=
udp.port: dsctr: cpfi; key 5000 already registered to: airopeek
udp.port: ddctr: tapa; key
Ulf Lamping wrote:
Sake Blok schrieb:
snip
I personally vote against inclusing of this code into the source
tree. How do others feel about the inclussion of this code?
FULL ACK to Sake!
+1
___
Wireshark-dev mailing list
The Windows buildbot build docs step is failing.
I suspect the failure is related to SVN #25845..
-
perl make-wsluarm.pl ../epan/wslua/wslua_dumper.c
../epan/wslua/wslua_field.c ../epan/wslua/wslua_gui.c
Nathan Jennings wrote:
Just curious if anyone was looking at this or had put any time into it.
See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2719
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
At Wed, 23 Jul 2008 14:00:58 -0400 (EDT), you wrote
However, when I
drop my plugin.dll file into a standard installation of wireshark (not
built from source), the plugin does not load.
Can anyone further clarify what is going on?
Also: ISTR that since ... I am writing (in Windows with VS8)...
Jeff Morriss wrote:
Are you automatically finding these? How? I was wondering about
finding a way to do it...
Yep: A little bit of regex'ing in checkAPIs.pl seems to work OK for the
way most value_string arrays are defined in Wireshark code.
The current code finds and checks the cases
[EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revroot=Wireshark-win32-libsrevision=180
User: etxrab
Date: 2008/07/20 03:28 PM
Log:
Add the latest GTK libraries:
Using the updated libraries: Everything builds OK on Windows and
Wireshark emits no smoke
Bill Meier wrote:
2. Also: I may be quite off-base as to checkAPIs errors being the reason
why the install packages aren't appearing in
http://www.wireshark.org/download/automated/win32/.
I now see that each of the Windows buildbot 'create installer/package'
steps apparently succeeds
The Windows buildbot has been failing since about July 1 due to
checkAPIs -g abort errors for several wiretap files.
One consequence is that the Windows Development install package is not
being generated.
So: I've removed the -g abort from the wiretap makefile checkAPIs line
for now so as to
Guy Harris wrote:
Bill Meier wrote
A quick look suggests that the following 3 files are using g_assert
when
checking for file format errors. I would guess that this code should
be
changed
A true file format error should never result in an assertion failure
or other exit
Jeff Morriss wrote:
[EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25761
User: wmeier
Date: 2008/07/17 02:40 PM
Log:
checkAPIs: remove '-g abort'; g_assert OK for wsutils files ?
I put the g_assert() in privileges.c (rev 24648) after finding
John Smith wrote:
Im running Linux, Red Hat Enterprise Linux 4, and srt the additonal
CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W'.
-Wshadow will cause various warnings when building the current Wireshark
source. Make errors will therefore occur since Wireshark is compiled
with
I am new to wireshark development community. What is the next step in
creating a defect and scheduling a fix in a future wireshark version?
Thanks.
An enhancement request can be filed at bugzilla.wireshark.org ...
(Use the 'enhancement' choice for the 'severity' of the bug report).
[EMAIL PROTECTED] wrote:
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/45
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for
Sake Blok wrote:
On Sat, Jun 21, 2008 at 09:45:24AM +, [EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25499
User: sake
Date: 2008/06/21 02:45 AM
Log:
From Ken Smith (bug 2574): Allow editcap to parse files into even time
intervals
A few
Sake Blok wrote:
On Sat, Jun 21, 2008 at 08:52:37AM -0400, Bill Meier wrote:
Sake Blok wrote:
On Sat, Jun 21, 2008 at 09:45:24AM +, [EMAIL PROTECTED] wrote:
Directory: /trunk/
ChangesPath Action
+1 -0 Makefile.commonModified
+72 -3 editcap.c
[EMAIL PROTECTED] wrote:
User: stig
Date: 2008/06/21 06:36 AM
Log:
Removed the usage of topic_available() as we now have all topics.
Directory: /trunk/gtk/
ChangesPath Action
+1 -1 capture_dlg.c Modified
+3 -9
Tobias Wärre wrote:
Hi
I'm not fully immersed of the details of the build process, but I think (well
know, but I'm a
bit modest... ;) ) it has to do with dependencies.
The C:\wireshark-1.0.0\ folder and all subfolders except
for those created during a
build (to see the effect do a
Kumar, Hemant wrote:
I got around this problem by modifying the statement in Makefile in
Wireshark directory.Just modified the -*–reference=Makefile.nmake *to
*–r Makefile.nmake*.
Another problem which I am facing now is related to Bison.exe.I get the
following error now.
At Thu, 29 May 2008 11:04:02 -0400 (EDT), you wrote
I personally believe not passing retransmitted frames is a better
choice, besides that its implementation is narrower, I see it as
natural for a transport protocol not to pass retransmissions to the
upper layer. All in all the user has a link in
Abhijit Mirajkar wrote:
Hi,
I could successfully compile the version 1.0.0 tarball with Visual C++ 2005
Express Edition and Platform SDK Server 2003 R2. However I am getting
compilation error when I use Visual C++ 6.0 instead of VC 2005 EE.
snip
I am attaching the compilation output
Gerald Combs wrote:
Bill Meier wrote:
In the same way that we use fail on warning for C compiles, it seems
to me that this should be sufficient enforcement as long as a build with
checkAPIs enabled causes a 'fail' if checkAPIs reports a problem.
I've added an 'nmake -f makefile.nmake
John Smith wrote:
I see
this as a training/tutorial exercise, as I desire to build some other
open source software the same way. By the way, MingW/MSYS let's you
run ./configure ;make all ; make install on Windows, and most of
these projects come with Unix style Makefiles/automake and are
Gerald:
What are the TCP preferences actually being used by tshark during the
Ubuntu buildbot fuzz-testing ?
Specifically: what are the values for the following preferences ?
Validate the TCP checksum if possible:
Allow subdissector to reassemble TCP streams:
Thanks
Having checkAPIs run in various directories during every Windows
incremental build (even when there are no file changes)
is a drag :)
Could we maybe have checkAPIs default to not being run (via an
environment variable or whatever) and then set the buildbot builds
to run checkAPIs ?
In the
[EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25170
User: etxrab
Date: 2008/04/24 11:42 PM
Log:
Flex (v 2.5.35) uses this symbol to exclude unistd.h
Directory: /trunk/
ChangesPath Action
+5 -0 config.h.win32
[EMAIL PROTECTED] wrote:
Log:
Fixed some old problems found while starting to add R7 support.
+186 -33 packet-umts_fp.cModified
I expect that the next buildbot Windows compile of packet-umts_fp will
fail (since it does on my Windows system):
packet-umts_fp.c(861) : warning
Jaap Keuter wrote:
Hi,
I think you been bitten by this bug:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493
Unfortunately this is a problem related to the use of cygwin flex 2.5.35
which was very recently noticed.
Please see
Guy Harris wrote:
Ulf Lamping wrote:
So there are not that many places that could show problems here - the
problem we have seems to be a lack of tests if GTK 2.0/2.2 is still running.
One data point:
The GTK+ version distribution in Wireshark bug reports not specifying
Windows as the OS
[EMAIL PROTECTED] wrote:
Add a routine filemanager_open_directory(), which takes a pathname
(presumed to be UTF-8 in Windows and Mac OS X; this might need work for
other UN*Xes) and attempts to open a file manager window for it, using
ShellExecute on Windows, ...
On my Windows Vista
Guy Harris wrote:
Guy Harris wrote:
Using the explore verb rather than the open verb in
filemanager_open_directory() *might* work. I'll try that.
Didn't help. The good news is that it didn't launch Wireshark; the bad
news is that it didn't open an Explorer window on the directory,
Stephen Fisher wrote:
On Thu, Apr 10, 2008 at 01:33:03AM +0200, Ulf Lamping wrote:
Lot's of stuff already done for the GTK1 cleanup, but we could still
need a helping hand ...
OPEN:
gtk/STATUS.gtk2: very old content (remove items marked as Done - or
remove the whole file?)
Let's
Peter Johansson wrote:
Still, (as I said earlier) I feel that it is not a good idea to go with
the patch that has been applied to oids.c since this will make all
Windows based versions to leak allocated memory. This should not have to
be an issue for users of the officially released
Stig Bjørlykke wrote:
I have no win32 experience to fix this, so if nobody can make this work
correctly I will propose the attached patch. This will leak some memory
on win32, but it's better than not working...
I suggest implementing the patch now so that this fix can be part of
Sake Blok wrote:
On Tue, Mar 18, 2008 at 05:35:57PM -0700, Gerald Combs wrote:
Ah, I thought this was a workaround for bug 2325. But it seems that
this bug is GTK+ related and not Glib related. I think bug 2325
should be solved for the big one-oh release, which I think means
going back on
Guy Harris wrote:
If it's not already exported, perhaps the libsmi developers weren't
aware of the wonderful feature of the Windows development
environment wherein a library uses the version of the C runtime
library with which it's built rather than the version with which the
Bill Meier wrote:
Stig Bjørlykke wrote:
Log:
Ensure tshark/wireshark always get good err msgs from dumpcap:
It looks like I'm getting the pipe header in my error message. Is
this intended?
Nope: I'm working on a fix...
I've committed a fix (SVN #24507) which has been tested on both
Maynard, Chris [EMAIL PROTECTED] writes:
The attached patch adds the gettext-runtime-0.17-1
and nasm-2.00 directories to the list of directories
in the clean_setup: target.
Commited in SVN 24497 (with one additional change to fix an earlier typo).
Thanks !
I'd like to release 0.99.8 tomorrow or Wednesday.
I've updated the INSTALL file somewhat to match current Wireshark.
However, I think there's a bit more updating needed as to the use of
setuid root privileges etc.
I removed some comments about don't use setuid; It may be that I
should have
Peter Johansson [EMAIL PROTECTED] writes:
I get the following when attempting to compile init_wslua.c rev 24479 on Win,
using VS2005EE. Anyone else that has run into this or is it just my (newly set
up) dev env that is wrong?
No: It's not you. :) :)
My Windows build fails in the
Stig Bjørlykke wrote:
Log:
Ensure tshark/wireshark always get good err msgs from dumpcap:
It looks like I'm getting the pipe header in my error message. Is
this intended?
Nope: I'm working on a fix...
Thanks
Bill
___
Wireshark-dev
Gerald Combs [EMAIL PROTECTED] writes:
The 0.99.8 roadmap still has the following items in the pending queue:
- Update the Windows PCRE package
Is there an up-to-date package available? If not, should we try to build
our own?
V7.0 is the the (latest) version on
Bug #2288 reports a problem wherein on Linux requesting a wireshark
capture to a file in a directory for which the user does not have write
permission causes a popup which says only:
Child capture process exited: exit status 2.
I've posted a rather longish analysis in the bug 2288 comments of
Bill Meier wrote:
bijjou2000 wrote:
hi
i want create a .exe file with NSIS. But I have this Failure:
Error in script wireshark.nsi on line 371 -- aborting creation process
Line 371 seems to be at the end of the following:
!else
!if ${MSVC_VARIANT} != MSVC6
!error C-Runtime
bijjou2000 wrote:
hi
i want create a .exe file with NSIS. But I have this Failure:
Error in script wireshark.nsi on line 371 -- aborting creation process
Line 371 seems to be at the end of the following:
!else
!if ${MSVC_VARIANT} != MSVC6
!error C-Runtime redistributable for this
I believe this file used $Revision$, $Date$, $Author$ because $Id$ was
used in the example code and two paragraphs above it and we didn't want
those $Id$s to expand to anything.
Oops: I missed that. I've reverted that change.
Thanks
___
at least on Linux after a make.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Log:
Create branch with gtk+ 2.12.8 glib 2.12.6-1 and pcre 7.0
Status of testing so far of the new libraries:
1. Windows Wireshark with Gtk 2.12.8 crashes;
2. Glib 2.14.6 requires the Iconv dll again. (Glib 2.14.5 did not require
same).
(Maybe they forgot about using win-iconv when
1. Windows Wireshark with Gtk 2.12.8 crashes;
Did you try with a distclean before building?
Yep :)
I did a (library) setup, an nmake maintainer-clean then an nmake all
again just to be sure;
Wireshark works when I do this with gtk 2.12.6 and crashes when
I do this with gtk
Stephen Fisher wrote:
Gerald,
What are the chances of getting the Sun C compiler instead of GCC on the
Solaris builtbot? We seem to be getting more and more reports of
Solaris build errors and warnings.
Now that I've looked at the Sun compiler warnings reported by David in a
bit
the time to generate the report.
I'll check out the warnings...
Bill Meier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
J.C. Wren wrote:
In the section of 3.2 of the documentation (shown below the 's),
the rule text to add is this:
snip
Thanks !
I'll take care of updating the documentation
Bill
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
What I need to do is to be able to extract out a specific VoIP call using
UNISTIM that spans multiple capture files based on IP Address and
Source and/or Destination Port and possible a within a specific time frame.
Altho I haven't tried this, I think the following should work:
tshark -r
Bill Meier wrote:
What I need to do is to be able to extract out a specific VoIP call using
UNISTIM that spans multiple capture files based on IP Address and
Source and/or Destination Port and possible a within a specific time frame.
Altho I haven't tried this, I think the following should
Bill Meier wrote:
I guess not (altho the error message is a bit weird):
Only read filters, not capture filters, can be specified when
reading a capture file.
I'm too quick off the mark today.
-f is the switch to specify a capture filter so the error message is
correct
C:\wireshark-0.99.7nmake -f Makefile.nmake all
Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'c-auto.h'
Stop.
Is this the only output from the 'nmake ...
Hold the press !!
There's been an update on the GTK bug report that indicates the bug has
been fixed in the freshly released GTK 2.12.6.
I'll check into it.
Bill
---
This problem isn't reproducible in the freshly released GTK+ 2.12.6. Windows
binaries at
Bill Meier wrote:
Hold the press !!
There's been an update on the GTK bug report that indicates the bug has
been fixed in the freshly released GTK 2.12.6.
I'll check into it.
Bill
---
This problem isn't reproducible in the freshly released GTK+ 2.12.6. Windows
binaries at http
Anders Broman [EMAIL PROTECTED] writes:
Bill Meier writes:
Once that's done, I'll be happy to make the required changes to
Makefile.nmake and tools/win32-setup.sh
Done - please do the other stuff - got to go...
/Anders
Makefile.nmake and etc have been updated.
Thanks to everyone
Bill Meier schrieb:
I've been going through all the GtkCombo usages and understanding exactly how
snip
I'm leaning towards writing wrapper functions which
provide the combo functionality required by Wireshark in terms of either
GtkCombo or GtkComboBox.
I haven't quite finished convincing
Re:
How is the conversion getting along? What parts are still to be addressed?
It's
a blocker bug for Win32, so lets get it sorted out.
I've been going through all the GtkCombo usages and understanding exactly how
each case works (User Interface) and how each can be implemented using
FWIW:
I note that when Wireshare opens a VMS sample capture file from
http://wiki.wireshark.org/SampleCaptures, the following warning messages
appear on the console:
15:50:27 Warn pcapng_read_block: Unknown block_type: 0xa200a20 (block
i
gnored)
15:50:27 Warn
Ulf Lamping wrote:
... so I guess the find call doesn't find the upx.exe, so chmod isn't
called. As a remark, AFAIK this is the first time for an exe needs this
bit, so the find call might never have been worked correctly before.
After a quick look, I've committed a change (SVN 23675)
Ulf Lamping wrote:
1Verifying that the DLLs and EXEs in . are executable.
1++ /usr/bin/find . '(' -name '*.dll' -o -name vcredist_x86.exe ')'
1+ for i in '`/usr/bin/find . \( -name *\.dll -o -name *\.exe \)`'
more dll's but
chetan jha wrote:
...it is not showing me any interfaces in my
interface list
From http://www.wireshark.org/lists/wireshark-users/200706/msg00113.html
You need to run wireshark with elevated privileges. Please try starting
wireshark by right-clicking on the wireshark link and choosing run
Shah, Sachin wrote:
These two plugins have completely different signature, so they are very
easy to differentiate. Following is snippet from dissect_*** methods of
each:
From packet-xxx.c
s1 = tvb_get_guint8(tvb, 0);
if (s1 != 0x01 s1 != 0x02 s1 != 0x03)
return;
From
It appears that something related the latest Windows GTK 2.12.0 associated
libraries is causing Windows WS to crash when GtkOptionMenu widgets are
displayed.
The crashes do not happen with the previous set of Windows GTK2 libraries.
Please see Bug #1915 for details.
Bill
Abhik Sarkar wrote:
Is there some way
this can be improved or it there something wrong with the capture itself?
(VMS being near and dear to my heart) I'll have a look-see.
Bill
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
Abhik Sarkar wrote:
For a few versions now (since 0.99.5), I have been unable to open
OpenVMS tcptrace files using Wireshark. A sample file is attached. In
some cases, the File Open dialog preview shows is as an invalid Endance
ERF file, sometimes an invalid Lucent/Ascend format and so
[EMAIL PROTECTED] wrote:
Log:
Fix two typos: ansi_tcap -- ansi-tcap
Directory: /trunk/asn1/
ChangesPath Action
+1 -1 Makefile.amModified
Directory: /trunk/
ChangesPathAction
+1 -1 configure.inModified
I've done the above to
Gerald Combs wrote:
It's working for me on Ubuntu, OS X, and Solaris, except for writing to
stdout.
Running tshark -w - in each case doesn't produce any output. Writing
directly
to a file works fine.
Presumably that's why the windows buildbot 'tests' step is failing
Toralf Förster wrote:
Hello,
I get :
(lt-wireshark:8404): GLib-GObject-WARNING **: invalid cast from `GtkToolbar'
to `GtkWindow'
(lt-wireshark:8404): Gtk-CRITICAL **: gtk_window_get_modal: assertion
`GTK_IS_WINDOW (window)' failed
when I click at the +Expression after I started
(After missing a Windows Wireshark library update once too often)
I've committed a change to the top-level Windows Makefile.name file
which checks for the presence of the required library 'packages' (zip
files) whenever the top-level Makefile.nmake is updated (or a clean
build is done).
The
Fulko Hew wrote:
(on wireshark 0.99.4)
I was looking at the results from the Capture-Interface statistics display
and the information I get from _my_ embedded system, and I thought
I had an error, but I don't think I do...
In ./gtk/capture_if_dlg.c: update_if() the comments talks about
501 - 600 of 631 matches
Mail list logo
