Re: [Wireshark-dev] Crash on Edit Preferences
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 Build Env: VC++ 2008 EE To investigate, I start Wireshark and then attach to it from VC++. Then I go to Edit Preferences. The result is that the program always stops due to an access violation and VC++ opens the file packet-vnc.c and breaks at this block in vnc_server_framebuffer_update case ENCODING_COPY_RECT: bytes_needed = vnc_copyrect_encoding(tvb, pinfo, offset, vnc_encoding_type_tree, width, height); break; I can't figure out what packet-vnc.c would have to do with my going to Edit Preferences, but that what always comes up. Perhaps I am doing something wrong. Can someone help out or suggest a new approach to try and find the problem? Version 1.0.4 works properly on the same machine. Is this similar to bug #2053 ? (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2053) Are you displaying packets (from a file or whatever) when you go to edit ! preferences ? When do you get the crash ? If you are displaying packets and the crash happens when you exit edit ! preferences, then the bug might be the same as #2053. If not, can you step through the edit ! preferences code to see when the crash occurs ? (I worked on bug 2053 for a while, made some progress but eventually got frustrated. I found that the problem seemed to have something to do with the GUI code invoked when redissecting packets after a preferences change and related to a gui callback during that code to redisplay the selected packet. My sense was that there was some kind of issue between the main line code and the callback which (sometimes) caused a crash. (Dependent upon the exact leftovers on the stack ?? other ??). I would repeat what seemed like the same sequence of user actions and only sometimes get a crash. I got far enough to see that I would have to spend some amount of time understanding in detail the GUI code related to displaying the packet dissection but then ran out of energy). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26904: /trunk/plugins/unistim/ /trunk/plugins/unistim/: packet-unistim.c
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 collides (at least) with tapa. */ It appears to me that, strictly speaking, the rev 26904 change does not convert the unistim dissector to a heuristic dissector but to to a new style dissector (with some heuristic tests). In any case, since dissector_add is still used to register port 5 on udp.port, the collision with tapa (as well as some other dissectors) still exists. I could make the change to actually register the dissector as a heuristic one instead (via heur_dissector_add). However, the just added heuristic seems quite minimal: Either [0,1] in the first byte or [2],[0-3,ff] in the first two bytes seems to me to be a rather weak heuristic. Would adding a check for port 5000 (or whatever from the pref) as part of the heuristic make the heuristic strong enough ? If it's not possible to strengthen the heuristic, I'm inclined to revert this change given various previous EMails etc on this subject. Comments (or am I missing something) ?? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] Decode As dialog doesn't offer SMB
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: Wireshark registers TCP port 445 as (what I'll call) a null variant of Netbios Session Service. (The null variant is just a 4 byte framing header). SMB/SMB2 are then considered be two possible protocols running over NBSS (either the normal NBSS or the null version). ( The code is written such that *only* traffic seen on port 445 will be treated as the 4 byte framing header followed by a protocol such as SMB/SMB2/MQ. Using NBSS for decode as will not work). One approach to allowing the use of decode-as for the variant registered to tcp port 445: In packet-nbns.c Register a new protocol: Call it ??? (microsoft-ds ???) Change the code so that there is a dissect_nbss and a dissect_??? The first calls the common main nbss code with an argument is_cifs as FALSE; the second with an argument is_cifs = TRUE. I believe the above would then allow a port other than 445 to be dissected the same as port 445 (via decode-as for the ??? protocol). Will using this be confusing to those not familiar with the exact details of the protocol layering ?? or: Simpler: just provide a NBSS preference to set the (??? microsoft-ds) port (default of 445). (The IANA port assignment document assigns port 445 (both TCP UDP) to Microsoft-DS). Comments ?? Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] Decode As dialog doesn't offer SMB
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. Comments ?? Never mind :) I was wrong. Using NBSS as the decode as does work (as Ronnie noted in his reply to John Walsh). Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] Decode As dialog doesn't offer SMB
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 tomorrow when I'm not falling asleep... Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Debugging WireShark / Visual 2008 / XP
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 !! I'm not sure what's going on Are you using File ! Open ! Project/Solution ? (The wiki page should be a more specific on this; I'll update the entry). In any case, let us know how you make out. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Debugging WireShark / Visual 2008 / XP
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. As implied, you'll need to use File ! Open ! Project/Solution:) Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Debugging WireShark / Visual 2008 / XP
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 out it starts most of the time). My Question is how do I go about debugging the WireShark.exe to find out where the fault address crash is ?? (1) – Are there any log files or debugging info .?? (2) – Do I use the Visual 2008 debugger – if so, Do I need to compile in debug mode ?? I am not very familiar with Visual 2008 – so any tips would be appreciated See Using MSVC++ for debugging under http://wiki.wireshark.org/Development/Tips. It's also worthwhile to spend a little time familiarizing yourself with the various VS debugging windows and function keys (F5, F10, F11, etc). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Debugging WireShark / Visual 2008 / XP
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 described in the Wiki link I gave). Is this what you are doing ? Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] About Wireshark Dissector development environment
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 Windows XP ald Windows XP is certainly OK for Wireshark development. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26687: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
[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 dropdown Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] MSVC2008EE or 2005EE
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 that the current Lua DLL depends upn MSVCR90.dll. One work-around is to build Windows VC6 Wireshark w/o Lua support by commenting out the Lua line in config.nmake. That being said: I'm not sure what the deal is with Lua requiring MSVCR90; I expect someone with more knowledge will be able to answer that. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] problem on Prepare cmd.exe
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 knows what's changed?
For VC9 (VS2008) you only need to call vcvars32.bat.
I guess the missing step is the reason why I'm seeing the following error:
C:\wireshark-1.0.4nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
tools/win32-setup.sh: line 4: $'\r': command not found
tools/win32-setup.sh: line 11: $'\r': command not found
tools/win32-setup.sh: line 14: $'\r': command not found
tools/win32-setup.sh: line 15: syntax error near unexpected token `$'{\r''
'ools/win32-setup.sh: line 15: `err_exit () {
NMAKE : fatal error U1077: 'd:\downloads\cygwin\bin\bash.EXE' : return code
'0x2
'
I'm not altogether sure what this is;
Is MSC_VARIANT properly defined for VS2008 in config.nmake ??
I should note that the '\r' command not found stuff sounds like an issue
related to cygwin bash being run without the igncr option and
thus having trouble with the DOS \r\n line endings of the
win-32-setup.sh file. However, this should not happen inasmuch as the
config.nmake should automatically deal with this issue.
Is cygwin up to date ?
Do you have c:\cygwin\bin in your Path ?
If you continue to have this problem, please post the complete output
from the nmake -f ... verify-tools as well as a listing of your
environment variables (from a 'set' command) so we can see what's going on.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how to debug on windows?
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 debug chapter is empty. I tried to start debugging in MSVC and wireshark did run, but it didn't break at the breakpoint I set. Many thanks, Joshua Several comments: 1. If possible, it's probably a good idea to use VS2008 EE since that's what is being used for the standard Wireshark Windows builds. (See the developer document). 2./ Re: But since we're compiling/building it using the gcc tool, I'm not sure what you mean here. The Windows build of Wireshark uses the Microsoft compiler (not the GCC compiler) from the command line (as well as using some cygwin stuff). 3. For debugging using VS see http://wiki.wireshark.org/Development/Tips using vatrious cygwin stuff) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how to debug on windows?
(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 or should I use gdb? How should I start? I read the online manual for developers but the debug chapter is empty. I tried to start debugging in MSVC and wireshark did run, but it didn't break at the breakpoint I set. Many thanks, Joshua Several comments: 1. If possible, it's probably a good idea to use VS2008 EE since that's what is being used for the standard Wireshark Windows builds. (See the developer document). 2. Re: But since we're compiling/building it using the gcc tool, I'm not sure what you mean here. The Windows build of Wireshark uses the Microsoft compiler (not the GCC compiler) from the command line (as well as using some cygwin stuff). 3. For debugging using VS see http://wiki.wireshark.org/Development/Tips ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26535: /trunk/ /trunk/epan/dissectors/: packet-dcom.c packet-dtls.c packet-frame.c packet-ieee80211.c packet-ssl.c /trunk/gtk/: capture_if_details_dlg_win32
[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 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how to debug on windows?
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 recommended free version :( ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] runtime error using plugin withprefs_register_enum_preference
[EMAIL PROTECTED] wrote: /*prefs_register_enum_preference(ismacryp_module, ismacryp.encoding, ismacryp version, ismacryp version, version_type, version_types, FALSE); */ The specific problem is that the preference name (ismacrypt.encoding) cannot contain the protocol name (see doc/README.developer). After changing the name to encoding, things were OK. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] runtime error using plugin with prefs_register_enum_preference
[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 version_types[] = {
{PROTO_TAG_ISMACRYP_11, PROTO_TAG_ISMACRYP_11, 11},
{PROTO_TAG_ISMACRYP_20, PROTO_TAG_ISMACRYP_20, 20},
{NULL, NULL, 0}- some dissectors have -1 here instead of 0
but makes no difference
};
prefs_register_enum_preference(ismacryp_module, ismacryp_encoding,
ISMACryp version,
ISMACryp version,
version_type, version_types, FALSE);
To get the simple question out of the way first :)
Did you do a prefs_register_protocol ?
(At first glance I don't see anything obviously wrong with the above code).
Bill
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] stdio.h/stdlib.h includes apparently not req'd in epan/dissector source files ....
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 that I shouldn't. After that, I plan to review generated files, plugins etc as well. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] stdio.h/stdlib.h includes apparently not req'd in epan/dissector source files ....
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 valid point. I'll hold off for now. Interestingly enough, I do note that just about half of the epan/dissector .c source files do not include stdio.h (and more than half do not include stdlib.h) and I've not heard of any issues with NULL etc (although I don't know if anyone has built Wireshark with GCC 4.3). Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New dissector for AYIYA
[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 plugin will become a part of my seminar paper, so I hope, there is nobody who is already writing such a plugin. Otherwise this would be a useful information for me. A dissector for the AYIYA protocol was just committed to the Wireshark development source repository on September 29 See: http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-ayiya.c from the Wireshark development tree. It sounds like it's time for Plan B :) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Adding live 802.15.4 Capture
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 :)
or:
Maybe the patch supplied doesn't completely reflect your actual code and
the problem is actually that:
The preference appears (perhaps confusingly) under IEEE 802.15.4 (the
protocol short name) since that's the way the protocol is registered.
proto_ieee802154 = proto_register_protocol(
IEEE 802.15.4 Low-Rate Wireless PAN,
IEEE 802.15.4,
wpan);
(wpan is used as the filter_name)
Notes:
1. If the patch supplied reflects your actual code, you should have
gotten a compilation error due to the missing include file. If you
didn't, you'll need to revisit your compilation process.
2. The patch file is 'backwards' (new -- old) so could not be applied
to packet-ieee802154.c as is. (I hand-edited the patch file so as to be
usable).
3. I've taken the liberty to re-arrange the proto_reg_handoff code
slightly. See the attached revised patch. (I've recently been doing work
on the proto_reg_handoff functions in various of the dissectors and will
be updating the doc/README.developer shortly).
The attachment is a revised version of your patch and is against the
current development version of packet-ieee802154.c.
Index: packet-ieee802154.c
===
--- packet-ieee802154.c (revision 26322)
+++ packet-ieee802154.c (working copy)
@@ -77,6 +77,7 @@
#include epan/crc16.h
#include epan/expert.h
#include epan/addr_resolv.h
+#include epan/prefs.h
#include packet-ieee802154.h
#include packet-frame.h /* For Exception Handling */
@@ -85,6 +86,9 @@
#define DISSECT_IEEE802154_OPTION_CC24xx0x0001 /* FCS field contains
a TI CC24xx style FCS. */
#define DISSECT_IEEE802154_OPTION_LINUX 0x0002 /* Addressing fields
are padded DLT_IEEE802_15_4_LINUX, not implemented. */
+/* ethertype for 802.15.4 tag - encapsulating an Ethernet packet */
+static unsigned int ieee802154_ethertype = 0x809A;
+
/* Function declarations */
/* Register Functions. Loads the dissector into Wireshark. */
void proto_reg_handoff_ieee802154 (void);
@@ -1662,6 +1666,8 @@
ett_ieee802154_bcn_pending
};
+module_t *ieee802154_module;
+
/* Register Protocol name and description. */
proto_ieee802154 = proto_register_protocol(IEEE 802.15.4 Low-Rate
Wireless PAN, IEEE 802.15.4, wpan);
@@ -1669,6 +1675,14 @@
proto_register_field_array(proto_ieee802154, hf, array_length(hf));
proto_register_subtree_array(ett, array_length(ett));
+/* add a user preference to set the 802.15.4 ethertype */
+ieee802154_module = prefs_register_protocol(proto_ieee802154,
+ proto_reg_handoff_ieee802154);
+prefs_register_uint_preference(ieee802154_module, 802154_ethertype,
+ 802.15.4 (Hex) Ethertype,
+ (Hexadecimal) Ethertype used to indicate
IEEE 802.15.4 frame.,
+ 16, ieee802154_ethertype);
+
/* Register the subdissector list */
register_heur_dissector_list(wpan, ieee802154_heur_subdissector_list);
@@ -1684,6 +1698,7 @@
* DESCRIPTION
* Registers the zigbee dissector with Wireshark.
* Will be called every time 'apply' is pressed in the preferences menu.
+ * as well as during Wireshark initialization
* PARAMETERS
* none
* RETURNS
@@ -1692,13 +1707,26 @@
*/
void proto_reg_handoff_ieee802154(void)
{
-dissector_handle_t ieee802154_handle;
+static gboolean prefs_initialized = FALSE;
+static dissector_handle_t ieee802154_handle;
+static unsigned int old_ieee802154_ethertype;
-/* Get the dissector handles. */
-ieee802154_handle = find_dissector(wpan);
-data_handle = find_dissector(data);
+if (!prefs_initialized){
+/* Get the dissector handles. */
+ieee802154_handle = find_dissector(wpan);
+data_handle = find_dissector(data);
+dissector_add(wtap_encap, WTAP_ENCAP_IEEE802_15_4,
ieee802154_handle);
+
+prefs_initialized = TRUE;
+} else {
+dissector_delete(ethertype, old_ieee802154_ethertype,
ieee802154_handle);
+}
+
+old_ieee802154_ethertype = ieee802154_ethertype;
+
/* Register dissector handles. */
-dissector_add(wtap_encap, WTAP_ENCAP_IEEE802_15_4, ieee802154_handle);
+dissector_add(ethertype, ieee802154_ethertype, ieee802154_handle);
+
} /* proto_reg_handoff_ieee802154 */
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Question about missing break; in packet-ncp22222.inc
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 ok as is, at the very least, it might help to include a comment of intentional fall-through to avoid confusion). - Chris I agree: It certainly looks like a typo/bug introduced in the last SVN commit for this file. I'll commit the fix and will also forward an EMail to Greg Morris (who did the last commit) in case he doesn't see this EMail thread. Thanks to the OP (original poster) for finding this ... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] dissector_add: Multiple registrations to same TCP/UDP ports;
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 it. Having dug a bit further into the three protocols I'm inclined to just do a dissector_add_handle in the airopeek cpfi dissectors leaving only the tapa dissector registered on port 5000. 1. Currently it appears that the airopeek dissector can already only be accessed via decode-as. 2. It also appears that the cpfi dissector can currently only be accessed via decode-as (or by changing cpfi port preference). In any case: Two of the dissectors (cpfi and tapa) are already new-style. The issue, unfortunately, is that currently all 3 dissectors explicitly register themselves to udp port 5000 via dissector_add(). Since there's no checking in dissector_add for duplicate registrations the net result is that the last dissector to register on udp port 5000 wins with the previous registrations being obliterated. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] dissector_add: Multiple registrations to sameTCP/UDP ports;
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 can be given. Register to port zero Still gives the possibility to do decode as and with a preference The user who needs this protocol can give the port value used in that environment. Heuristics may not be possible. For the cases in which there is no actual dissector port preference, it seems to me that dissector_add_handle() (rather than registering to port 0) should be used to allow decode as. Am I missing something ? Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] dissector_add: Multiple registrations to same TCP/UDP ports;
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 5000 already registered to: cpfi result: cpfi airopeak registrations lost (as well as a little memory leak) = tcp.port: dsctr: tcpencap; key 1 already registered to: ndmp result: ndmp registration lost -- Q1: Can anyone suggest the appropriate resolution of these conflicts ? Q2: It seems reasonable to me to add code to dissector_add and friends to validate the arguments: handle != null pattern (key) not already in the dissector table Is this OK ? (If so, I'll add the code). (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.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol dissector
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 Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Windows build docs step failing on xmllint of wslua_pinfo.xml
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 ../epan/wslua/wslua_listener.c ../epan/wslua/wslua_pinfo.c ../epan/wslua/wslua_proto.c ../epan/wslua/wslua_tree.c ../epan/wslua/wslua_tvb.c ../epan/wslua/wslua_util.c touch wsluarm --- WSUG - VALIDATING XML --- xmllint --valid --noout user-guide.xml wsluarm_src/wslua_pinfo.xml:46: element section: validity error : Element section content does not follow the DTD, expecting (sectioninfo? snip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Windows build for VS 2008
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 https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Using ptvcursor in a Plugin
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)... that dropping my plugin.dll into a standard installation this may not play well since the standard Windows Wireshark is built with VC6. I think a little web searching should find other message threads on this topic. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25794: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gsm_a.c
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 of static const value_string ...; I'll commit the checkAPIs.pl changes in a bit. (ToDo: investigate cases of value_string definitions such as const value_string ...;). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] wireshark-win32-libs rev 180: /trunk/packages/gtk2.12/ /trunk/packages/gtk2.12/: glib-2.16.5.zip glib-dev-2.16.5.zip gtk+-2.12.11.zip gtk+-dev-2.12.11.zip pango
[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 when started and a capture is loaded ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SVN #25615: Wiretap code probably shouldn't abort the application either.
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 (although there is something that looks like an error message (possibly not relevant) in the log for each step). I don't know how the packaging etc works as part of the build so I'll just note that the packages don't seem to be ending up in the .../win32 directory. The packages from the latest build are in the .../automated/win32 directory again since the build has now completed successfully. (copy packages is the last step of the Windows buildbot build; [I'd forgotten]); ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SVN #25615: Wiretap code probably shouldn't abort the application either.
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 allow the Development Windows install package to be built (assuming no other errors). The following 4 wiretap files appear to use g_error etc in relation to checking for programming errors. Q: Is the use of g_error etc not OK in these cases ? buffer.c: exit,g_error etherpeek.c: g_assert file_access.c: g_error k12.c: g_assert -- 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 ngsniffer.c: g_assert pppdump.c: g_assert wtap.c: g_assert ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SVN #25615: Wiretap code probably shouldn't abort the application either.
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. However: ngsniffer.c: g_assert snip Seems as to how my quick look was much too quick (at least for one and possibly for two reasons) :-( 1. My thanks to Guy for his detailed reply about ngsniffer etc My understanding of the replies is that the current usage of g_error g_assert in wiretap files is OK. (I'll remove the 'debug' case in k12.c). 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 (although there is something that looks like an error message (possibly not relevant) in the log for each step). I don't know how the packaging etc works as part of the build so I'll just note that the packages don't seem to be ending up in the .../win32 directory. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25761: /trunk/wsutil/ /trunk/wsutil/: Makefile.nmake
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 some utilities (capinfos, editcap) weren't calling get_credential_info() which was causing them to not work correctly. Since the assert is to prevent a programming error so it makes sense to me to keep it there though I guess there could be another way... It's fine by me... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compile error using svn revision 25628
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 'treat all warnings as errors' (for the most part). (I know since I've been gradually fixing -Wshadow warnings). I would expect that there will also be warnings (and thus make errors) for -Wcast-qual. -Wpointer-arith is (as far as I can see) is already included in the default CFLAGS. I suggest not using the extra CFLAGS if you want to build Wireshark w/o warnings (and thus Make errors). Alternatively, you'll need to remove the -Werror. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wireshark utilities unable to read large files
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). Thanks ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] buildbot failure in Wireshark (development) on Ubuntu-7.10-x86-64
[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 this Build: ubuntu-7.10-x86 -- [How does one get access to the two copied files from -- the failure ?] -- From the log: /var/lib/buildbot/menagerie/sample: /home/buildbot/bb-wireshark/trunk/ubuntu710x86/build/tools/fuzz-test.sh: line 119: 16642 Segmentation fault (core dumped) $TSHARK $TSHARK_ARGS $TMP_DIR/$TMP_FILE /dev/null 2 $TMP_DIR/$ERR_FILE ERROR Processing failed. Capture info follows: Output file: /home/buildbot/bb-wireshark/trunk/ubuntu710x86/menagerie-fuzz/fuzz-2008-06-26-25238.pcap fuzz-2008-06-26-25238.err 0 100%0.00kB/s0:00:00 (xfer#1, to-check=1/2) fuzz-2008-06-26-25238.pcap 5759 100%0.00kB/s0:00:00 5759 100%0.00kB/s0:00:00 (xfer#2, to-check=0/2) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25499: /trunk/ /trunk/: Makefile.common editcap.c
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 changes from me: - make use of nstime_set_unset and nstime_is_unset i.s.o. extra variable first_pass - change 'if' to 'while' to allow intervals with no packets - remove 'unused' variable current_pkt_ts Directory: /trunk/ ChangesPath Action +1 -0 Makefile.commonModified +72 -3 editcap.c Modified I seem to have broke the Windows build. I'm firing up my WinXP dev-image to see if I can fix it... Cheers, SAke ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev I've got a simple Makefile fix I'm about to commit :) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25499: /trunk/ /trunk/: Makefile.common editcap.c
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 Modified I seem to have broke the Windows build. I'm firing up my WinXP dev-image to see if I can fix it... I've got a simple Makefile fix I'm about to commit :) I was about to commit the same changes to 'Makefile.nmake', but won't your changes to 'Makefile.common' break the '*nix' builds? I had added 'nstime.c' to Makefile.common to make it compile on my FC8 development image. Cheers, Oops Seems as to how I broke things the opposite way ! (Sorry) I'll revert the Makefile.common change. It seems to me that the right fix for the Windows build is to use editcap_SOURCE, etc. I'll dig a bit deeper later today. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25505: /trunk/gtk/ /trunk/gtk/: capture_dlg.c capture_if_details_dlg_win32.c capture_if_dlg.c capture_info_dlg.c color_dlg.c conversations_table.c decode_as
[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 capture_if_details_dlg_win32.cModified snip HELP_CAPTURE_INTERFACES_DETAILS_DIALOG is undeclared in capture_if_details_dlg_win32.c thus causing a Windows build to fail ... Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Failure.Please help!!
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 'nmake -f Makefile.nmake distclean' and then a 'nmake -f Makefile.nmake all' and watch what folders that are created). In the end of the build, all necessary files are copied (using xcopy in windows) into /wireshark-gtk-1 and /wireshark-gtk2 and in those folders all dependencies are on the right places. The C:\wireshark-1.0.0\ is only a placeholder of the development files until the build is ready. Was I fussy or (or perhaps even wrong) somewhere? If so, please say that. You are quite correct: the wireshark-gt? directories are especially created and populated to contain all the dependencies (dlls and etc) required to run wireshark, tshark etc on Windows in the development environment. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] FW: Build Failure.Please help!!
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. bison -d -p ascend ascend-grammar.y -o ascend-grammar.c * c:\util\gnu\bin\bison.EXE: /usr/local/lib/bison.simple: No such file or director * c:\util\gnu\bin\... as a path seems a bit unexpected Are you using cygwin ? If not, I suggest you start over (following exactly the instructions in the developer's guide). (The wireshark windows build is based upon the use of cygwin). For example; the cygwin version of touch implements the --reference option. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
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 the packet details to the originally-transmitted frame if they need to see the dissection of the payload. L On Wed, May 28, 2008 at 10:24 PM, Sake Blok [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) It's a mixed up world, we should have all bugs fixed before the end of the day and never run out of beer... and *not* the other way around ;-) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. 1. Given that TCP is a streaming protocol, ISTR that a retransmitted frame can actually consist partially of bytes previously sent and partially of additional bytes not previously sent. If this is the case (and I'm not missing something), then presumably the tcp dissector would need to forward any new bytes of a frame. 2. How does re-assembly play into this discussion ? I haven't looked at the SSL dissector so I don't know how it works. Is re-assembly being used ? Doesn't re-assembly in effect take care of retransmissions (at least in some cases) ? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compilation error on Windows with VC 6
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 with the errors below for your reference. Any help will be greatly appreciated. = Compiling... gui_prefs.c gui_utils.c help_dlg.c D:\Programs_Win2K\Microsoft Platform SDK for Windows Server 2003 R2\Include\html help.h(374) : error C2146: syntax error : missing ')' before identifier 'dwData' There may be several different things goiung on However: first things first: If you are compiling with VC6 I would not have expected D:\Programs_Win2K\Microsoft Platform SDK for Windows Server 2003 R2\include\html to be in the include path. 1. Did you start a fresh cmd window and then execute the vc6 setup file c:\Program Files\Microsoft Visual Studio\VC98\Bin\vcvars32 ? (The actual location of the VC6 setup file might be different depending upon how VC6 was installed on your PC). 2. Did you do a distclean ?? 3. Did you edit the config.nmake file to set the proper value for MSC_VARIANT ? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] checkAPIs being run every incremental build on Windows
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 checkapi' step to the Windows buildbot, which halts on failure. Is this sufficient for the Buildbot side of things? Thanks ! I'll modify the various Windows makefiles so that nmake ... checkapi at the top level will do an nmake ... checkapi for the relevant lower level directories (only as appropriate; ie: if the sources for any specific directory have already been cleaned up with respect to checkapi). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Buidling Wireshark using MingW/MSyS on WIndows ?
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 pretty hard to get compiled using Microsoft's IDE. Please let us know how you make out. I've been thinking about trying to build Wireshark using MinGW/MSys but never got around to it. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Bug 2470] Buildbot crash... What TCP preferences are used during Ubuntu Buildbot fuzz-testimg ?
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 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] checkAPIs being run every incremental build on Windows
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 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. Or: maybe a way to run checkAPIs only on changed files ? My 2cents ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25170: /trunk/ /trunk/: config.h.win32
[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.win32Modified Unfortunately this only works for some of the lex files. I've fixed the others as described in the bug #2493 comments. I haven't yet committed the changes for this bug because there is still other generated code causing compiler warnings (eg: 'signed/unsigned mismatch'; I'm working through these and hope to commit everything today. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
[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 C4244: 'function' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible s of data Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] 1.0.0 source code build failure in Visual C++ 6 on Win XP
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 http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493. The Wireshark source code has been changed to fix the build errors as of a little while ago. You can either 1. apply one of the work-arounds given in comment #15 of the bug report or: 2. Down load a current source tarball from http://www.wireshark.org/download/automated/src/ Note that you will need a source tarball for SVN 25178 or greater. This should appear at the above URL within an hour or two. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Should we support GTK+ 2.0[.x] and 2.2[.x], or just 2.4 and later?
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 and which give the GTK version is as follows: 1 GTK+ 2.0 [2006-11-03] 3 GTK+ 2.2 [2005-10-28] [2006-05-03] [2008-02-17] 64 GTK+ 2.4 144 GTK+ 2.6 4 GTK+ 2.7 114 GTK+ 2.8 158 GTK+ 2.10 2 GTK+ 2.11 149 GTK+ 2.12 1 GTK+ 2.15 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25097: /trunk/ /trunk/gtk/: about_dlg.c webbrowser.c webbrowser.h /trunk/: configure.in
[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 system, double-clicking on any of the links for 'Global Configuration', 'System' and 'Program' actually starts Wireshark. Looking a little deeper: the 'parent' directory specified in these links has a wireshark-gtk2.exe as well as a wireshark-gtk2 directory. (This is my standard wireshark development setup). Any way to force the path to be opened in file manager as a directory as opposed to first defaulting to trying the path as an executable ? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25097: /trunk/ /trunk/gtk/: about_dlg.c webbrowser.c webbrowser.h /trunk/: configure.in
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, either. I suspect what happens with the explore verb is that Windows Explorer says hey, wireshark-gtk2.exe isn't a directory, I can't open that up as a folder window! I guess we need some way to convince the UI that when we say wireshark-gtk2 we really mean wireshark-gtk2, not wireshark-gtk2.* and use the 'best' one you find - if there is a way to do that. ___ Just to see what would happen I added a trailing '\' to the path. This worked using 'explore'; (I guess it would probably also work using 'open'). Would it be OK on Windows to add the trailing '\' (if missing) ? I'm guessing that trying to have all 'directory paths' (eg datafile_path, progfile_dir, etc) have the trailing separator would break stuff at this point; A quick look suggests to me that currently some do and some don't. I do note: get_datafile_dir already defaults to using the trailing '\' (on Windows): datafile_dir = C:\\Program Files\\Wireshark\\; Thoughts ? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GTK1: code cleanup status and some open points
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 just get rid of that old file :). The most commonly used macros need to change as follows: OBJECT_SET_DATA(widget, key, data); to: g_object_set_data(G_OBJECT(widget), key, data); Done !! OBJECT_GET_DATA(widget, key); to: g_object_get_data(G_OBJECT(widget), key); Done !! SIGNAL_CONNECT(widget, name, callback, arg); to: g_signal_connect(widget, name, G_CALLBACK(callback), arg); (depending on the type of arg, it may need to be cast to a gpointer) Indeed:). I think the next step is to get rid of GTK1 features that have been deprecated in GTK2, such as the CList (which should be possible for all instances except the packet list). Of course, this will take plenty of work to port the code to the new APIs. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problems with epan\oids.c
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 binaries (1.0 for instance). It need only affect the Windows based developers that do not have MS VC6 at hand until a long term solution has been applied. Sounds reasonable: I'll commit a patch shortly (adapted from your previous suggestion) to do this. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problems with epan\oids.c
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 the 1.0 release. A fix can then be implemented and tested for the next release. Thanks for taking the initiative on this. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24675: /trunk-1.0/
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 the GTK+ release. I know we need GTK+2.12.6 to fix bug 2066. Are there any other GTK+/Glib issues present that need te be taken into account in choosing the optimum GTK+/Glib release? Bug 2325 Desc 'Edit Preferences - Protocols' does not accept more than one character anymore Sol Use GTK+2.12.6 ??? FWIW: This GTK bug may soon get a fix ... From the gnome bug report on this --- Comment #4 from Cody Russell 2008-03-18 17:26 UTC --- Daniel prodded me in irc just now, so I'll do this today. I didn't have a Win32 setup to test on when I was in Berlin so I just put this off last week, sorry about that. Even so, I'll guess a GTK release with the fix won't appear right away (especially since there's just been a gtk release) so falling back to Windows gtk 2.12.6 (I believe -2 on Windows) may very well be the right answer. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problems with epan\oids.c
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 application using the library was built; that's a rather alien notion to most if not all UN*X developers, and I suspect the libsmi developers started on some UN*X. nicely stated ! If so, yes, we should probably mention that to them, e.g. on the libsmi list. (While we're at it, we should probably also mention to them that: 1) there's an smi_render man page: http://www.ibr.cs.tu-bs.de/cgi-bin/dwww?type=manlocation=/usr/local/man/man3/smi_render.3 but there's no link to it in the sidebar on the libsmi home page: http://www.ibr.cs.tu-bs.de/projects/libsmi/ 2) that page doesn't indicate that the strings returned by those routines are mallocated.) A quick look at the last several messages on the list indicates that there's been recent changes related to compiling on Windows. I'll read thru the messages tomorrow and provide some comments/suggestions as appropriate and as per the above. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24446: /trunk/ /trunk/: capture_opts.c capture_sync.c dumpcap.c
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 Windows and Linux. Please let me know if any further issues are seen. Thanks Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for top-level Makefile.nmake
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 ! ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Outstanding 0.99.8 issues
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 left them in What is the recommended install configuration re privileges on *nix for wireshark etc ? I suggest updating INSTALL as needed and including the updated version in the 0.99.8 release. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compilation problem due to recent chang es in init_wslua.c
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 same manner. I expect I or someone else will fix the problem shortly. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24446: /trunk/ /trunk/: capture_opts.c capture_sync.c dumpcap.c
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 mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Outstanding 0.99.8 issues
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 the GnuWin32 PCRE page. (http://gnuwin32.sourceforge.net/packages/pcre.htm). IMHO it's too late in this release cycle to build and test our own. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 2288: Selecting multiple files...: Advice/thoughts requested
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 what I think is going on and some thoughts as to possible fixes. The problems basically relate to the use of dumpcap as a childwireshark/tshark child and can manifest themselves differently for wireshark and tshark. I would appreciate any comments which the developers might have. (I would normally have posted the analysis here, but since I started the analysis in the bug comments, I decided to continue the analysis there). Thanks Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] need help : NSIS
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 redistributable for this package not available /
notredistributable!
!endif
!endif ; MSVCR_DLL
!endif ; VCREDIST_EXE
So: please see section 2.2.1.3 of the Wireshark Developer's Guide about
getting the redistributable.
Ere: That's section 2.2.13
A link to the guide is at http://www.wireshark.org/docs/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] need help : NSIS
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 package not available /
notredistributable!
!endif
!endif ; MSVCR_DLL
!endif ; VCREDIST_EXE
So: please see section 2.2.1.3 of the Wireshark Developer's Guide about
getting the redistributable.
A link to the guide is at http://www.wireshark.org/docs/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24380: /trunk/
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 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] rawshark.html has 4 copies of most of text ...
at least on Linux after a make. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] wireshark-win32-libs rev 142: /tags/2008-02-15/
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 building the Windows version of Glib 2.14.6 ?); 3. I haven't yet tried the new pcre. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] wireshark-win32-libs
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 2.12.8. Wireshark with gtk 2.12.8 is crashing during a call to gtk_image_new_from_pixmap. I'm about to do a little digging to determine if I can see what's going on. 2. Glib 2.14.6 requires the Iconv dll again. (Glib 2.14.5 did not require same). Have you reported this tho the GTK guys? I was about to make a report when I discovered that there's now a glib-2.14.6-2 at http://ftp.gnome.org/pub/GNOME/binaries/win32/glib/2.14/ (even though http://www.gtk.org/download-windows.html hasn't yet been updated). 2.14.6-2 seems to work AOK in that it does not require iconv.dll Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24295: /trunk/ /trunk/epan/dissectors/: packet-dcerpc-nt.c packet-sccp.c packet-sctp.c /trunk/wiretap/: 5views.c iseries.c wtap-int.h
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 more detail (and learned more about exactly how Wireshark builds when using GCC): It appears that many of the warnings reported are for cases for which the Wireshark build explicitly (or implicitly) disables warnings. Two examples: 1. The Wireshark GCC build uses -Wno-pointer-sign to disable warnings having to do with things like: signed char * = unsigned char *. 2. The Wireshark GCC build does not (normally) use -Wcast-qual. The warnings not seen due to the the above two cases account for many of the warnings seen from the Sun compiler as described by David. (I'm sure there are additional cases). So: if we choose to use the Sun compiler, the first order of business will be a requirement for someone to determine if and how certain warnings can be disabled and then to adjust the build scripts appropriately. I will continue to go through the warnings to see if there's anything which stands out... Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compilation warnings using Sun's comp ilers on Solaris 10
Dr. David Kirkby [EMAIL PROTECTED] writes: Hi all, I thought this might be of use to some of the developers (if not copy to /dev/null). It shows a number of warnings during compilation of release 24290, some of which might just significant, such as integer overflows. Thanks for taking 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
Re: [Wireshark-dev] What files are really necessary to modify to add a plug-in?
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 http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Feature Request for EDITCAP - Selecting by IP Address and Port Number
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 input file -R read filter -f output file (You might need to write a script to run tshark on each of multiple files and then use mergecap to combine the output files). See the tshark help or manpage for additional information. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Feature Request for EDITCAP - Selecting by IP Address and Port Number
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 work: tshark -r input file -R read filter -f output file (You might need to write a script to run tshark on each of multiple files and then use mergecap to combine the output files). See the tshark help or manpage for additional information. 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. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Feature Request for EDITCAP - Selecting by IP Address and Port Number
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. The follow does seem to work, however: tshark -r filename -R read-filter -w output filename ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] nmake -f Makefile.nmake all is failing.
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 ... all' ? If not, please post (or attach) the complete output. Also: please post the output of the 'verify_tools' step. Thanks ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 2066: GtkCombo: Conversion Status
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://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.12/ My guess is that the problem was caused by bug #506769 . *** This bug has been marked as a duplicate of 506769 *** ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 2066: GtkCombo: Conversion Status
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://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.12/ My guess is that the problem was caused by bug #506769 . *** This bug has been marked as a duplicate of 506769 *** Er: That was Stop the press In any case: I've built and tested Windows Wireshark with GTK+ 2.12.6; The GtkCombo related crash is indeed fixed. So: I' appreciate it if someone downloads the new Gtk+ 2.12.6 Windows binaries to the repository and creates a new tag etc. (I'd do it but I'm on low-bandwidth dialup). Once that's done, I'll be happy to make the required changes to Makefile.nmake and tools/win32-setup.sh ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 2066: GtkCombo: Conversion Status
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 for the help on Bug 2066. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 2066: GtkCombo: Conversion Status
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 myself that this will be doable (another day should do it). Ulf Lamping wrote: This seems to be a bug in the GTK libraries, we should simply go back to the old GTK version that works and put some pressure on the GTK guys (the bug report seems to be written already). Bottom Line: I now think the right answer is to follow Ulf's suggestion to fall back to the GTK version currently being used with 0.99.7 and to push to get the GTK problem fixed (or a work-around determined). Reason: AFAIKT implementing the current Wireshark usage of GtkCombo using GtkComboBoxEntry has some problems (at least on Windows when using the Wimp style (theme ?). The problems I've noted: 1. I've found that the appearance of the GtkComboBoxEntry widget is unacceptable (to my eye) on Windows using Wimp in certain cases (see below). 2. Given the complexity of the usage of GtkCombo in certain cases (eg: the filter dropdown) I can well believe that using GtkComboBoxEntry will result in subtle UI changes which may not be initially apparent. It appears that using GtkComboBoxEntry is not altogether a simple drop-in. There are some number of details which need to be examined and worked though and which may be difficult to get right. (I was certainly naive about all of this). I think our effort is best spent elsewhere. Comments ?? - Some details: A number of the Wireshark GtkCombo usages would need to be implemented using GtkComboBoxEntry: for example: the filter dropdown in the main window. I've written wrappers using GtkComboBoxEntry which seem to be usable to reasonably cleanly replace the usage of GtkCombo. (I haven't done the detailed testing to see if everything works the same as currently; eg the handling of signals such as 'changed'). In any case, I've found that the appearance of the GtkComboBoxEntry widget is different on Windows using Wimp in certain cases; To my eye, the differences are not acceptable. For example: setting the GtkComBoxEntry widget as insensitive does not gray out the downarrow. Also: for some reason, the GtkEntry widget itself does not have the inward-beveled shadow and vertically fills the widget. The above may be problems with Wimp since these specific problems don't seem to exist after removing the gtkrc file (although obviously the look is quite different). I also wouldn't be surprised if there are other differences in appearance that I haven't noticed. (If anyone wants to look at all of this, I would be happy to provide a test program that I've written). Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Bug 2066: GtkCombo: Conversion Status
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 GtkComboBox (or, possibly in some instances, GtkComBoxEntry). There are about 16 usages and some of them are a bit complex. In any case, my understanding is that we'll need to continue to use the current GtkCombo widget for: - GTK1 (since we're still supporting Gtk 1 and since GtkComboBox is a Gtk 2.4 widget) - GTK2 2.4 (maybe 2.6) (ditto) To keep the code from getting really messy (with many #if GTK_CHECK_VERSION(...)), 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 myself that this will be doable (another day should do it). Comments are welcome. - A specific question: In Capture ! Options the Interface entry can be edited from the keyboard. It seems to me to not be useful to be able to enter text since presumably only the dropdown interface entries are valid. Am I missing something ? Is there a reason for this ? [It obviously would be nice if the GTK bug were fixed. :) I've spent some time trying to build a debug version of the GTK library on Windows but haven't succeeded because of something about using MinGW and Cygwin (or Msys) to make GTK that I don't yet understand.] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] pcap-ng support: warning message w
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 pcapng_read_block: couldn't read second block length 15:50:27 Warn pcapng_open_new: couldn't read first SHB Is this just debug output which eventually goes away ? This doesn't happen for all types of capture files presumably because of the order in which the various capture file types are tried ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] win32-setup.sh fails to set executable bit for upx.exe - any ideas?
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) which works for my directory configuration; Please give it a try on your system (YMMV). Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] win32-setup.sh fails to set executable bit for upx.exe - any ideas?
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 *no* exes since the find was looking for vcredist...exe
which happend to be in your top level directory (but not in mine).
I've submitted a fix which quotes the *\.dll and *.\exe
Bill
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Issue with Wireshark on Windows Vista
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 as administrator. This is a side effect of user account control (UAC) introduced in Vista. Even if you are logged in as an administrator, you do not have full privileges, you need to elevate your credentials to have full privileges needed to run wireshark (or better, to use winpcap which is part of wireshark). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Heuristic dissector conflict
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 packet-yyy.c s1 = tvb_get_guint8(tvb, 0); s2 = tvb_get_guint8(tvb, 1); if(s1 != 0x55) return; if(s2 != 0x55) return; At the very least you need to: return FALSE; if the heuristic fails. (Note that packet-??? should have been defined as static gboolean ... See (for example) packet-acn.c for an example of a heuristic dissector. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Windows WS GTK2 GtkOptionsMenu usage causes crashes
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 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Unable to open OpenVMS tcptrace
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 http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Unable to open OpenVMS tcptrace
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 on. I guess it is because the heuristics of one wiretap file format reader is better than the others in case of plain text files. Is there some way this can be improved or it there something wrong with the capture itself? I've tightened the heuristic used to identify Lucent/Ascend capture files so that now your example capture is no longer identified as a Lucent/Ascend file but is correctly identified as a VMS TCPIPTRACE capture file. The fix will be available once 0.99.7 is released (or you can obtain or build a Wireshark development version: SVN #23152 or newer). If you have examples of other VMS TCPIPTRACE files which are mis-identified (eg: as an ERF file), please let us know. (Note that the code to process capture ERF files has very recently been changed so it's possible that the situation has already improved in this case). [For future reference: please use the Wireshark bugzilla (bugs.wireshark.org) to report problems and provide example capture files]. Thanks Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 23137: /trunk/ /trunk/asn1/: Makefile.am /trunk/: configure.in
[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 get the buildbots running again. However, I'm not really sure if the correct fix is that ans1/ansi-tcap directory is really supposed to be asn1/ansi_tcap to match asn1/ansi_map (given the comment on the previous SVN). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] tshark now using dumpcap - unix side currently don't work - need some help on the pipe handling
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 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gtk warning with current svn version of wireshark
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 wireshark. Fixed: SVN #22795 Thanks ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Windows make now checks for required libraries when top-level Makefile.nmake changed
(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 assumption made is that if the required package file is present then it has been installed. At the moment a missing package causes an error message which then terminates the build. If this is too strict or if there are other comments please let me know. Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Capture-Interface shows incorrect statistics
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 the differences between wpcap and regular pcap, where wpcap only sends delta statistics and pcap sends stats since the beginning of the session. snip I say the #ifdef Win32 (at line 247) is backwards and should be #ifndef instead! Yup! Just tested that on my Fedora box, and the stats look correct now! Sounds like a good catch ! 1. capture_if.c has changed a bit since 0.99.4 so I'd appreciate it if you could verify that the bug still exists in the latest SVN version (a quick look suggests that it may). See http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/gtk 2. If the bug still exists, please submit a bug report (bugzilla.wireshark.org) and attach a diff -u from the latest svn of the bug fix. The attachment should be marked as a patch and the request for review' flag should be checked. Thanks ! ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
