Re: [Wireshark-dev] [Patch] pragma warning
Gisle Vanem wrote: Graham Bloice [EMAIL PROTECTED] wrote: Gisle Vanem wrote: The #pragma warning() statements are MSVC specific. So embed them inside #ifdef _MSC_VER. I always thought unrecognised #pragma directives were ignored. I take it that MinGw barfs on them in some way? MingW ignores them, but with a warning. I thought we should strive to reduce the number of warnings. Hence my patch. Ignore and issues a warning don't quite mesh in my dictionary, but now I understand what's up I support your solution. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. On 3/28/07, Graham Bloice [EMAIL PROTECTED] wrote: Gisle Vanem wrote: Graham Bloice [EMAIL PROTECTED] wrote: Gisle Vanem wrote: The #pragma warning() statements are MSVC specific. So embed them inside #ifdef _MSC_VER. I always thought unrecognised #pragma directives were ignored. I take it that MinGw barfs on them in some way? MingW ignores them, but with a warning. I thought we should strive to reduce the number of warnings. Hence my patch. Ignore and issues a warning don't quite mesh in my dictionary, but now I understand what's up I support your solution. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] GIOP plugin compilation warning
On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow compilation to proceed due to a warning emitted when compiling packet-parlay.c. The warning was that the number of lines exceed an internal limit (65536) and no more line number info would be issued. The only fixes that I can see for this is to either split the file somehow or add a #pragma warning, but as this is a generated file both those may be a little tricky. Shall I just commit the makefile change for the moment? P.S. I compile under VC 6.0 just for historical reasons as my ws dev env has been that way for years. I have VS 2005, so moving isn't an issue for me, but should we consider dropping support for earlier VC versions. This might clean up a few things. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Regarding downloading source
Hi , I am having a Windows XP m/c. I hv installed MSVC ExpEd and PSDK also. I am getting the foll. error when I try to download source through Tortoise SVN. Error: PROPFIND request failed on '/wireshark/trunk' Error: PROPFIND of '/wireshark/trunk': could not connect to server (http://anonsvn.wireshark.org) What could be the error? Pls guide ---Manju SASKEN BUSINESS DISCLAIMER - This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding downloading source
Manjunath P wrote: Hi , I am having a Windows XP m/c. I hv installed MSVC ExpEd and PSDK also. I am getting the foll. error when I try to download source through Tortoise SVN. Error: PROPFIND request failed on '/wireshark/trunk' Error: PROPFIND of '/wireshark/trunk': could not connect to server (http://anonsvn.wireshark.org) What could be the error? Pls guide I guess you are behind a (restrictive) proxy/firewall. Subversion uses some advanced HTTP mechanisms to connect from client to server, which might be restricted by the proxy/firewall. Try to get a tarball/zip, as described in the developers guide. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GIOP plugin compilation warning
Graham Bloice wrote: On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow compilation to proceed due to a warning emitted when compiling packet-parlay.c. The warning was that the number of lines exceed an internal limit (65536) and no more line number info would be issued. The only fixes that I can see for this is to either split the file somehow or add a #pragma warning, but as this is a generated file both those may be a little tricky. ... or add /wd4049 to the Makefile.nmake CFLAGS, to ignore especially this warning. Shall I just commit the makefile change for the moment? I would prefer to follow Ronnies approach to have different lists for the generated files (if the Makefile CFLAGS problem I've mentioned can be solved). However, the giop plugin is a special case here, as all files are generated for this dissector (when I remember correct). So adding /wd4049 is the way to go IMHO - this way the warnings won't show up while compiling. P.S. I compile under VC 6.0 just for historical reasons as my ws dev env has been that way for years. I have VS 2005, so moving isn't an issue for me, but should we consider dropping support for earlier VC versions. This might clean up a few things. I'm unsure if there's enough clean up to justify all developers to force an update ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On 3/28/07, Ulf Lamping [EMAIL PROTECTED] wrote: ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll As far as i remember, the manual process of make copy_files and not having the asn compilation part of the build process was really just to wait doing so until we were sure asn2wrs was mature enough. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] FYI: Status of gcc warnings in epan/dissectors
Stephen Fisher wrote: On Wed, Mar 28, 2007 at 03:04:27PM +0800, Jeff Morriss wrote: Stephen Fisher wrote: Almost all of the warnings I've fixed so far are sign mismatches between guint8* and (g)char* :(. 552 of the 795 remaining warnings outside of the .cnf files are this problem. Is casting away signed and unsigned really the way to go with that? Well, since (g)char defaults to unsigned on most platforms, it is usually the same as a guint8. So it isn't really a mismatch; I think Well, both glib-1.2 and 2.0 on Linux and Solaris say: typedef char gchar; typedef unsigned char guchar; and it looks like you recently changed things like: const char *dn; [...] - format_text(dn, strlen(dn))); + format_text(dn, strlen((guchar*)dn))); but strlen() usually takes a (const) char*. That makes no sense to me. Maybe the compiler is wrong? gcc 4.0 is warning about it for portability to platforms that don't have (g)char unsigned by default (which are they?). The problem is that we use guint8 all over the place, but the standard C and GLib functions use char. So there is a lot of going back and forth in the code. The implicit conversion is already being done and the code works, I'm just making it explicit with a cast. I'm open to other ideas if you have any other than getting rid of our use of guint8 :). That's why I suggested turning on -Wno-pointer-sign (because I don't have a better idea and I don't particularly like the idea of just casting them all away). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On 3/28/07, ronnie sahlberg [EMAIL PROTECTED] wrote: On 3/28/07, Ulf Lamping [EMAIL PROTECTED] wrote: ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. Full Ack, These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll Wouldn't be better to move trunk/asn1 into trunk/epan/dissectors like the pidl ones? As far as i remember, the manual process of make copy_files and not having the asn compilation part of the build process was really just to wait doing so until we were sure asn2wrs was mature enough. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GIOP plugin compilation warning
Ulf Lamping wrote: Graham Bloice wrote: On MSVC 6.0 + PDSK, I had to remove the Wx from CFLAGS to allow compilation to proceed due to a warning emitted when compiling packet-parlay.c. The warning was that the number of lines exceed an internal limit (65536) and no more line number info would be issued. The only fixes that I can see for this is to either split the file somehow or add a #pragma warning, but as this is a generated file both those may be a little tricky. ... or add /wd4049 to the Makefile.nmake CFLAGS, to ignore especially this warning. No go I'm afraid. MS VC 6.0 (AFAICT) doesn't allow you to specify warnings to ignore from the command line. It's all or nothing. Shall I just commit the makefile change for the moment? I would prefer to follow Ronnies approach to have different lists for the generated files (if the Makefile CFLAGS problem I've mentioned can be solved). However, the giop plugin is a special case here, as all files are generated for this dissector (when I remember correct). So adding /wd4049 is the way to go IMHO - this way the warnings won't show up while compiling. As that doesn't work and this issue is breaking the buildbot, shall I just commit my earlier suggestion? P.S. I compile under VC 6.0 just for historical reasons as my ws dev env has been that way for years. I have VS 2005, so moving isn't an issue for me, but should we consider dropping support for earlier VC versions. This might clean up a few things. I'm unsure if there's enough clean up to justify all developers to force an update ... It might remove a few queries to the list, and as VS 2005 Express is free, I can't think anyone in the right mind would attempt to start WS dev on VC 6.0. I suppose the main issue would be the buildbot. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On Wed, Mar 28, 2007 at 08:21:24AM +, ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Which warnings do you have in mind specifically? Why do you think they can't be avoided? Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. I think they should just be generated from their real sources on each build, thus removing the need to manually rebuild them at all. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. dito. ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] (Fwd) Re: Patch to AMQP dissector
Ronnie, Why do you change all function argumentns to use _U_ ? _U_ is only used to mark a parameter as unused so that the compiler will not emit any warnings parameter foo is never used. You only set this _U_ for arguments that are indeed never used inside the function to suppress these kinds of compiler warnings. Can you resubmit the patch after removing and reviewing these _U_ changes? The problem here is that we are generating the code. In case we want to remove obsolete _U_s we would have to do generation in 2 passes (1st pass collects all the variables that will be actually used in the code, 2nd pass generates the code). Is the issue critical for you? Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding downloading source
I have special Downloading Rights in my office and my m/c is not behind any firewall. I downloaded a tortoise SVN( recent SVN 1.4.3 win32 ). When I try to do svn --versionon my cmd line , I get an error The application has failed to start because cygdb-4.2.dll was not found. Re installing the application may fix this problem. After this, I tried to repair with installer package. Later I uninstalled the present client and re-installed the windows installer package again from the Tortoise website but again found the same problem(given below). I read sections 3.3.2 and 3.3.3 and 3.3.4 of Developer's guide. How can I proceed further? Pls advice -Regards Manju - Original Message - From: Ulf Lamping [EMAIL PROTECTED] To: Manjunath P [EMAIL PROTECTED]; Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Wednesday, March 28, 2007 3:44 PM Subject: Re: [Wireshark-dev] Regarding downloading source Manjunath P wrote: Hi , I am having a Windows XP m/c. I hv installed MSVC ExpEd and PSDK also. I am getting the foll. error when I try to download source through Tortoise SVN. Error: PROPFIND request failed on '/wireshark/trunk' Error: PROPFIND of '/wireshark/trunk': could not connect to server (http://anonsvn.wireshark.org) What could be the error? Pls guide I guess you are behind a (restrictive) proxy/firewall. Subversion uses some advanced HTTP mechanisms to connect from client to server, which might be restricted by the proxy/firewall. Try to get a tarball/zip, as described in the developers guide. Regards, ULFL SASKEN BUSINESS DISCLAIMER - This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding downloading source
Manjunath P wrote: I have special Downloading Rights in my office and my m/c is not behind any firewall. I downloaded a tortoise SVN( recent SVN 1.4.3 win32 ). When I try to do svn --versionon my cmd line , I get an error The application has failed to start because cygdb-4.2.dll was not found. Re installing the application may fix this problem. After this, I tried to repair with installer package. Later I uninstalled the present client and re-installed the windows installer package again from the Tortoise website but again found the same problem(given below). I read sections 3.3.2 and 3.3.3 and 3.3.4 of Developer's guide. How can I proceed further? Pls advice The dll error was probably because your command line is picking up a cygwin version of svn. Tortoise does *not* provide a command line version of svn. It does provide some command line tools, but they aren't the same as standard svn. Using TortoiseSVN, open an Explorer window, right click any directory or drive and choose SVN Checkout... from the context menu. It might be in the TortoiseSVN sub menu. In the resulting dialog, enter the correct url (http://anonsvn.wireshark.org/wireshark/trunk) in the URL of repository field, and a suitable local directory in the Checkout directory field. Ensure the two check boxes are cleared and select the HEAD radio button. Click OK. After a suitable period of time you should have the source tree on your local hard disk. Continue as per the developers guide. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] packet-amqp.c
Permissions have not been correctly set on packet-amqp.c Regards, Sebastien Tandel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll Wouldn't be the register_all_protocols() function problematic? Regards, Sebastien Tandel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On 3/28/07, Sebastien Tandel [EMAIL PROTECTED] wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll Wouldn't be the register_all_protocols() function problematic? We could create a plugin directory with all its paraphernalia and have the asn1 dissectors be loaded like a plugin. But still the best thing would be to have the asn1 generated dissectors inepan/dissectors and have them built from the Makefile. For the warnings we could have asn2wrs.py prepend the #pragma for unused static function right bellow the signature to the generated code (that's an ugly fix but I do not find a feasible way to have asn2wrs not creating the unused functions). The rest is monkey business: just to add the generated targets to the Makefile[s] like this: packet-h248.c: ../../asn1/h248/packet-h248-template.c \ ../../asn1/h248/packet-h248-template.h \ ../../asn1/h248/h248.cnf \ ../../asn1/h248/h248v3.asn [TAB](cd ../../asn1/h248 make copy_files ) packet-h248.h: packet-h248.c Luis Regards, Sebastien Tandel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
Hi Ulf, Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. I made it partly for the Unix side. (Makefile.common and Makefile.am affected). The Makefile is, in fact, building now four libraries : - asn dissectors : libasndissectors.la - pidl dissectors : libpidldissectors.la - normal dissectors : libdissectors.la *and* libcleandissectors.la. I separated it in two libraries temporarily. The source files used to build libcleandissectors.la do not generate warning anymore and the -Werror is used to compile them. If we patch a dissector and it doesn't generate warning anymore, we have to move the filename dissector from DISSECTOR_SRC to CLEAN_DISSECTOR_SRC in epan/dissectors/Makefile.common. You can define specific cflags with, for example, libpidldissectors_la_CFLAGS. The problem is that I really don't know how to do this for Makefile.nmake. Maybe the attached patch will give you some ideas ;) Regards, Sebastien Tandel sources-per-dissector-type.diff.gz Description: application/gzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Protocol statistics
Sorry for the repost. The wiki doesn't mention putting PATCH in the subject line and I am new here. I have attached a patch for the protocol hierarchy statistics (-z io, phs). It's a simple update from a 32 bit unsigned integer to a 64 bit version. I am a little uncertain about the portability of the new include but I tied to follow how it was done else where in the code. Thanks, D. Todd Vollmer proto_stats_64bit.gz Description: GNU Zip compressed data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Warnings in asn2wrs generated files
Hi, Without checking - I think the PDU lacked something in the signature or something such as that but I'll try to find the time to have another look. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Kukosa, Tomas Skickat: den 28 mars 2007 17:19 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Warnings in asn2wrs generated files Hi, if those choice statemens are only dummy the better way is to define those types as PDU in .cnf file. Then -F option could be removed. Regards, Tomas Mailcode: NdD2sKHg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman (AL/EAB) Sent: Wednesday, March 28, 2007 2:30 PM To: Developer support list for Wireshark Subject: [Wireshark-dev] Warnings in asn2wrs generated files Hi, I had a quick look at the warnings for NBAP some of the unused function warnings are due To the dirty way hf fields and stuff are auto generated by creating dummy statements for Opcodes and elements to hand craft them or remove the dummy statements after copying the auto generated stuff to the template file seems like owerkill or? Other parts of the warnings are problems with asn2wrs it self or how it's used. Tomas kukosa wrote: those field functions are created bacuse of -F option is used. It is used because some of field functions are called from nbap template. field functions are not called from generated code now. It was changed few months ago when I change PER helper funcions from field oriented to type oriented. I'm not sure how to fix those... Best regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer Sent: den 28 mars 2007 14:13 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Patch] pragma warning On Wed, Mar 28, 2007 at 08:21:24AM +, ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Which warnings do you have in mind specifically? Why do you think they can't be avoided? Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. I think they should just be generated from their real sources on each build, thus removing the need to manually rebuild them at all. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. dito. ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Which takes precedence - plug-ins or built-in dissectors?
Mea culpa if this is a FAQ but I couldn't find reference to this anywhere. What happens if I add a plug-in for a dissector that already is statically linked into Wireshark? Does the plug-in take precedence or will there be a conflict? Cheers, Bryan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] packet-amqp.c
On Wed, Mar 28, 2007 at 03:55:38PM +0200, Sebastien Tandel wrote: Permissions have not been correctly set on packet-amqp.c I assume you are referring to the svn:executable property. I have removed this as SVN revision 21247. Thanks for pointing it out! Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Discrepancies between summary view and details view - rpc dissector
Hello all, I am developing an RPC based dissector and I am getting odd results when I run it. It correctly identifies the protocol (based on RPC program and procedure numbers) for a couple of frames and then begins to display another RPC protocol (different program number, same procedure number). Interestingly, the information displayed below in the details window displays the correct RPC protocol whilst the summary window does not. My dissector uses packet-rpc and, at this point, I am not manually updating the summary or tree view contents. I am simply letting packet-rpc do the heavy lifting of creating the display information. Any thoughts on where things may be going wrong? I'm ready to begin a liberal sprinkling of g_print() statements in packet-rpc to see what is happening. Cheers, Bryan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Which takes precedence - plug-ins or built-in dissectors?
Bryan Miller wrote: What happens if I add a plug-in for a dissector that already is statically linked into Wireshark? Does the plug-in take precedence or will there be a conflict? There is no guarantee of any particular outcome. It depends on the mechanism the dissectors use to register themselves, and the way those mechanisms happen to be implemented in any particular version of Wireshark. If you have improvements for a dissector, you should replace that dissector directly, and send us the improvements so we can put them into the main Wireshark release. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] use Global Title as address in SCCP/SUA?
In case of SUA, wouldn't this mean pinfo-src and pinfo-dst would no longer have the IP end-points of the SCTP association? Is yes, is that desirable? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: Would it be correct to add an AT_SS7_GT to the address types and have sccp/sua setting the GTs as pinfo-src pinfo-dst ??? Isn't the global title an actual (transport) address? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] use Global Title as address in SCCP/SUA?
Hmmm... OK, I have yet had to use the M3UA dissector, didn't know that. Anyway, in SUA/SCCP too, it is possible for the CgPA and CdPA to be only PC-SSN. So, if SCCP/SUA does set the transport address as GT, it should also set it to point code if only point code is available. Perhaps the others have something to say about this too. I am curious though, how do you think it will help? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: There still be the IP addresses in net_src/net_dst. It would be much like M3UA does that replaces ip src and ip dst by the opc and dpc (which I do not doubt it is ok). What I wonder about is whether the GT is an address or should it be just taken as a port on a certain address. On 3/28/07, Abhik Sarkar [EMAIL PROTECTED] wrote: In case of SUA, wouldn't this mean pinfo-src and pinfo-dst would no longer have the IP end-points of the SCTP association? Is yes, is that desirable? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: Would it be correct to add an AT_SS7_GT to the address types and have sccp/sua setting the GTs as pinfo-src pinfo-dst ??? Isn't the global title an actual (transport) address? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] FYI: Status of gcc warnings in epan/dissectors
On Wed, Mar 28, 2007 at 06:45:01PM +0800, Jeff Morriss wrote: That's why I suggested turning on -Wno-pointer-sign (because I don't have a better idea and I don't particularly like the idea of just casting them all away). Ok, I can go ahead and remove my casts and add the -Wno-pointer-sign as long as no one objects. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Wireshark 0.99.5 make rpm-package problems on RHEL3
While attempting to build a Wireshark .rpm on a Red Hat Enterprise Linux system (Taroon, update 8), I ran into 2 problems: 1) epan/crypt/Makefile.common does not get copied to packaging/rpm/BUILD/wireshark-0.99.5/epan/crypt/. To quickly circumvent that problem, I manually copied the file once the directory was created. A hack, I know, but good enough for now ... except I also ran into this next problem, which I don't know how to remedy: 2) Ran into an undefined reference problem. Here's the relevant output: gcc -DINET6 -D_U_=__attribute__((unused)) -Wall -Wpointer-arith -W -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/local/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/rpm -DINET6 -O2 -g -pipe -march=i386 -mcpu=i686 -Dlinux -I/usr/include/rpm -I. -I/usr/include/net-snmp -I/usr/kerberos/include -o .libs/wireshark capture-pcap-util-unix.o capture_errs.o capture-pcap-util.o capture_stop_conditions.o capture_ui_utils.o cfile.o clopts_common.o conditions.o disabled_protos.o packet-range.o print.o ps.o pcapio.o ringbuffer.o timestats.o util.o version_info.o airpcap_loader.o alert_box.o capture.o capture_info.o capture_opts.o capture_sync.o color_filters.o file.o fileset.o filters.o g711.o merge.o proto_hier_stats.o sync_pipe_write.o summary.o tempfile.o ..libs/wiresharkS.o -Wl,--export-dynamic -pthread -Wl,--export-dynamic -L/usr/local/lib -L/usr/lib gtk/libui.a codecs/libcodec.a wiretap/.libs/libwiretap.so epan/.libs/libwireshark.so -L/usr/kerberos/lib /usr/lib/libnetsnmp.so -lelf -lcrypto -lpcap -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -lkrb5 -lk5crypto -lcom_err -lz /usr/bin/ld: warning: libcom_err.so.3, needed by /usr/lib/libcrypto.so, may conflict with libcom_err.so.2 gtk/libui.a(ssl-dlg.o)(.text+0x1f3e): In function `follow_find_button_cb': /home/username/wireshark-0.99.5/packaging/rpm/BUILD/wireshark-0.99.5/gtk /ssl-dlg.c:861: undefined reference to `gtk_text_buffer_select_range' gtk/libui.a(follow_dlg.o)(.text+0x2431): In function `follow_find_button_cb': /home/username/wireshark-0.99.5/packaging/rpm/BUILD/wireshark-0.99.5/gtk /follow_dlg.c:991: undefined reference to `gtk_text_buffer_select_range' collect2: ld returned 1 exit status make[3]: *** [wireshark] Error 1 I have successfully built 0.99.5 rpm's for systems running Fedora Core 4 and Fedora Core 6, so I'm not sure why the Makefile.common isn't getting copied or the undefined reference is happening on this system. Does anyone have any ideas? Thanks in advance, Chris Maynard - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Which takes precedence - plug-ins or built-in dissectors?
Guy, I am in agreement and that is what I anticipate doing with the bulk of my work. I this particular case the protocol is proprietary and will likely not become public until 2008. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris Sent: Wednesday, March 28, 2007 10:32 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Which takes precedence - plug-ins or built-in dissectors? Bryan Miller wrote: What happens if I add a plug-in for a dissector that already is statically linked into Wireshark? Does the plug-in take precedence or will there be a conflict? There is no guarantee of any particular outcome. It depends on the mechanism the dissectors use to register themselves, and the way those mechanisms happen to be implemented in any particular version of Wireshark. If you have improvements for a dissector, you should replace that dissector directly, and send us the improvements so we can put them into the main Wireshark release. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Warnings in asn2wrs generated files
Hi,
Looking again the basic problem is asn2wrs not handling constructs like:
--InitiatingMessage ::= SEQUENCE {
-- procedureID
NBAP-ELEMENTARY-PROCEDURE.procedureID ({NBAP-ELEMENTARY-PROCEDURES}),
-- criticality
NBAP-ELEMENTARY-PROCEDURE.criticality
([EMAIL PROTECTED]),
-- messageDiscriminator
NBAP-ELEMENTARY-PROCEDURE.messageDiscriminator({NBAP-ELEMENTARY-PROCEDURES}
[EMAIL PROTECTED]),
-- transactionID TransactionID,
-- value
NBAP-ELEMENTARY-PROCEDURE.InitiatingMessage([EMAIL PROTECTED]
rocedureID})
--}
:
--AuditResponse-IEs NBAP-PROTOCOL-IES ::= {
-- { ID id-End-Of-Audit-Sequence-Indicator
CRITICALITY ignore TYPE End-Of-Audit-Sequence-Indicator
PRESENCE mandatory }|
-- { ID id-Cell-InformationList-AuditRsp
CRITICALITY ignore TYPE Cell-InformationList-AuditRsp
PRESENCE optional }|
-- { ID id-CCP-InformationList-AuditRsp
CRITICALITY ignore TYPE CCP-InformationList-AuditRsp
PRESENCE optional }|
-- CCP (Communication Control Port) --
-- { ID id-Local-Cell-InformationList-AuditRsp
CRITICALITY ignore TYPE Local-Cell-InformationList-AuditRsp
PRESENCE optional }|
-- { ID id-Local-Cell-Group-InformationList-AuditRsp CRITICALITY
ignore TYPE Local-Cell-Group-InformationList-AuditRsp PRESENCE optional }|
-- { ID id-CriticalityDiagnostics
CRITICALITY ignore TYPE CriticalityDiagnostics
PRESENCE optional },
-- ...
--}
--AuditResponse-Extensions NBAP-PROTOCOL-EXTENSION ::= {
-- { ID id-Power-Local-Cell-Group-InformationList-AuditRsp CRITICALITY
ignore EXTENSION Power-Local-Cell-Group-InformationList-AuditRsp
PRESENCE optional },
-- ...
--}
--Cell-InformationList-AuditRsp ::= SEQUENCE (SIZE (1..maxCellinNodeB)) OF
ProtocolIE-Single-Container {{ Cell-InformationItemIE-AuditRsp}}
Cell-InformationList-AuditRsp ::= SEQUENCE (SIZE (1..256)) OF
ProtocolIE-Single-Container
The current workarounds leads to a lot of unused code creating warnings.
I see no good solution currently.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Anders Broman
Skickat: den 28 mars 2007 18:11
Till: 'Developer support list for Wireshark'
Ämne: Re: [Wireshark-dev] Warnings in asn2wrs generated files
Hi,
Without checking - I think the PDU lacked something in the signature or
something such as that but I'll try to find the time to have another look.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Kukosa, Tomas
Skickat: den 28 mars 2007 17:19
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] Warnings in asn2wrs generated files
Hi,
if those choice statemens are only dummy
the better way is to define those types as PDU in .cnf file.
Then -F option could be removed.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Wednesday, March 28, 2007 2:30 PM
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Warnings in asn2wrs generated files
Hi,
I had a quick look at the warnings for NBAP some of the unused
function warnings are due
To the dirty way hf fields and stuff are auto generated by creating
dummy statements for
Opcodes and elements to hand craft them or remove the dummy statements
after copying the auto generated stuff to the template file seems like
owerkill or?
Other parts of the warnings are problems with asn2wrs it self or how
it's used.
Tomas kukosa wrote:
those field functions are created bacuse of -F option is used.
It is used because some of field functions are called from nbap
template.
field functions are not called from generated code now.
It was changed few months ago when I change PER helper funcions from
field oriented to type oriented.
I'm not sure how to fix those...
Best regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent: den 28 mars 2007 14:13
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Patch] pragma warning
On Wed, Mar 28, 2007 at 08:21:24AM +, ronnie sahlberg wrote:
I dont think it is really realistic to have all autogenerated files
always compile without any warnings.
Which warnings do you have in mind specifically? Why do you think they
can't be avoided?
Maybe we should instead split Makefile.common up into three parts :
First part : normal dissectors
Second part : ANS2WRS generated dissectors which take extra compile
time flags and definitions to suppress artefacts from the compiler.
I think they should just be generated from their real sources on each
build, thus removing the need to manually rebuild them at all.
Third part : PIDL generated dissectors that once again take extra
compile parameters and definitions.
dito.
ciao
Joerg
--
Joerg Mayer [EMAIL
Re: [Wireshark-dev] Wireshark 0.99.5 make rpm-package problems on RHEL3
On Wed, Mar 28, 2007 at 04:07:34PM -0400, Maynard, Chris wrote: 2) Ran into an undefined reference problem. Here's the relevant output: gtk/libui.a(ssl-dlg.o)(.text+0x1f3e): In function `follow_find_button_cb': /home/username/wireshark-0.99.5/packaging/rpm/BUILD/wireshark-0.99.5/gtk /ssl-dlg.c:861: undefined reference to `gtk_text_buffer_select_range' gtk/libui.a(follow_dlg.o)(.text+0x2431): In function `follow_find_button_cb': /home/username/wireshark-0.99.5/packaging/rpm/BUILD/wireshark-0.99.5/gtk /follow_dlg.c:991: undefined reference to `gtk_text_buffer_select_range' collect2: ld returned 1 exit status make[3]: *** [wireshark] Error 1 I've never tried building a Wireshark RPM unfortunately. However, since I wrote the code referenced above, your message caught my eye. What version of GTK are you using on this system? The gtk_text_buffer_select_range() function is available in GTK 2.4 and above. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] use Global Title as address in SCCP/SUA?
After a deeper analysis of some captures I have I've got to the conclusion that it is not a good idea. The GT is something different that what i believed it to be. I was considering a way to group together TCAP transactions taking into account that for some of those I've seen responses coming from a different opc than the dpc of the begin, now after a detailed analysis of those traces I noticed that this was due to a (unavoidable) misbehavior of the Flow Graph where the same SCTP packet carried more M3UA packets destined to different PCs and being pinfo-src set to the opc of the second M3UA packet the flow graph have the arrow coming from the wrong OPC. (That's a problem caused by the 1:1 relation between frame and packet wireshark assumes) Other than that I found MAP requests with two GT (from mobile's IMSI to HLR's) whose response to has different GTs (HLR's to VLR's), thus invalidating any assumption I made about the GT being determinant in establishing to which TCAP transaction does the packet belong that was the issue that had me coming with the (demential) idea. Luis On 3/28/07, Abhik Sarkar [EMAIL PROTECTED] wrote: Hmmm... OK, I have yet had to use the M3UA dissector, didn't know that. Anyway, in SUA/SCCP too, it is possible for the CgPA and CdPA to be only PC-SSN. So, if SCCP/SUA does set the transport address as GT, it should also set it to point code if only point code is available. Perhaps the others have something to say about this too. I am curious though, how do you think it will help? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: There still be the IP addresses in net_src/net_dst. It would be much like M3UA does that replaces ip src and ip dst by the opc and dpc (which I do not doubt it is ok). What I wonder about is whether the GT is an address or should it be just taken as a port on a certain address. On 3/28/07, Abhik Sarkar [EMAIL PROTECTED] wrote: In case of SUA, wouldn't this mean pinfo-src and pinfo-dst would no longer have the IP end-points of the SCTP association? Is yes, is that desirable? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: Would it be correct to add an AT_SS7_GT to the address types and have sccp/sua setting the GTs as pinfo-src pinfo-dst ??? Isn't the global title an actual (transport) address? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch to AMQP dissector
checked in On 3/27/07, Martin Sustrik [EMAIL PROTECTED] wrote: Hi Ronnie, here's a patch to AMQP dissector. The only change is that when there are seceral AMQP frames in single TCP packet, all of them are referred in the info column. Can you check it in? Thanks. Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] JXTA dissector memory leak?
The dissector file packet-jxta.c has a comment saying that an allocation
is a memory leak:
if (NULL != found_addr) {
found_addr-type = AT_URI;
found_addr-len = strlen(*current_token);
/* FIXME 20050605 bondolo THIS ALLOCATION IS A MEMORY LEAK! */
found_addr-data = g_strdup(*current_token);
}
Anyone familiar enough with this dissector to fix it easily?
Steve
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Which takes precedence - plug-ins or built-in dissectors?
On Mar 28, 2007, at 2:28 PM, Bryan Miller wrote: Guy, I am in agreement and that is what I anticipate doing with the bulk of my work. I this particular case the protocol is proprietary and will likely not become public until 2008. So is this an extension to an existing protocol, or a completely new protocol? (A new ONC RPC-based protocol or a new DCE RPC-based protocol is a new protocol, not an extension to an existing protocol.) If it's a completely new protocol, there's no dissector already statically linked into Wireshark. If it's an extension to an existing protocol, you'll have to modify the existing dissector and build a private version of Wireshark for internal use. (Anybody outside your organization to whom you give the modified version can ask for the source, and you have to provide it to them, and they can then give the source away to anybody they want.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] JXTA dissector memory leak?
On Wed, 28.Mar.07 16:41:59 -0700, Stephen Fisher wrote:
The dissector file packet-jxta.c has a comment saying that an allocation
is a memory leak:
if (NULL != found_addr) {
found_addr-type = AT_URI;
found_addr-len = strlen(*current_token);
/* FIXME 20050605 bondolo THIS ALLOCATION IS A MEMORY LEAK! */
found_addr-data = g_strdup(*current_token);
}
Anyone familiar enough with this dissector to fix it easily?
Should be enough just to change g_strdup to ep_strdup or se_strdup.
See README.malloc for more details.
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21256: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-winreg.c packet-dcerpc-winreg.h /trunk/epan/dissectors/pidl/: winreg.idl
:-) Well those files are not supposed to be manually edited/modified anyway. I can change PIDL to always emit #ifdef _MSC_VER #pragma warning(disable:4005) #pragma warning(disable:4013) #endif at the head of the file. Are there any other pramgas you want it to emit as well? On 3/29/07, Ulf Lamping [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21256 User: sahlberg Date: 2007/03/29 12:26 AM Log: update winreg to the latest idl Directory: /trunk/epan/dissectors/ ChangesPath Action +221 -18 packet-dcerpc-winreg.cModified +1 -0 packet-dcerpc-winreg.hModified Directory: /trunk/epan/dissectors/pidl/ ChangesPath Action +26 -11winreg.idlModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits Hi Ronnie! You've repeatedly breaking the Win32 buildbot by removing the handcrafted #pragma warning(disable) I've added to fix warnings of the generated files. Unless we have implemented the real fix you've mentioned, namely splitting the sources into generated and normal sources with different CFLAGS, could you add the #pragma changes to the generated files before checking them in? We are currently working against each other ;-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] FYI: Native Mac OS X port of GTK+ on the horizon ...
Hi List! Just stumbled over Gtk+ for Mac OS X: http://developer.imendio.com/projects/gtk-macosx which is a native port of GTK+ - so you won't need an X server. The screenshots suggests to be aimed towards bringing a native The Gimp to the MAC. The project seems to be in early beta (or maybe still alpha) state, maybe a bit too early to use it with Wireshark. I'm not using a MAC myself, but the interested MAC developers might keep an eye on it :-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] FYI: Wireshark code metrics on ohloh.net
Hi List! I've just stumbled over ohloh.net, which do code metrics for various open source projects. The Wireshark related pages are at: http://www.ohloh.net/projects/3805 I found it interesting to look at the Contributors tab ... Unfortunately, the metrics only took into account the code changes after our switch from Ethereal to Wireshark, so some of the metrics are quite misleading Short source control history and 17,667 LOC are probably not quite complete ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21256: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-winreg.c packet-dcerpc-winreg.h /trunk/epan/dissectors/pidl/: winreg.idl
ronnie sahlberg wrote: :-) Well those files are not supposed to be manually edited/modified anyway. I know, I know, that's the reason of the header comment, but I couldn't find another way :-( I can change PIDL to always emit #ifdef _MSC_VER #pragma warning(disable:4005) #pragma warning(disable:4013) #endif at the head of the file. Sounds like a good approach. In the meantime the MSVC vs. MinGW problems have been fixed, so there shouldn't be further changes required with the #ifdef. Are there any other pramgas you want it to emit as well? A find over all files showed the following pragmas in generated files: PIDL: #ifdef _MSC_VER /* disable: warning C4101: 'xy' : unreferenced local variable */ #pragma warning(disable:4101) /* disable: warning C4018: '' : signed/unsigned mismatch */ #pragma warning(disable:4018) /* disable: warning C4013: 'xy' undefined; assuming extern returning int */ #pragma warning(disable:4013) /* disable: warning C4005: 'xx' : macro redefinition */ #pragma warning(disable:4005) #endif Asn1 (only in rrlp): #ifdef _MSC_VER /* disable: warning C4146: unary minus operator applied to unsigned type, result still unsigned */ #pragma warning(disable:4146) #endif In my opinion: 4101: only annoying, pragma should be added to PIDL generation 4018: only annoying, pragma should be added to PIDL generation 4013: unclean code, should be fixed (BTW: As you've fixed some things, this might simply no longer be necessary :-) 4005: unclean code, but I don't know how this could be fixed, see below 4146: buggy code, needs to be fixed (uses a negative constant out of the valid range)! An explanation of 4005: The winreg IDL file defines e.g. REG_NONE, which is already defined in the windows header files, which is obviously a bad thing. The only clean way I can see would be to add a prefix (e.g. WS_) to the generated symbols. Unfortunately I don't know if this will raise other problems in the generated code (e.g. constant strings might be a problem). So the way to go: - adding 4101, 4018 as a #pragma to the code - these warnings can be safely ignored - fixing 4013, 4146 - these warnings actually indicate unclean generated code so they shouldn't be just ignored - fix 4005 if possible, otherwise add it as a #pragma to the code - might be fixed later, but still a pending time bomb if definitions are actually *different* Please add the corresponding comments to the pragmas, as remembering the meaning of the warning numbers is cumbersome. Unfortunately, I don't know enough about the generated files to fix it myself, so I must beg you to put some work on it ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Broken Record - Release tag
Bryant Eastham wrote: Gerald Combs wrote: /trunk-0.99.2 was copied from /trunk last week. Once the 0.99.2 release is made it will be moved to /releases/wireshark-0.99.2. Some time in the future we'll start over again by copying /trunk to /trunk-0.99.3. Sorry to sound like a broken record. Is there going to be a release tag for 0.99.5? My understanding from Gerald’s message on 13 Jul 2006 was that each new release would get a /releases tag. Done. Sorry for the delay. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding downloading source
Hi Graham, I followed each and every step faithfully as given in Developer's guide , but still I am not able to get the source and I get the same error. I download source from http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz separately(without SVN), untarred it through cygwin, and then tried to put the source into SVN( by specifying the untarred file directory in the checkout file option ). I got the error Error: Unable to open an ra_local session to URL I hv even mailed to the dev guide of Tortoise but no reply from them Ur advice is very essential Pls help ---Manju - Original Message - From: Graham Bloice [EMAIL PROTECTED] To: Manjunath P [EMAIL PROTECTED]; Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Wednesday, March 28, 2007 6:50 PM Subject: Re: [Wireshark-dev] Regarding downloading source Manjunath P wrote: I have special Downloading Rights in my office and my m/c is not behind any firewall. I downloaded a tortoise SVN( recent SVN 1.4.3 win32 ). When I try to do svn --versionon my cmd line , I get an error The application has failed to start because cygdb-4.2.dll was not found. Re installing the application may fix this problem. After this, I tried to repair with installer package. Later I uninstalled the present client and re-installed the windows installer package again from the Tortoise website but again found the same problem(given below). I read sections 3.3.2 and 3.3.3 and 3.3.4 of Developer's guide. How can I proceed further? Pls advice The dll error was probably because your command line is picking up a cygwin version of svn. Tortoise does *not* provide a command line version of svn. It does provide some command line tools, but they aren't the same as standard svn. Using TortoiseSVN, open an Explorer window, right click any directory or drive and choose SVN Checkout... from the context menu. It might be in the TortoiseSVN sub menu. In the resulting dialog, enter the correct url (http://anonsvn.wireshark.org/wireshark/trunk) in the URL of repository field, and a suitable local directory in the Checkout directory field. Ensure the two check boxes are cleared and select the HEAD radio button. Click OK. After a suitable period of time you should have the source tree on your local hard disk. Continue as per the developers guide. -- Regards, Graham Bloice SASKEN BUSINESS DISCLAIMER - This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
