Re: [Wireshark-dev] Update official Windows build?
Hello Gerald, is there a reason to switch? If you mean just the installer then I think it's ok. But developing is much better with VC6, because it's much faster and more stable. As long as you don't need .Net there is nor real reason to switch in my opinion. The .Net Studio is just annoying. Also for installers there are better solutions than MSI Installer: NSIS: http://nsis.sourceforge.net/Main_Page Bitrock installer: http://bitrock.com/products_installbuilder_overview.html (Platform independent installer) Gerald Combs schrieb: The official Windows installers are still built using Visual Studio 6.0. I'd like to switch over to Visual C++ 2005 Express Edition before the next release. Is there any reason not to do this? ___ 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] WIN32 Compilation failed : tshark is not a validwin32 application
Ulf Lamping wrote: Graham Bloice wrote: CANDIA, Fabrice wrote: The nmake used is C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin and not the directory mentioned in the developper's guide (Visual studio dir). Is it normal ? The paths shown in the dev guide are for information only and refer to a VC 6.0 installation. Hi! I've updated the setup target output in the guide to reflect the MSVC 2005 EE version (so it better fits with the recommended MSVC version): cl: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/cl link: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/link nmake: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/nmake and also mentioned that the string depends on the compiler version used. The paths seem to be for a non-english, or at least a non-default installation, e.g. Programme. Don't know whether that will confuse folks? -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The war against warnings - mission accomplished!
Ulf Lamping wrote: Hi List! I would like to say a big THANK YOU to all the developers involved in the virtual warning fix party of recent days! :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) I'm very pleased to notice that my call for a warning free Wireshark was heard and was being answered ;-) The buildbot is now all green again, even with the treat warning as error setting in the buildbot makefiles. To quote myself: While I would take a look on the Win32 warnings, are the unix/linux developers willing to spend some time to remove warnings that don't appear on Win32 (or would this be a Win32 only show)? I'm pleased to notice that this wasn't a Win32 only show! As I did expect, some of the warnings have been fixed in a pragmatical way, e.g. disabled some warnings for the generated files by using a #pragma warning. However, this is pretty much ok for me and much better than what we had before. For most code files, a warning will emit an error now, making it much more obvious to see :-) So I guess we now have a much better base to prevent new warnings from leak into the sources. Our mission continues ... Thanks for rousing us into action. It had grated with me for a long time, but I didn't have your resolve, nor Sebastian's commitment. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Update official Windows build?
Ulf Lamping wrote: Gerald Combs wrote: The official Windows installers are still built using Visual Studio 6.0. I'd like to switch over to Visual C++ 2005 Express Edition before the next release. Is there any reason not to do this? Hi Gerald! I like the idea to switch to MSVC 2005 EE, e.g. this would make the config.nmake file consistent with the recommended compiler in the developer's guide. There seems to be repeating problems with the msvc runtime DLL msvcr80.dll, which doesn't appear when we use MSVC 6. As I don't have such problems and no good idea what the real cause of it is (maybe manifest files and/or compiler switch settings), I'm unsure if we will run into problems here. In addition, we'll need to pack the msvc redist package into the installer, which is obviously not open source - is there a problem with this? I guess not, as even the GPL addresses this as a operating system / compiler extension. I'm not sure about this step for two reasons, licencing restrictions, which we should check and installer bloat. Can we either provide a link to the redistributables (on the MS site) or a version of the installer without them. After all over time most machines will acquire them by other means. If we do the compiler update, do we want to put the redist exe into the Win32 libs dir on the subversion server, so it can be downloaded by the setup target? See above, e.g. a link to the MS download. Regards, ULFL P.S: If I find some time, I'll try to include the manifest files into the dll and exe files (I read somewhere on the web that this is possible). I guess the seperate manifest files are at least one cause of the problems mentioned above. This will also make the handling in NSIS, U3, ... packaging easier. I don't think it makes much difference. The loader will check for the manifest in both places and the assemblies identified in the manifest must be available. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] WIN32 Compilation failed : tshark is not a validwin32 application
Hi, In fact, It seem to be the call to C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd which change my paths. * Look at the result after the call to vcvars32.bat : C:\wiresharkcall C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat C:\wiresharkC:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32. bat Setting environment for using Microsoft Visual Studio 2005 x86 tools. C:\wiresharknmake -f Makefile.nmake verify_tools Microsoft (R) Program Maintenance Utility Version 8.00.50727.762 Copyright (C) Microsoft Corporation. Tous droits r'serv's. Checking for required applications: cl: /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN/cl link: /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN/link nmake: /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN/nmake bash: /usr/bin/bash bison: /usr/bin/bison flex: /usr/bin/flex env: /usr/bin/env grep: /usr/bin/grep /usr/bin/find: /usr/bin/find perl: /cygdrive/c/Opt/Perl/bin/perl C:/python24/python.exe: /cygdrive/c/python24/python.exe sed: /usr/bin/sed unzip: /usr/bin/unzip wget: /usr/bin/wget * And now, look at the result after the call to SetEnv.cmd : C:\wiresharkcall C:\Program Files\Microsoft Platform SDK for Windows Server 20 03 R2\SetEnv.Cmd Attempting to detect a Microsoft Visual Studio installation Targeting Windows XP 32 DEBUG C:\wiresharknmake -f Makefile.nmake verify_tools Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. Checking for required applications: cl: /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN/cl link: /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN/link nmake: /cygdrive/c/Program Files/Microsoft Platform SDK for Windows Serv er 2003 R2/Bin/nmake bash: /usr/bin/bash bison: /usr/bin/bison flex: /usr/bin/flex env: /usr/bin/env grep: /usr/bin/grep /usr/bin/find: /usr/bin/find perl: /cygdrive/c/Opt/Perl/bin/perl C:/python24/python.exe: /cygdrive/c/python24/python.exe sed: /usr/bin/sed unzip: /usr/bin/unzip wget: /usr/bin/wget Link to nmake changes between the 2 calls ! I tried to build after recall the first script (vcvars32.bat). I've got the same problem + problem with xcopy : if exist tshark.exe xcopy tshark.exe wireshark-gtk1 'xcopy' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes. NMAKE : fatal error U1077: 'if' : code retour '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : code retour '0x2' Stop. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Ulf Lamping Envoyé : vendredi 30 mars 2007 19:59 À : Developer support list for Wireshark Objet : Re: [Wireshark-dev] WIN32 Compilation failed : tshark is not a validwin32 application Graham Bloice wrote: CANDIA, Fabrice wrote: The nmake used is C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin and not the directory mentioned in the developper's guide (Visual studio dir). Is it normal ? The paths shown in the dev guide are for information only and refer to a VC 6.0 installation. Hi! I've updated the setup target output in the guide to reflect the MSVC 2005 EE version (so it better fits with the recommended MSVC version): cl: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/cl link: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/link nmake: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/nmake and also mentioned that the string depends on the compiler version used. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of security reasons. This
[Wireshark-dev] Parallel Redundancy Protocol (PRP) dissector
Hi all, This is a dissector for the Parallel Redundancy Protocol (PRP) defined in chapter 6 of the IEC 62439. PRP uses two independent networks in parallel and allows redundancy without switchovers. The protocol is sending Mac multicast messages with Ethertype 0x88fb. In addition to that it adds to every Ethernet frame a 4 byte trailer before the FCS. The trailer is detected by checking a size field and an identifier which are part of the trailer. Therefore, if the last 4 bytes of a frame match a correct trailer they get interpreted as a trailer, although it was probably not a real one. Best regards Sven Meier /// ||| ||| ///||| ///Sven Meier /// ||| ||| /// ||| /// Dipl.Ing. FH Informationstechnologie /// |||/// |||/// Entwicklungsingenieur IEEE 1588 /// ||/// ||/// Institute of Embedded Systems /// ||| |///|///Raum / Room InES TW 220 /// ||| /// /// Postfach 805 CH-8401 Winterthur Switzerland Zuercher Hochschule Winterthur Phone :+41 (0)52 267 70 58 (University of Applied Sciences)Fax :+41 (0)52 268 70 58 Mitglied der Zuercher Fachhochschule[EMAIL PROTECTED] prp_frames.cap Description: prp_frames.cap prp_patch.gz Description: prp_patch.gz ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Questions about IEEE 802.11 dissector
Hi. I have some questions about the ieee 802.11 dissector (and the wlancap dissector). I am capturing on Mac OS 10.4.9 with the latest wireshark svn on the wireless device wlt1. 1. When connected to an open network all packages have 4 trailing bytes which is not recognized correctly as a tagged parameter, and the packet is tagged malformed. Is this some sort of ICV for unprotected packages? See the attached capture ieee80211-clear.pcap. 2. When connected to a wep encrypted network the data package is marked as protected but the data part is not encrypted and the content is not dissected. Is this be because the mac os driver has decrypted the data before they are captured with wireshark? In this case I think the data should be dissected. See the attached capture ieee80211-wep.pcap, with a IPP package which is not dissected. 3. A question for the wlancap dissector: The SSI-type seems to have wrong endian, and the SSI-signal has a negative value. Should this be handled by the dissector? I do not know anything about the 802.11 protocol (yet), but I am willing to make a fix if I understand how to handle this :) -- Stig Bjørlykke ieee80211-clear.pcap Description: Binary data ieee80211-wep.pcap Description: Binary data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for bug 1377 that produces a modal dialog with garbage
This is a repost! Please consider this patch for Bug 1377. Regards, Peter 2007/3/30, Peter Johansson [EMAIL PROTECTED]: 2007/3/30, Jeff Morriss [EMAIL PROTECTED]: Peter Johansson wrote: I compiled Wireshark with HAVE_AIRPDCAP by mistake (since I do not have AirPcap). This leads to a runtime problem however. When choosing options from the Capture interfaces dialog, I receive a modal dialogue with an OK button with a textual description that is only garbage (uninitialized memory). The provided patch adds a new error - AIRPCAP_NOT_LOADED (2) code to the airpcap loader that also adds the text AirPcap was expected to be loaded but is not to the modal dialogue instead of the uninitialized string. Hmm, I think you found the problem of bug 1377: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1377 Having a quick look, though, I am a bit confused because it doesn't appear anybody ever allocates any space for 'err_str' before calling though maybe I'm missing it. Anyway I don't really have time to dig further for the moment. Another thing that needs a look is it appears that it's normal that AirPcap is compiled in (I didn't change my setup and my Windoze builds say with Airpcap) though in that case I'm not sure it should be complaining at all if it doesn't find an AirPcap device or whatever. After having read the description for bug 1377 I agree. This patch fixes that problem. err_str should not be allocated prior to calling get_airpcap_interface_list(err, err_str). err_str gets assigned a pointer to allocated memory (g_strdup) in the called function that gets freed when returning from the function. Thank you for having me review my changes once more. It turns out that my original change will make the code call g_free for the newly added statically allocated error description which would be a new error. I have attached a new set of files to be supplied as a solution for bug 1377. This time my changes allocate the error description using g_strdup just like the rest of the code, making it possible to call g_free upon return from the get_airpcap_interface_list(...) function. I was also wondering how to handle this case, should it not produce a dialogue at all? I am unsure. If a dialogue is not displayed, the user will never understand why the AirPcap devices do not show up if AirPcap is not loaded but Wireshark is compiled with support for it. On the other hand, I guess most users do not have AirPcap, which means that it would be annoying to get the dialogue every time when entering the options dialogue. Therefor I have changed the code in airpcap_loader.c even further to produce the modal dialogue stating that AirPcap is not loaded only once per Wireshark session. Hence it will not get displayed more than once unless the user restarts Wireshark. Unfortunately I had to make changes to more files than I would have wanted to be able to do this. Is that good enough? Regards, Peter ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Update official Windows build?
Newer versions of Visual C++ provide better overrun protection. Visual C++ 6.0 is also past the end of its supported life cycle: http://support.microsoft.com/lifecycle/?p1=3003 Gerhard Gappmeier wrote: Hello Gerald, is there a reason to switch? If you mean just the installer then I think it's ok. But developing is much better with VC6, because it's much faster and more stable. As long as you don't need .Net there is nor real reason to switch in my opinion. The .Net Studio is just annoying. Also for installers there are better solutions than MSI Installer: NSIS: http://nsis.sourceforge.net/Main_Page Bitrock installer: http://bitrock.com/products_installbuilder_overview.html (Platform independent installer) Gerald Combs schrieb: The official Windows installers are still built using Visual Studio 6.0. I'd like to switch over to Visual C++ 2005 Express Edition before the next release. Is there any reason not to do this? ___ 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
Re: [Wireshark-dev] Questions about IEEE 802.11 dissector
On Mon, Apr 02, 2007 at 03:56:59PM +0200, Stig Bj?rlykke wrote: 1. When connected to an open network all packages have 4 trailing bytes which is not recognized correctly as a tagged parameter, and the packet is tagged malformed. Is this some sort of ICV for unprotected packages? See the attached capture ieee80211-clear.pcap. Got to the preferences, protocols, ieee80211 and select that the frame is to be treated to include the FCS. That might help. 2. When connected to a wep encrypted network the data package is marked as protected but the data part is not encrypted and the content is not dissected. Is this be because the mac os driver has decrypted the data before they are captured with wireshark? In this case I think the data should be dissected. See the attached capture ieee80211-wep.pcap, with a IPP package which is not dissected. IIRC, that is configureable as well. Ignore the protection bit. 3. A question for the wlancap dissector: The SSI-type seems to have wrong endian, and the SSI-signal has a negative value. Should this be handled by the dissector? I do not know anything about the 802.11 protocol (yet), but I am willing to make a fix if I understand how to handle this :) Need to check. 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] Questions about IEEE 802.11 dissector
On Mon, Apr 02, 2007 at 05:51:40PM +0200, Stig Bj?rlykke wrote: IIRC, that is configureable as well. Ignore the protection bit. This does not work as expected, because dissection of the WEP parameters are omitted and the dissection of LLC starts too early. You are right. Maybe you can add yet another prefs flag that says Ignore the protection bit with IV and change the existing one to Ignore the protection bit without IV? 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] New dissector for OpcUa protocol
Gerhard Gappmeier wrote: Hello, because I got no feedback on my last submit I'm trying it again now. I attached the new protocol dissector as follows: 1.) The patch for the makefile changes 2.) The new sources are in the attached zip file. (renamed to zip_ to avoid mail filtering) 3.) A sample capture file to test the dissector. Please take a look at sources if they are ok and add them to the repository. Or give me some feedback if I need to change something. Hi Gerhard! Sorry, that I didn't respond, but I'm currently pretty busy in another project :-( Some things I've noticed while doing a quick view: a lot of the code seems to be autogenerated (as the comments suggest) It might make sense to include the sources and the build process instead of the intermediate files (if the amount of code/tools to build the files seems reasonable). The reason: When people start to hack your code (e.g. to remove warnings on a compiler you don't even think about), you'll might get into annoying trouble with merging code the next time you've update the upcua files. The example capture file seems pretty short regarding the code size. Having some more examples will make fuzz-testing more efficient - can you provide some more diverse to test? Did you fuzz-test the code yourself? A wiki page about upcua would be nice :-) I'll try to have a deeper look into your code next weekend, but I cannot promise ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New dissector for OpcUa protocol
Hi Ulf Ulf Lamping schrieb: Hi Gerhard! Sorry, that I didn't respond, but I'm currently pretty busy in another project :-( np Some things I've noticed while doing a quick view: a lot of the code seems to be autogenerated (as the comments suggest) It might make sense to include the sources and the build process instead of the intermediate files (if the amount of code/tools to build the files seems reasonable). The reason: When people start to hack your code (e.g. to remove warnings on a compiler you don't even think about), you'll might get into annoying trouble with merging code the next time you've update the upcua files. I'm sorry, but I cannot give you the sources of the code generator, because they are owned by the OPC Foundation. I only extended the existing code generator to produce also wireshark code. It's .Net based so I guess you don't want to have it anyway ;-) I already tested the plugin with VC6 and GCC3.4.6 to compile error and warning free. Don't hesitate to contact me if you find some issues with other compilers. The example capture file seems pretty short regarding the code size. Having some more examples will make fuzz-testing more efficient - can you provide some more diverse to test? Did you fuzz-test the code yourself? I'll send you a bigger capture file as soon as possible. A wiki page about upcua would be nice :-) NP, I can do that too. Meanwhile you can take a look at http://www.ascolab.com/index.php?file=ualang=en There is some information about it. I'll try to have a deeper look into your code next weekend, but I cannot promise ... Thanks in advance. I just want to get it integrated as soon as possible. 1.) It's easier to maintain for me (no more two repos to sync) 2.) Some UA developers are already waiting for it and I want to avoid that somebody else does the same work twice. 3.) It will be less work when OpcUa is finished. regards, Gerhard. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21303: /trunk/wiretap/ /trunk/wiretap/: k12.c
On Apr 2, 2007, at 3:17 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21303 User: lego Date: 2007/04/02 10:17 PM Log: There are odd packet records in k15 generated files where the interface record does not match any given one. I noticed that these records have the first byte changed so When a lookup fails mask the byte and lookup again. Are there any cases where the upper byte of the ID in question is significant? (I.e., might that be a 24-bit ID plus a separate 8-bit field?) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21303: /trunk/wiretap/ /trunk/wiretap/: k12.c
On 4/3/07, Guy Harris [EMAIL PROTECTED] wrote: On Apr 2, 2007, at 3:17 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21303 User: lego Date: 2007/04/02 10:17 PM Log: There are odd packet records in k15 generated files where the interface record does not match any given one. I noticed that these records have the first byte changed so When a lookup fails mask the byte and lookup again. Are there any cases where the upper byte of the ID in question is significant? It is significant for most files I have. That's why I lookup twice instead of just using the masked id as key. (I.e., might that be a 24-bit ID plus a separate 8-bit field?) I thought that myself i thus I coded it... then the regression test showed me that it wasn't that. -- 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] Questions about IEEE 802.11 dissector
On Apr 2, 2007, at 6:56 AM, Stig Bjørlykke wrote: 3. A question for the wlancap dissector: The SSI-type seems to have wrong endian, What type of AirPort adapter do you have? I think at least some of them are using (yay!) radiotap headers rather than AVS headers, although some older ones might've used AVS headers. There might be a driver bug wherein the SSI type isn't big-endian, although with older adapters that'd arguably be somewhat stoopid, given that 1) the AVS header spec says All multibyte fields of the capture header are in network byte order. (go to http://mail.shaftnet.org, click on Development, click on Version Control, click on trunk, click on doc, click on capturefrm.txt, select the atest revision (1795, as of now); 2) older adapters are on older Macs, which have big-endian PowerPC processors; 3) Ethereal/Wireshark, as is appropriate, interprets them as big- endian, so little-endian fields in an AVS header would've shown up pretty quickly when looking at those captures. and the SSI-signal has a negative value. To quote the AVS header spec: 4.11 ssi_signal The ssi_signal field contains the signal strength value reported by the WLAN device for this frame. Note that this is a signed quantity and if the ssi_type value is dBm that the value may be negative. ___ 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 05:01:06PM +0200, Sebastien Tandel wrote:
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.
Did you already commit these changes? I don't see them in my svn tree.
We're still compiling epan/dissectors with a ton of warnings from
auto-generated dissectors on Unix.
There is only one warning left from the regular dissectors and I'm not
quite sure how to fix it properly:
packet-diameter.c: In function `dissect_avps':
packet-diameter.c:2057: warning: comparison between signed and unsigned
The relevant code is:
if ( data.secs = NTP_TIME_DIFF){
Where data is a nstime_t (and secs is a time_t). NTP_TIME_DIFF is
defined as 2208988800UL since it's too large to be a signed int/long.
time_t is typically a signed value, but isn't guaranteed to be from what
I've read. Making the value LL (long long) is only officially supported
in c99, not the c90 that we code to. Any ideas on how to fix this in a
portable fashion?
Steve
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On Apr 2, 2007, at 4:13 PM, Stephen Fisher wrote:
We're still compiling epan/dissectors with a ton of warnings from
auto-generated dissectors on Unix.
How many of them are coming from asn2wrs-generated dissectors?
asn2wrs is, for some reason, generating a lot of dissect_ functions
that aren't being called.
I think it might also be generating some hf_ values that aren't being
used, although I might be thinking of some other set of generated
dissectors with that problem.
There is only one warning left from the regular dissectors and I'm not
quite sure how to fix it properly:
packet-diameter.c: In function `dissect_avps':
packet-diameter.c:2057: warning: comparison between signed and
unsigned
The relevant code is:
if ( data.secs = NTP_TIME_DIFF){
Where data is a nstime_t (and secs is a time_t). NTP_TIME_DIFF is
defined as 2208988800UL since it's too large to be a signed int/long.
We don't support platforms on which int is shorter than 32 bits, so
2208988800U *should* suffice, unless there's something I'm missing.
time_t is typically a signed value, but isn't guaranteed to be from
what
I've read.
According to RFC 2030 (which defines the NTP time stamp format also
used in Diameter), the NTP time stamp is unsigned. Therefore, the
seconds field of an NTP time stamp should be fetched into a guint32_t
value.
Then, the relevant code would be
if (ntp_timestamp_secs = NTP_TIME_DIFF) {
which is comparing two unsigned values.
Inside that branch of the if, I'd do
data.secs = ntp_timestamp_secs - NTP_TIME_DIFF;
with data being the nstime_t.
Making the value LL (long long) is only officially supported
in c99, not the c90 that we code to. Any ideas on how to fix this
in a
portable fashion?
64-bit integer support isn't needed for this, but as a general FYI on
64-bit integer support in Wireshark, gint64_t or guint64_t are
supported on all the platforms we support (we no longer support
platforms where the compiler and formatted-output routines don't
support 64-bit integral data types).
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] RFC 2508 Dissector
On Sun, Mar 25, 2007 at 08:36:35PM -0700, Donald White wrote: In resolving this problem, I developed a partial RFC 2508 dissector which I added to packet-ppp.c. The code is attached. Thus, I submit it to the list in its current state. I cannot even provide the capture from which I worked as test data. I am willing to do further development if someone can provide further examples of packets from this protocol. Thanks for your contribution! I've committed your changes as SVN revision 21304 with a minor change in a few places that won't affect normal operation of the code: I changed match_strval() to val_to_str() (see doc/README.developer for usage notes - match_strval() may return a NULL that we don't want and cause a crash if it runs across unexpected data). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] pragma warning
On Mon, Apr 02, 2007 at 04:40:05PM -0700, Guy Harris wrote:
On Apr 2, 2007, at 4:13 PM, Stephen Fisher wrote:
We're still compiling epan/dissectors with a ton of warnings from
auto-generated dissectors on Unix.
How many of them are coming from asn2wrs-generated dissectors?
asn2wrs is, for some reason, generating a lot of dissect_ functions
that aren't being called.
I think it might also be generating some hf_ values that aren't being
used, although I might be thinking of some other set of generated
dissectors with that problem.
Assuming that they have either template, -fn, or .cnf in their names
when compiling, almost all of the remaining warnings come from the ASN1
dissectors. There are 3,265 warnings from these files. All but about
20 are defined but not used warnings (only 3 of which include hf_ in
the name - the rest start with dissect_).
There is only one warning left from the regular dissectors and I'm not
quite sure how to fix it properly:
packet-diameter.c: In function `dissect_avps':
packet-diameter.c:2057: warning: comparison between signed and
unsigned
The relevant code is:
if ( data.secs = NTP_TIME_DIFF){
Where data is a nstime_t (and secs is a time_t). NTP_TIME_DIFF is
defined as 2208988800UL since it's too large to be a signed int/long.
We don't support platforms on which int is shorter than 32 bits, so
2208988800U *should* suffice, unless there's something I'm missing.
Good point, I have changed that.
According to RFC 2030 (which defines the NTP time stamp format also
used in Diameter), the NTP time stamp is unsigned. Therefore, the
seconds field of an NTP time stamp should be fetched into a guint32_t
value.
Then, the relevant code would be
if (ntp_timestamp_secs = NTP_TIME_DIFF) {
which is comparing two unsigned values.
Inside that branch of the if, I'd do
data.secs = ntp_timestamp_secs - NTP_TIME_DIFF;
with data being the nstime_t.
Thanks! No more warning :). I'll commit it with my next batch of
warnings fixes - some more have crept in since I upgraded from gcc 4.0
to 4.1.
Steve
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Fix for JXTA dissector bug
Mike Duigou wrote: The enclosed patch corrects a problem where jxta elements were being added to the protocol tree for segments that did not contain complete jxta frames. This patch ensures that the jxta proto elements are only added those the segments that end a complete, assembled jxta frame. The patch has been fuzz tested with a broad selection of jxta captures and ran successfully overnight for over 4000 iterations. Applied as svn revision 21305. Thank you. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
