Re: [Wireshark-dev] Git mirror issues
Hi, On 11/07/2013 11:59 PM, Gerald Combs wrote: A while back Erwin Rol noticed that tags weren't showing up in the git mirror[1]. I finally had a chance to look into the issue in detail and as it turns out some transactions were failing due to a stale lock file. After cleaning up the lock file and running 'git fsck' the missing tags have appeared. I created a new SVN→Git export from scratch for validation. It is available at http://code.wireshark.org/git/wireshark-rebase-2013-11-07 Its history differs quite a bit from the main git mirror, but this appears to be due to changes in the identity map (SVN userernames to Git email addresses) which were made over the past year. The file and directory contents appear to be the same. I compared a fresh SVN checkout with a clone of the old and new git mirrors and they were all identical except for the VCS metainformation. It would be nice to replace the current mirror with a fresh export but it looks like that might cause problems. If I run the following: git clone http://code.wireshark.org/git/wireshark ws-git-test cd ws-git-test git remote set-url origin \ http://code.wireshark.org/git/wireshark-rebase-2013-11-07 Then 'git pull' produces a lot of errors but 'git pull --rebase' seems to work fine. If I *did* freshen the git mirror, would having to rebase cause any undue problems for any git users? Theoretically rebasing private branches should not cause big headaches to users since the content is the same as the commit they are rebasing from, but if they forked off from their private brances those branches have to be rebased as well and this is not handled automatically by git. Not to mention the merges across private branches. If we stay with the current git mirror we only have 102 commits of 3 (4?) people which list only usernames and not real life names: rbalint@chaos:~/projects/wireshark.git$ git log --format=%an origin/master | grep -v ' ' | wc -l 106 rbalint@chaos:~/projects/wireshark.git$ git log --format=%an origin/master | grep -v ' ' | sort | uniq anonsvn hannes pascal ruengeler I see very little value in fixing the author names retroactively but I see much bigger potential pain in replacing the git commits. Speaking of the Git repo it would be nice to have the tags signed by your key to make attacks on the repo content harder. Currently both the anonymous svn and git repos allow MITM attacks against people using them. Cheers, Balint signature.asc Description: OpenPGP digital signature ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Is Python Still Considered Optional for the Build Process? What Should the Minimum Version Be?
On 07/31/2012 09:59 AM, Pascal Quantin wrote: Le 31 juil. 2012 à 09:43, Anders Broman anders.bro...@ericsson.com mailto:anders.bro...@ericsson.com a écrit : Hi, Others have to comment on whether we require python or not but it would be nice if you attached your script to a bug report so we could have a look at it and have a record of it. I think it should be OK to require python 2.6 as the lowest supported level to make things simpler. Best regards Anders Hi, just for information the Linux development machine I have at work (Debian Lenny) is still packaging python 2.5 by default (unfortunately). It would be great if we could keep compatibility with older machines. Regards, Pascal. Hi Pascal, Lenny is oldstable and is not supported even by the Debian Project itself. Please upgrade to Squeeze. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Fuzz testing with valgrind
Hi Evan, On 07/26/2012 04:44 AM, Evan Huus wrote: On Wed, Jul 25, 2012 at 7:03 PM, Martin Mathieson martin.r.mathie...@googlemail.com wrote: On Wed, Jul 25, 2012 at 6:12 PM, Evan Huuseapa...@gmail.com wrote: I've been playing around in my head for a while now with the idea of running fuzz tests under valgrind. I notice the fuzz-test script already sets a bunch of environment variables for memory checking, so I'm not sure if valgrind would really add anything. How extensive are the memory checks turned on by the fuzz-test script? Would valgrind be a useful addition, or would it be mostly redundant? Thanks, Evan I'm not sure either, but out of the 3 problems reported by valgrind that I just fixed: - 1 was writing outside of allocated data (which the canary checks may have picked up on) - 2 were reading/displaying/branching-based-upon uninitialized data (which I don't expect other types of checks would spot) Martin Basic support added in revision 44024, so it's there if people want to use it. I don't know if it would be worth turning on for the build-bot, as it does slow down the check considerably, but it will probably catch a few more errors. I think it is a good idea. Maybe we could have a fuzz-test run with Valgrind once a week. The memory corruption I fixed recently has been identified using Valgrind as well. Cheers, Balint Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Expected ABI breakage with 1.6.8
Hi, Please do not release 1.6.8 in its current state or bump library version to 2.0.0 for libwireshark. Using 1.1.8 is misleading as 1.6.8 breaks the ABI: http://rbalint.cs.bme.hu/ws-ABI-1.6.7-1.6.8/libwireshark/abi_compat_report.html Please run the following command before release to verify ABI compatibility in the git repo: git checkout master-1.6 git checkout master -- tools/git-compare-abis.sh tools/git-compare-abis.sh ./autogen.sh ./configure make -j3 make dumpabi Thanks, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/11/2012 06:04 PM, Gerald Combs wrote: On 1/10/12 2:29 PM, Gerald Combs wrote: On 1/10/12 2:09 PM, Balint Reczey wrote: diff --git a/debian/wireshark-common.files b/debian/wireshark-common.files index 41341be..4403c04 100644 --- a/debian/wireshark-common.files +++ b/debian/wireshark-common.files @@ -5,7 +5,7 @@ /usr/bin/text2pcap /usr/bin/rawshark /usr/lib/wireshark/libwireshark.so.1 -/usr/lib/wireshark/libwireshark.so.1.1.0 +/usr/lib/wireshark/libwireshark.so.1.1.1 /usr/lib/wireshark/libwiretap.so.1 /usr/lib/wireshark/libwiretap.so.1.0.1 /usr/lib/wireshark/libwsutil.so.1 Unfortunately I can't commit it now. It's a little late for that now at any rate. :) I modified make-version.pl to update the libwireshark and libwiretap revision numbers in accordance with the libtool documentation. I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. Running the ACC script and updating the version based on the result (possibly using a script) would give the right new version. Cheers, Balint commit baada8699e2365b3de312bf5f8825710dee34aff Author: Gerald Combs ger...@wireshark.org Date: Wed Jan 11 17:00:56 2012 + Have make-version.pl -v update the library revision information for libwireshark and libwiretap. The source code for each changes with every release and according to the libtool documentation we should increment the revision number. (wsutil hardly ever changes so we don't update it here.) svn path=/trunk-1.6/; revision=40436 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/11/2012 08:37 AM, Harper wrote: Balint Reczeybalint.rec...@ericsson.com wrote in news:4f09f7b3.2000...@ericsson.com: Hi, I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642). The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries. :-) There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133. Does this affect only ZigBee? Do I need to recompile plugins that have compiled with 1.6.0? Since our plugins are not ZigBee related I assume it's not necessary to compile and distribute them. The ABI stability should allow using these plugins for all 1.6.x version. So if there is an ABI change can do you describe it? I have updated the ABI compatibility report here: http://rbalint.cs.bme.hu/ws-ABI-1.6.4-1.6.5/ If you don't use ZigBee related #define-s, you will be fine. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/12/2012 06:20 PM, Gerald Combs wrote: On 1/12/12 9:06 AM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update [ hit send too soon. ] We update the code in epan and wiretap in every release, which means the revision number should be incremented for libwireshark and libwiretap, correct? I can imagine a release without any change in those libraries, this is why I wrote that it may not be the proper approach, but you are correct, if there are only internal changes in both libs, we should update the revision for both. Since we can change the ABI as well I propose running ACC before the release and manually updating the versions properly or creating a script which updates the version numbers properly according to ACC. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/12/2012 06:06 PM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update Running the ACC script and updating the version based on the result (possibly using a script) would give the right new version. Is ACC available for Windows or OS X? I'd rather keep make-version.pl cross-platform if possible. BTW, what version of ACC do you have installed? All of my Ubuntu machines have 1.6 which seems to support a completely different set of options than the ones in the dumpabi makefile target. The home page at http://ispras.linux-foundation.org/index.php/ABI_compliance_checker has been down since September. I use ABI compliance checker 1.21.12 Unfortunately the Debian package is outdated, but there is a packaged 1.96.1-1, waiting for sponsor: http://packages.qa.debian.org/a/abi-compliance-checker.html I'll give a try to 1.96.1-1. Since we don't version dll-s and I don't know anything about the OS X builds I'm okay with supporting only currently suppported OS-s. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
Hi Gerald, On 01/09/2012 11:44 PM, Gerald Combs wrote: On 1/9/12 1:39 PM, Balint Reczey wrote: Hi Gerald, On 01/09/2012 07:56 PM, Gerald Combs wrote: The ABI change is the result of fixing a bug. If we revert the change the ZigBee ZCL dissector will revert back to its previous broken behavior and packet-zbee-zcl.h will have incorrect definitions. Shouldn't we change the libwireshark version from 2:0:1 to 2:1:0 instead? I don't know how important the ZigBee change is, but generally bumping the major version of a library is something I would avoid. After releasing 1.8.0 we should definitely avoid it because we will probably bump the major version in 1.8.0 and bumping it in 1.6.x would result a collision. As a not too nice solution we can release 1.6.4 with a known ABI breakage what is still better than breaking the ABI more like we did in the past. Oops. That should be 2:0:1 to 2:1:1. That is, increment the revision only. That at least provides a hint that something changed. I meant the proper change in the library version would be bumping the major version for the #define change since the ABI is not backward compatible. There would be an alternate way, redefining the constants in the C file in the backported fix. This way we could keep the API unchanged and fix the bug for stock Wireshark. I would prefer not breaking the ABI and not releasing the ZigBee fix because this would be a clean solution and users can always download the automated builds to get the latest correct dissector. Users *can't* always download the latest build. Some environments are tightly controlled and standardize on the latest stable or a specific I think IT's (and a plugin maintainer's) general expectation is that we don't introduce big changes in stable branches and don't make non backward-compatible changes in stable branches and this is why they approve only latest stable releases. If we make non backward-compatible changes we surprise them in a not too funny way. release, period. In one extreme case I received an email from someone trying to use 0.99.7 on Windows 7 because his IT group hadn't validated newer releases of Wireshark. I'm not sure if we could help all people with insane constraints due to IT. I'd rather fix a dissector bug and break the API. In this case there are presumably more people analyzing ZigBee traffic than writing ZigBee dissector code. It would not be a problem, if the dissector were not written in the current way an we had a well defined external API not including the ZigBee header file. If we had a well defined API, we could concentrate on keeping only this stable. I would like to help the creation of a well-defined API but I'm less and less convinced that ABI stability is something which the project would care about. Generally I would prefer releasing only stability/security/build fixes in the stable branch to minimize the probability of introducing new bugs and incompatibilities. This is one of the drawbacks of our release cycle. If we don't backport fixes people have to live with dissector bugs for a year or more. There will be a group of people who want latest and an others using stable, so I think our release cycle is fine from this POV. Especially since the quality of automated builds is high, IMO. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
Hi Gerald, On 01/09/2012 11:44 PM, Gerald Combs wrote: On 1/9/12 1:39 PM, Balint Reczey wrote: Hi Gerald, On 01/09/2012 07:56 PM, Gerald Combs wrote: The ABI change is the result of fixing a bug. If we revert the change the ZigBee ZCL dissector will revert back to its previous broken behavior and packet-zbee-zcl.h will have incorrect definitions. Shouldn't we change the libwireshark version from 2:0:1 to 2:1:0 instead? I don't know how important the ZigBee change is, but generally bumping the major version of a library is something I would avoid. After releasing 1.8.0 we should definitely avoid it because we will probably bump the major version in 1.8.0 and bumping it in 1.6.x would result a collision. As a not too nice solution we can release 1.6.4 with a known ABI breakage what is still better than breaking the ABI more like we did in the past. Oops. That should be 2:0:1 to 2:1:1. That is, increment the revision only. That at least provides a hint that something changed. The debian-package target needs this patch, too: diff --git a/debian/wireshark-common.files b/debian/wireshark-common.files index 41341be..4403c04 100644 --- a/debian/wireshark-common.files +++ b/debian/wireshark-common.files @@ -5,7 +5,7 @@ /usr/bin/text2pcap /usr/bin/rawshark /usr/lib/wireshark/libwireshark.so.1 -/usr/lib/wireshark/libwireshark.so.1.1.0 +/usr/lib/wireshark/libwireshark.so.1.1.1 /usr/lib/wireshark/libwiretap.so.1 /usr/lib/wireshark/libwiretap.so.1.0.1 /usr/lib/wireshark/libwsutil.so.1 Unfortunately I can't commit it now. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
Hi Gerald, On 01/09/2012 07:56 PM, Gerald Combs wrote: On 1/8/12 12:08 PM, Balint Reczey wrote: Hi, I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642). The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries. :-) There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133. The ABI change is the result of fixing a bug. If we revert the change the ZigBee ZCL dissector will revert back to its previous broken behavior and packet-zbee-zcl.h will have incorrect definitions. Shouldn't we change the libwireshark version from 2:0:1 to 2:1:0 instead? I don't know how important the ZigBee change is, but generally bumping the major version of a library is something I would avoid. After releasing 1.8.0 we should definitely avoid it because we will probably bump the major version in 1.8.0 and bumping it in 1.6.x would result a collision. As a not too nice solution we can release 1.6.4 with a known ABI breakage what is still better than breaking the ABI more like we did in the past. I would prefer not breaking the ABI and not releasing the ZigBee fix because this would be a clean solution and users can always download the automated builds to get the latest correct dissector. Generally I would prefer releasing only stability/security/build fixes in the stable branch to minimize the probability of introducing new bugs and incompatibilities. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
Hi Bill, On 01/09/2012 08:34 PM, Bill Meier wrote: On 1/9/2012 1:56 PM, Gerald Combs wrote: On 1/8/12 12:08 PM, Balint Reczey wrote: Hi, I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642). The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries. :-) There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133. The ABI change is the result of fixing a bug. If we revert the change the ZigBee ZCL dissector will revert back to its previous broken behavior and packet-zbee-zcl.h will have incorrect definitions. Shouldn't we change the libwireshark version from 2:0:1 to 2:1:0 instead? FYI: 1. In the recent SVN #40414 1.6 changes, there were some changes in packet-ssl-utils.h (which undoubtedly would be considered an ABI change) done as part of a fixing a bug. (r40221) I think we could keep the original ABI function with the leak an provide a new one which does not leak an use that in the backported fix. This way the lib could be kept backward compatible and at least Wireshark would not leak. 2. There was also a (trivial) change to remove a typedef from packet-nfs.h (which I made while fixing an unrelated bug). I certainly can remove this particular change if necessary. I think we could revert this change. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
Hi, I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642). The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries. :-) There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133. Cheers, Balint [1]: http://rbalint.cs.bme.hu/ws-ABI-1.6.4-1.6.5/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] misleading description on Wireshark Download page
On 11/06/2011 12:25 AM, Chris Maynard wrote: Balint Reczeybalint.reczey@... writes: We already provide automated development builds at ftp://ftp.wireshark.org/automated/ . I think those are enough. Distributions are also free to package svn snapshots. That's true, but those automated builds aren't announced on the wireshark- mailing list(s) when they're made, nor do they appear center-stage on http://www.wireshark.org/ with the other other stable releases, so I suspect that there are a lot of users out there that aren't even aware of them. I think we could emphasize their availability on the front page. The other thing about the development release is that it's sort of an indication from the development team that, yeah, this is a development release and you might encounter some problems with it, but we believe it's at least in reasonable enough shape that you should find it useful for most purposes. Contrast that with automated releases which could contain features in just about any state of development. Unless you're following along closely to wireshark-dev, wireshark-bugs, etc., you probably don't have a good sense of which automated release is likely OK to use and which you should probably avoid. When we used to announce development releases we could point users to a set of automated build known to work. Well, I don't have any particularly strong opinion on this matter either way, but I'm just presenting some counter-arguments as food for thought. I think we are used to releasing the development builds, but I don't think they were used widely and we could replace them with announcing interesting automated builds. Cheers, Balint - Chris ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] misleading description on Wireshark Download page
On 11/05/2011 03:44 AM, Chris Maynard wrote: Balint Reczeybalint.reczey@... writes: Why not release a new dev release (based on trunk) to each new release of 1.6.x/1.4.x ? Why should we? The svn repository is public. Perhaps so more people could try the development releases without requiring them to build it themselves? We already provide automated development builds at ftp://ftp.wireshark.org/automated/ . I think those are enough. Distributions are also free to package svn snapshots. But that said, I'm not sure a 1-1 development-to-stable release schedule is necessarily the right way to go either since there may be features in progress on the development branch that aren't ready for prime-time when a new stable release is made. If the repository were not open, I would release a few development snapshots shortly before branching off a new stable branch. In our case instead of releasing development snapshots I would announce the approaching opening of the new stable branch. Interested parties could then look into the current state and submit patches before the new branch opens. Cheers, Balint - Chris ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark 1.4.10 is now available
On 11/01/2011 08:44 PM, Gerald Combs wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm proud to announce the release of Wireshark 1.4.10. Digests wireshark-1.4.10.tar.bz2: 20611930 bytes MD5(wireshark-1.4.10.tar.bz2) = d688 827a 9b99 083f d995 2c4f c0f3 410c SHA1(wireshark-1.4.10.tar.bz2) = ae7c 560c bb8f 87d4 64ec f56b a4d7 2f1c d542 f3a6 RIPEMD160(wireshark-1.4.10.tar.bz2) = c84f 56ca b1ca 5e08 bf02 30c0 6aad 726c d49e df9d Hi Gerald, Could we please return to the original hash format without the spaces? I used to use grep, but now I also have to remove the spaces. I don't see any advantage of breaking up the hash values. Thanks, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] misleading description on Wireshark Download page
On 11/02/2011 08:19 PM, Alexis La Goutte wrote: On Wed, Nov 2, 2011 at 6:07 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: Excellent question. We were holding off on making a development release over the summer until the multi-interface capture support settled down. Is there any reason to delay 1.7.0 at this point? On 11/2/11 12:51 AM, Dirk Jagdmann wrote: So today somebody at my company wanted to check the latest Wireshark. Looking at http://www.wireshark.org/download.html he read the description literally which said that the 1.6.0rc2 is the latest development release. So he figured it might be newer than the fresh 1.6.3 release... I think we can remove that old release candidate, or alternatively put a daily/weekly tarball of trunk on that page. Hi, Why not release a new dev release (based on trunk) to each new release of 1.6.x/1.4.x ? Why should we? The svn repository is public. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 39487: /trunk/debian/ /trunk/debian/: control
On 10/20/2011 07:29 PM, Guy Harris wrote: On Oct 20, 2011, at 8:30 AM, Stephen Fisher wrote: I don't know how the debian things work in the Wireshark source, but I assume that this minimum GTK requirement will need to be bumped every time it is bumped in configure.in. Should we put a comment in configure.in to remind us to change it in debian/control as well? Could debian/control be generated from a debian/control.in file by the configure script, with the script filling in the minimum GTK+ version? Since debian/control is read by dpkg-buildpackage _before_ calling configure would not go that way. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
On 10/07/2011 04:26 PM, Jeff Morriss wrote: Balint Reczey wrote: On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. How? (At the moment I'm looking only at automake, but I suppose eventually Windows and CMake must be considered.) I was thinking about using build-stamps and inter-directory dependencies without implementing a full non-recursive make system, but I have to investigate the current situation to be sure. In the meantime maybe we could simply speed up the asn2wrs script, but I haven't done any profiling on it yet. Right now I'm getting errors even with -j1. :-( Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Brutal patch to build with GTK 3.0
On 08/19/2011 02:01 AM, Stephen Fisher wrote: On Thu, Aug 18, 2011 at 05:55:43PM -0600, Stephen Fisher wrote: On Thu, Aug 18, 2011 at 06:31:56PM +0200, Anders Broman wrote: I don't mind if some one commits the patch, but I think you have to build with the new UI MANAGER on GTK 3.0 as there is quite a bit of factory stuff left to fix. Unless we want to break the remaining statistics functions until fixed. My GTK 3.0 box is at work so I can't try GTK 3.0 builds until tomorrow. I committed it as r38612 since it doesn't seem to cause problems when compiling with GTK 2. The new UI manager code is enabled by default when building with GTK 3 now. ... on second thought, it isn't all contained within #if statements for GTK 3 builds only, so it could affect GTK 2 builds as well. I backed it out as of r38613. Could we please commit it after changing //-s to #ifdef-s? Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
Hi, On 08/05/2011 04:01 AM, Jeff Morriss wrote: On 08/04/2011 07:35 PM, Tony Trinh wrote: Isn't Python also necessary for the Wireshark Python API? (It's disabled by default, unlike the Lua API.) Yes, but here we're talking about whether we have/should have a (hard) requirement to have Python in order to compile Wireshark (from the source tarball, which is often different than building from SVN). Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 38296: /trunk/gtk/ /trunk/gtk/: sctp_graph_dlg.c
On 08/01/2011 12:07 AM, Joerg Mayer wrote: On Sun, Jul 31, 2011 at 09:54:48PM +, etx...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=38296 User: etxrab Date: 2011/07/31 02:54 PM Log: Try to fix: cc1: warnings being treated as errors ../../gtk/sctp_graph_dlg.c: In function ???draw_tsn_graph???: ../../gtk/sctp_graph_dlg.c:511: error: ???cr??? may be used uninitialized in this function ... Just a curious question: Is this a compiler bug? It didn't complain on my system and the code looked right to me. I think cairo_destroy(cr); should be followed by cr = NULL; Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] upcoming Wireshark 1.7.0
Hi, Why do we want to release 1.7.0 in this very early stage of it's development? Automatic builds are usable for experiments. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] make debian-package failing
Hi Peter, If you don't want anything special from trunk, the official Debian packages should work fine: http://packages.qa.debian.org/w/wireshark.html Others, I propose following the official Debian packages more closely. I can sync them, but I don't want to go against others in the project. If you know about something that is broken in the official packages or something you don't want to see in the upstream packages, please tell me now. Cheers, Balint On 06/17/2011 05:14 PM, Peter Bond wrote: Hi all - I'm trying to put together a local build of Wireshark; I've downloaded the 1.6.0 release source and built (and run) OK, but it is falling over during the package creation. A bit of a surprise, as I've done it with previous releases OK. Here's the commands issued to build: svn co http://anonsvn.wireshark.org/wireshark/releases/wireshark-1.6.0 wireshark cd wireshark ./autogen.sh ; ./configure ; make make debian-package ...and the tail end of the build output: ln -s /etc/wireshark/init.lua \ /home/peter/workspace/wireshark/debian/tmp/usr/share/wireshark/init.lua mkdir -p /home/peter/workspace/wireshark/debian/tmp/usr/lib/python2.4/site-packages/ cp /home/peter/workspace/wireshark/tools/wireshark_be.py /home/peter/workspace/wireshark/tools/wireshark_gen.py \ /home/peter/workspace/wireshark/debian/tmp/usr/lib/python2.4/site-packages/ mkdir -p /home/peter/workspace/wireshark/debian/tmp/usr/include/wireshark/ for F in `cat debian/wireshark-dev.header-files`; do \ cp --parents $F /home/peter/workspace/wireshark/debian/tmp/usr/include/wireshark; \ done rm -rf /home/peter/workspace/wireshark/debian/tmp/usr/man dh_installman dh_movefiles dh_movefiles: debian/tmp//usr/lib/wireshark/libwireshark.so.0 not found (supposed to put it in wireshark-common) dh_movefiles: debian/tmp//usr/lib/wireshark/libwireshark.so.0.0.1 not found (supposed to put it in wireshark-common) dh_movefiles: debian/tmp//usr/lib/wireshark/libwiretap.so.0 not found (supposed to put it in wireshark-common) dh_movefiles: debian/tmp//usr/lib/wireshark/libwiretap.so.0.0.1 not found (supposed to put it in wireshark-common) dh_movefiles: debian/tmp//usr/lib/wireshark/libwsutil.so.0 not found (supposed to put it in wireshark-common) dh_movefiles: debian/tmp//usr/lib/wireshark/libwsutil.so.0.0.0 not found (supposed to put it in wireshark-common) make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/peter/workspace/wireshark' dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 The only 2 things I can think of are a) should I have added anything to the configure call or b) have I missed a package dependency? This is Ubuntu 10.10 64 bit, a clean install for this build. Many thanks for any assistance, Peter Bond ___ Sent via:Wireshark-dev mailing listwireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to support some kind of stop criteria to stop capturing wireshark log automatically, either by script or by some kind of interfaces wireshark already supported?
Hi Yuhuai, Set up a script for parsing tshark's output and killing tshark and dumpcap when needed. Cheers, Balint On 06/10/2011 09:43 AM, Xie Yuhuai-CFQ846 wrote: Hi all, Do you know how to support some kind of stop criteria” to stop capturing wireshark log automatically, either by script or by some kind of interfaces wireshark already supported? This will be very useful when capture some low-rate-of-occurrence issues. In the capture option, it can only set stop capture after some packets/some megabytes/some minutes. could we add in one option say as stop capture after some customized criteria? /Yuhuai/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to support some kind of
I think this is an obsolete feature as one can write a Lua tap for this purpose and even use more complicated triggers. Writing a Lua example for stopping Wireshark for the Lua wiki would be more useful. See : os.exit(0) Cheers, Balint On 06/10/2011 04:28 PM, Chris Maynard wrote: Balint Reczeybalint.reczey@... writes: Set up a script for parsing tshark's output and killing tshark and dumpcap when needed. ... or maybe the idea presented in bug 3967 would be helpful? https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3967 ___ Sent via:Wireshark-dev mailing listwireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] This break buiklding of Wiretap plugins FW: [Wireshark-commits] rev 37543: /trunk/wiretap/ /trunk/wiretap/: 5views.h airopeek9.h ascend-int.h ascendtext.h atm.h ber.h btsnoop.h buf
Hi Anders, How does it break? The diff: --- trunk/wiretap/file_wrappers.h 2011/06/04 20:14:06 37542 +++ trunk/wiretap/file_wrappers.h 2011/06/04 21:20:57 37543 @@ -23,6 +23,10 @@ #ifndef __FILE_H__ #define __FILE_H__ +#include glib.h +#include wtap.h +#include wsutil/file_util.h + extern gint64 file_seek(FILE_T stream, gint64 offset, int whence, int *err); extern gint64 file_tell(FILE_T stream); extern gint64 file_tell_raw(FILE_T stream); You can contact me using the internal company address. ;-) Cheers, Balint On 06/07/2011 02:52 PM, Anders Broman wrote: Hi, The change to file_wrappers.h breaks building of a wiretap plugin for me, reverting the Change to file_wrappers.h makes it build again. Reghards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of rbal...@wireshark.org Sent: den 4 juni 2011 23:21 To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 37543: /trunk/wiretap/ /trunk/wiretap/: 5views.h airopeek9.h ascend-int.h ascendtext.h atm.h ber.h btsnoop.h buffer.h catapult_dct2000.h commview.h cosine.h csids.h daintree-sna.h ... http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=37543 User: rbalint Date: 2011/06/04 02:21 PM Log: Fix wiretap headers to allow error-free ABI dumping. Directory: /trunk/wiretap/ ChangesPath Action +2 -0 5views.h Modified +1 -0 airopeek9.h Modified +6 -0 ascend-int.h Modified +1 -0 ascendtext.h Modified +1 -0 atm.hModified +1 -0 ber.hModified +1 -0 btsnoop.hModified +1 -0 buffer.h Modified +7 -0 catapult_dct2000.h Modified +1 -0 commview.h Modified +2 -0 cosine.h Modified (39 files not shown) ___ Sent via:Wireshark-commits mailing listwireshark-comm...@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing listwireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-core] Working up to a new stable branch (1.6)
[Moving thread to wireshark-dev from wireshark-core, following Joerg's action] I have just committed the make target dumpabi for dumping ABI description using ABI compliance checker [1]. Now everything is there to start versioning with as little effort as possible. Cheers, Balint [1] http://ispras.linux-foundation.org/index.php/ABI_compliance_checker On 05/30/2011 02:23 PM, Balint Reczey wrote: Most patches has been merged which would allow us to easily update the library versions. The important change I can't introduce by submitting a patch would be a change to the release process. We should ensure that we don't make major and maintenance releases without adjusting the library version according to the ABI changes and we should not make maintenance releases with changes bumping the library versions too high, e.g. to an existing major library version. What is missing is a script for checking the ABI changes, but I'll try to prepare one. Cheers, Balint On 05/18/2011 11:16 PM, Jeff Morriss wrote: Why not create a patch? If this is only to maintain the ABI within a (stable) trunk, it doesn't seem to do any harm. And would then linuxtesting.org (only) warn us about ABI breaks within a particular version of the library? Balint Reczey wrote: Ping... We broke ABI again according to http://linuxtesting.org/upstream-tracker/versions/wireshark.html . What should be done (from my side) to start versioning? Thanks, Balint On 05/15/2011 02:24 PM, Balint Reczey wrote: On 01/12/2011 02:55 PM, Balint Reczey wrote: On 01/04/2011 06:26 PM, Jaap Keuter wrote: ... Therefore I would like to hear from you what needs to be done, what loose end are still there (other than hoovering the Bugzilla patches). I've got some ideas myself, but you probably have a better outlook on things. No grand plans, just getting thing completed (hopefully in time). Hi, I think since we export only the symbols listed in .def/.sym files we could start keeping our API/ABI stable in stable branches and start library versioning. We could start by bumping the major version of the libs we ship (libwiretab, libwsutil, libwireshark) in 1.6.0. In 1.8.0 we could remove the obsolete exported symbols if there is any. Cheers, Balint Hi, Could we please start managing the lib versions with 1.6.0(rc1)? Thanks, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] wireshark-devel package - Was: [Wireshark-core] Working up to a new stable branch (1.6)
Hi Joerg, On 05/31/2011 12:02 AM, Joerg Mayer wrote: [Moved this to wireshark-dev as it still does not belong onto wireshark-core] On Mon, May 30, 2011 at 04:18:31PM +0200, Balint Reczey wrote: I still don't know how it works when we don't install header files, network except have copy of wireshark .h files? On Debian we ship .h files in the wireshark-dev (libwireshark-dev, libwiretap-dev, libwsutil-dev in recent package versions). netexpect build-depends on those packages. OK, as this seems to repeat every 6-8 months right now, let me repeat my standard answer to this as well: The library was never meant to be used outside Wireshark (well, Ethereal). It was created to prevent us from linking the same code into ethereal and tethereal. We do not have a proper API and looking at the hoops people are jumping through to create a devel package is just plain ugly: iff some people really feel they want to create a devel package that is not endorsed by the majority of wireshark developers then at least do it properly: create proper include files instead of just adding more and more includes files of the normal dissctors etc. Most likely this will need to be redone for each major release, but that's what you get when you effectively create a fork (although for packaging purposes only). You almost correctly summarized what I would like to see changed. The library was never meant to be used outside Wireshark, but other projects, like Network Expect [1] would like to use it. In my opinion the Open Source world is about sharing. How could we capture packets with Wireshark if the Tcpdump project did not provide the libpcap as a shared library? I think now it is our turn to make our libraries usable for other OSS projects. Eloy Paris, the developer of netexpect helped a lot in separating the libraries to new Debian packages and I also did some work to not exporting symbols on UN*X systems not exported on Windows. Now it is also possible to easily dump ABI information and we could use it for setting the correct library versions while preparing releases. In my opinion everything is ready, and we could start versioning with little effort. You are right that we should reorganize .h files, too. I proposed this step for 1.8.0 in my one of previous emails. Currently we (the Wireshark project) provide the .h files in the wireshark-dev package, see debian/control. For 1.6.0 we could start by bumping the library versions to 1.0.0 and refraining from making big changes affecting the major library version in 1.6.x releases. The only stable solution that I see is to create something like ipcshark where the dissection is running as a service and other processes just use this service by feeding it undissected traces plus some specification on the dissectoin details and the output format and receive the disscted stuff back in said format. Of course you loose a bit of performance, but that is the only stable longtime solution i see. Since there is no officially stable representation of the undissected traces this wouldn't be a stable solution either. Cheers, Balint PS: [1] http://netexpect.org Ciao Jörg -- Joerg Mayerjma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 37016: /trunk/gtk/ /trunk/gtk/: main_welcome.c
On 05/17/2011 05:53 PM, Stephen Fisher wrote:
On Tue, May 17, 2011 at 05:13:35PM +0200, Balint Reczey wrote:
It is expected to be one inch below the text. :-) I wanted to make it
as clear as possible, but obviously I failed. How could it be made
clearer?
It's further down on my screen :). Just saying See the capture help
below would be sufficient I think.
Done in 37238.
Index: gtk/main_welcome.c
===
--- gtk/main_welcome.c (revision 37237)
+++ gtk/main_welcome.c (working copy)
@@ -864,7 +864,7 @@
} else {
label_text = g_strdup(No interface can be used for capturing in\n
this system with the current
configuration.\n\n
- See Capture Help for details.);
+ See Capture Help below for details.);
w = gtk_label_new(label_text);
gtk_label_set_markup(GTK_LABEL(w), label_text);
g_free (label_text);
Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 37016: /trunk/gtk/ /trunk/gtk/: main_welcome.c
It is expected to be one inch below the text. :-) I wanted to make it as clear as possible, but obviously I failed. How could it be made clearer? I also updated documentation in docbook ant the wiki with Debian related help. Cheers, Balint On 05/16/2011 08:58 PM, Stephen Fisher wrote: This is a great idea. What is/where is capture help that it refers to? It would be great if it could be a clickable link to take the user there. On Sun, May 08, 2011 at 10:59:24AM +, rbal...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=37016 User: rbalint Date: 2011/05/08 03:59 AM Log: If no interface is found for capturing show this information and direct user to Capture Help instead of showing the empty list of interfaces and capture options. Directory: /trunk/gtk/ ChangesPath Action +77 -55main_welcome.cModified ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Eclipse project for Wireshark
ddd .libs/wireshark works for me (on Debian Squeeze). Learning new things sometimes involves PITA. :-) Cheers, Balint On 01/25/2011 10:02 AM, Dietfrid Mali wrote: I used the call given below, but replaced 'gdb' with 'ddd'. ddd doesn't display any source code though, so there's still something going wrong. This stuff is a PITA. Can't I even use a graphical debugger frontend to debug Wireshark? Date: Mon, 24 Jan 2011 14:57:41 -0700 From: st...@stephen-fisher.com To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] Eclipse project for Wireshark On Mon, Jan 24, 2011 at 06:29:23PM +0100, Dietfrid Mali wrote: Thanks. I tried that, and the files are indeed compiled with -g -O0, but DDD (gdb) doesn't seem to find an program entry point (and complains about bash missing on my openSUSE 11.3 box ???). When you debug Wireshark from the root build directory, use libtool as follows: libtool --mode=execute gdb ./wireshark Otherwise, you'll be debugging the libtool wrapper script called wireshark (which calls .libs/wireshark after setting up the proper library paths and such). If you wait to debug it until it's installed, the debugging symbols will be stripped by make install. I can usually debug Wireshark without needing to turn off optimizations (-O0). ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] snmp decoding ...ubuntu smi issue ?... different then on windows XP ...?
Hi, As the maintainer of the wireshark package in Debian I feel like being addressed. :-) On 01/21/2011 11:11 AM, Andrew Hood wrote: Apologies in advance for the tone, but some actions are inexcusable. Jaap Keuter wrote: Hi, Some history: libsmi doesn't provide MIBs any more, due to Debian bug 498476 [7] The bug belongs to Debian, not libsmi. limsmi provides MIBs. Debian chooses to not include them. Yes, they can't include them in main, because they are not considered to be free according to Debian Free Software Guidelines. http://people.debian.org/~bap/dfsg-faq.html MIB installation was spun out into an independent package snmp-mibs-downloader [8] By this step Debian can ship MIBs which are note even redistributable. This package downloads the MIBs directly from their source [9], so these are not cleaned up for libsmi. snmp-mibs-downloader actually include scripts for converting and potentially cleaning up MIBs. If you are aware of any cleanup script which would be useful in snmp-mibs-downloader, please open a bug against the package at http://www.debian.org/Bugs/ . Debian is choosing to use the MIB writers version - not the one in libsmi's source. They would rather have an unusable package than a working one. I can't comment on this, but please open a bug at Debian's BTS if you find your claim valid. The better solution would have been for Debian to package the whole of libsmi as non-free, or for Wireshark to provide a Debian safe version without SNMP support. Packaging libsmi as non-free would put the depending packages to contrib instead of main. The package in Debian works fine if you don't try to crash it with broken MIBs. How would a version without SNMP support be better than that? IANA and IETF provided MIBs have numerous syntax errors. The libsmi authors have gone to a lot of trouble to correct the MIBs they provide in their codebase. I can not think of a single manufacturer whose MIBs will all go into libsmi without some syntactic and semantic corrections. Please include those cleanup scripts in snmp-mibs-downloader. Cheers, Balint NetSNMP does not have the same level of strictness in its parser, so it was not a problem until the switch was made to libsmi. FYI OpenNMS runs into the same problems with faulty MIBs. Andrew ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FW: [Wireshark-users] wireshark (with SMI) install on ubuntu issues ...(sending again ..)..
Hi, On 01/10/2011 04:27 PM, Sandor, Todd (Todd) wrote: To reach a wider audience, sending this to the dev email as well … *From:* wireshark-users-boun...@wireshark.org [mailto:wireshark-users-boun...@wireshark.org] *On Behalf Of *Sandor, Todd (Todd) *Sent:* Monday, January 10, 2011 10:14 AM *To:* wireshark-us...@wireshark.org *Subject:* [Wireshark-users] wireshark (with SMI) install on ubuntu issues ...(sending again ..).. (had errors in previous email, sending again) … Hi - need some help getting wireshark with SMI (for decoding snmp via MIBs) working on ubuntu 10.04 LTS. Wireshark shipped is compiled with SMI support: https://launchpad.net/ubuntu/lucid/amd64/wireshark-common/1.2.7-1 I can not find a package that includes wireshark with SMI ready for install, so I googled and found: apt-get install wireshark snmp-mibs-downloader should make the trick. ... ::/usr/local/wireshark(504)$ sudo apt-get install libsmi2-common libsmi2-dev libsmi2ldbl Reading package lists... Done Building dependency tree Reading state information... Done adduser: No UID is available in the range 100-999 (FIRST_SYS_UID - LAST_SYS_UID). adduser: The user `postfix' was not created. dpkg: error processing postfix (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of bsd-mailx: bsd-mailx depends on default-mta | mail-transport-agent; however: Package default-mta is not installed. Package postfix which provides default-mta is not configured yet. Package mail-transport-agent is not installed. Package postfix which provides mail-transport-agent is not configured yet. dpkg: error processing bsd-mailx (--configure): dependency problems - leaving unconfigured Setting up libsmi2-common (0.4.8+dfsg2-2) ... No apport report written because the error message indicates its a followup error from a previous failure. Setting up libsmi2ldbl (0.4.8+dfsg2-2) ... Setting up libsmi2-dev (0.4.8+dfsg2-2) ... Processing triggers for libc-bin ... ldconfig deferred processing now taking place /sbin/ldconfig.real: /usr/lib32/libMrm.so.3 is not a symbolic link /sbin/ldconfig.real: /usr/lib32/libXm.so.3 is not a symbolic link /sbin/ldconfig.real: /usr/lib32/libUil.so.3 is not a symbolic link Errors were encountered while processing: postfix bsd-mailx E: Sub-process /usr/bin/dpkg returned an error code (1) Your system is broken, you should fix it first. Please ask for help on ubuntu users list. I assume if I can get this SMI stuff installed, that if I follow the rest of the compile/install that wireshark (below) with SMI will work…? After installing devscripts via Synaptic Package Manager (so could use the dpkg-buildpackage command) I was able to get verion 1.2.7 of wireshark installed/working using the command below, but when I go into Preferences Name Resolution, the options to configure the MIB paths/modules are not available. sudo apt-get build-dep wireshark cd wireshark-1.2.7/ dpkg-buildpackage -rfakeroot -b -uc cd .. sudo dpkg -i tshark_1.2.7-1_amd64.deb wireshark-common_1.2.7-1_amd64.deb wireshark_1.2.7-1_amd64.deb You don't need to do this. The official packages should work. But, I can’t decode smmp mibs when I run this wireshark: You need to install snmp-mibs-downloader as descibed in /usr/share/doc/wireshark-common/README.Debian . Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why isn't libwireshark.def autogenerated?
Hi Gregory, On 12/17/2010 03:21 PM, Gregory Seidman wrote: I keep running into this issue where I'm working on a dissector plugin (for internal distribution, on Windows) and want to use some function declared in a header file in epan or epan/dissectors only to discover that it won't link. Even if I modify libwireshark.def in my source tree so the plugin will link, it will fail to load in any other build of Wireshark (e.g. the standard release). Symbols listed in libwireshark.def are the symbols provided for external use. We should not list symbols not exported from libwireshark in headers provided for plugin development, I agree. Why isn't libwireshark.def generated from all of those header files as part of the build system? Is it just the difficulty of extracting those function declarations, or is there some policy reason? Would there be any objection to a patch (almost certainly including a Perl or Python script) to generate it as part of the build? The point of having libwireshark.def (and libwireshark.sym from now) is to list the symbols we consider to be part of the public API (ABI). We can keep those symbols reasonably stable while we are free to change the internal symbols frequently. Please don't provide a patch for exporting all symbols, but name the symbol you miss from libwireshark.def. Note that this is unique to Windows, as far as I know. Shared objects (a.k.a. DLLs) under any *nix system I know of default to exporting all (non-static) symbols. Windows DLLs, however, default to exporting no symbols, and there are mechanisms both in the code (i.e. a keyword) and outside the code (i.e. a .def file) to explicitly export individual symbols. Exporting all symbols from .so files is a bad practice and we just stopped doing so in the development branch. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 35145: /trunk/ /trunk/epan/: Makefile.am /trunk/: Makefile.am.inc /trunk/wiretap/: Makefile.am /trunk/wsutil/: Makefile.am
On 12/08/2010 04:21 AM, Jeff Morriss wrote: On 12/07/2010 01:42 PM, Jeff Morriss wrote: Balint Reczey wrote: On 12/07/2010 04:06 PM, Jeff Morriss wrote: rbal...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=35145 User: rbalint Date: 2010/12/07 05:38 AM Log: Make libtool export only symbols listed in *.def files [...] Directory: /trunk/wsutil/ Changes Path Action +6 -2 Makefile.am Modified Hmmm, libwsutil holds the optional targets (e.g., inet_aton() for systems that don't have it). At least on the MacOS 10.5 buildbots, nmedit complains if libtool asks it to export a symbol that isn't present in the library. I'm not sure of an easy way to fix that (hacking the .def or the .sym file depending on which optional targets are being built doesn't sound fun). Any ideas? Or should we export all symbols from libwsutil? I revert the change for /trunk/wsutil/ to make us able to build for all platforms. I will look into other possibilities of hiding some functions: http://www.gnu.org/software/hello/manual/gnulib/Exported-Symbols-of-Shared- Libraries.html Oops, looks like I just beat you to it. As mentioned in the commit message, it may not be worth it for libwsutil: on my system there are only 21 global symbols (including things like _init, _end, etc.). Since this library's purpose is to provide utility functions, I suppose we may be able to control what it exports fairly easily (there hopefully won't be any cases of module A's symbols being needed by module B where that symbol isn't also needed outside of the library). There are also optional functions in libwireshark. The Solaris buildbot doesn't have Lua installed so it's failing to link because it can't find wslua_plugin_list... Ideas? Maybe this behavior can only be enabled if the right versions of various tools are installed (which ones?)? I committed a hack which will filter out wslua_plugin_list from the sym file to keep the build successful. I think this is not the right approach. I think the list of exported symbols should not depend on configure parameters, because that way we could make two libraries with the same so version but with different symbol lists. In the wslua_plugin_list case we could export it and leave it as NULL. I will send my patch after running a few tests. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 35145: /trunk/ /trunk/epan/: Makefile.am /trunk/: Makefile.am.inc /trunk/wiretap/: Makefile.am /trunk/wsutil/: Makefile.am
On 12/09/2010 12:59 AM, Balint Reczey wrote:
On 12/08/2010 04:21 AM, Jeff Morriss wrote:
On 12/07/2010 01:42 PM, Jeff Morriss wrote:
Balint Reczey wrote:
On 12/07/2010 04:06 PM, Jeff Morriss wrote:
rbal...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=35145
User: rbalint
Date: 2010/12/07 05:38 AM
Log:
Make libtool export only symbols listed in *.def files
[...]
Directory: /trunk/wsutil/
Changes Path Action
+6 -2 Makefile.am Modified
Hmmm, libwsutil holds the optional targets (e.g., inet_aton() for
systems that don't have it).
At least on the MacOS 10.5 buildbots, nmedit complains if libtool asks
it to export a symbol that isn't present in the library. I'm not sure
of an easy way to fix that (hacking the .def or the .sym file depending
on which optional targets are being built doesn't sound fun). Any
ideas? Or should we export all symbols from libwsutil?
I revert the change for /trunk/wsutil/ to make us able to build for
all platforms.
I will look into other possibilities of hiding some functions:
http://www.gnu.org/software/hello/manual/gnulib/Exported-Symbols-of-Shared-
Libraries.html
Oops, looks like I just beat you to it.
As mentioned in the commit message, it may not be worth it for
libwsutil: on my system there are only 21 global symbols (including
things like _init, _end, etc.). Since this library's purpose is to
provide utility functions, I suppose we may be able to control what it
exports fairly easily (there hopefully won't be any cases of module A's
symbols being needed by module B where that symbol isn't also needed
outside of the library).
There are also optional functions in libwireshark. The Solaris buildbot
doesn't have Lua installed so it's failing to link because it can't find
wslua_plugin_list... Ideas? Maybe this behavior can only be enabled if
the right versions of various tools are installed (which ones?)?
I committed a hack which will filter out wslua_plugin_list from the sym file to
keep the build successful.
I think this is not the right approach. I think the list of exported symbols
should not depend on configure parameters, because that way we could make two
libraries with the same so version but with different symbol lists.
In the wslua_plugin_list case we could export it and leave it as NULL.
I will send my patch after running a few tests.
Cheers,
Balint
Tests ran faster than expected.
Will commit this tomorrow and revert my last commit if there are no objections.
The commit implementing filtering could be adapted to wsutil's several optional
symbols, if needed.
Cheers,
Balint
Index: gtk/plugins_dlg.c
===
--- gtk/plugins_dlg.c (revision 35158)
+++ gtk/plugins_dlg.c (working copy)
@@ -29,9 +29,6 @@
#include gtk/gtk.h
#include epan/plugins.h
-#ifdef HAVE_LUA_5_1
-#include epan/wslua/init_wslua.h
-#endif
#include gtk/dlg_utils.h
#include gtk/gui_utils.h
Index: epan/wslua/init_wslua.c
===
--- epan/wslua/init_wslua.c (revision 35158)
+++ epan/wslua/init_wslua.c (working copy)
@@ -32,9 +32,9 @@
#include math.h
#include epan/expert.h
#include epan/ex-opt.h
+#include epan/plugins.h
#include wsutil/privileges.h
#include wsutil/file_util.h
-#include init_wslua.h
static lua_State* L = NULL;
Index: epan/wslua/init_wslua.h
===
--- epan/wslua/init_wslua.h (revision 35158)
+++ epan/wslua/init_wslua.h (working copy)
@@ -1,43 +0,0 @@
-/* init_wslua.h
- * definitions for wslua plugins structures
- *
- * $Id$
- *
- * Wireshark - Network traffic analyzer
- * By Gerald Combs ger...@wireshark.org
- * Copyright 1998 Gerald Combs
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __INIT_WSLUA_H__
-#define __INIT_WSLUA_H__
-
-#include glib.h
-/** @defgroup wslua_group Wireshark LUA
- *
- */
-/** @file
- * @ingroup wslua_group
- */
-typedef struct _wslua_plugin {
-gchar *name;/** plugin name */
-gchar *version; /** plugin version */
-struct _wslua_plugin *next;
-} wslua_plugin;
-
-WS_VAR_IMPORT wslua_plugin *wslua_plugin_list;
-
-#endif /* __INIT_WSLUA_H__ */
Index: epan/plugins.h
Re: [Wireshark-dev] [Wireshark-commits] rev 35145: /trunk/ /trunk/epan/: Makefile.am /trunk/: Makefile.am.inc /trunk/wiretap/: Makefile.am /trunk/wsutil/: Makefile.am
On 12/07/2010 04:06 PM, Jeff Morriss wrote: rbal...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=35145 User: rbalint Date: 2010/12/07 05:38 AM Log: Make libtool export only symbols listed in *.def files [...] Directory: /trunk/wsutil/ ChangesPath Action +6 -2 Makefile.amModified Hmmm, libwsutil holds the optional targets (e.g., inet_aton() for systems that don't have it). At least on the MacOS 10.5 buildbots, nmedit complains if libtool asks it to export a symbol that isn't present in the library. I'm not sure of an easy way to fix that (hacking the .def or the .sym file depending on which optional targets are being built doesn't sound fun). Any ideas? Or should we export all symbols from libwsutil? I revert the change for /trunk/wsutil/ to make us able to build for all platforms. I will look into other possibilities of hiding some functions: http://www.gnu.org/software/hello/manual/gnulib/Exported-Symbols-of-Shared- Libraries.html Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Install catastrophe
Hi Gethro, Have you checked those sites?: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582298 https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/513903 Or this file?: /usr/share/doc/wireshark-common/README.Debian Cheers, Balint PS: It is a -dev list BTW. On 06/22/2010 01:09 PM, Geoffrey C. Brown wrote: To all, This is my first post so please forgive the naivety. I have been trying to install Wireshark for several days now... The overarching problem is that I am unable to see the eth0 and wlan capture devices. I am using Ubuntu 10.04 LTS - the Lucid Lynx and Wireshark 1.2.7 was installed and having the above issues. I downloaded the current tar's from GTK+, Glib, baycc, and Wireshark. I followed the install directions listed on the site and still haven't had any luck... In advance, thank you for any help you might be able to shed on this problem... Regards, Gethro ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark 1.2.6 Run Time Error
Of course. Please open a bug report at https://bugs.wireshark.org/bugzilla/, attach your dissector's source licensed under GPL as a patch and mark the patch for review. ;-) Cheers, Balint Reddy Nagendra-GKTC37 wrote: Hi, I am creating one new dissector, in that I used dissector_add(tipc-payload.interface, CLMP_SM_INT, clmp_sm_handle); Comiplation and Linking gone smooth … But when we ran WireShark, giving run time error. This application has requested the Runtime to terminate it an unusual way …. Can any one help me regarding run time error. Thanks, NAG ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] MIBS Problem?
Hi, Probably you don't have the MIBs on your PATH. The Windows installers for Wireshark come with the needed MIBs, but when you run wireshark.exe right after building it, the MIBs won't get copied to the usual MIB directory. Cheers, Balint dest wrote: After downloading source files and building, launching the wireshark.exe in my development directory presents me with this error: The following errors were found while loading the MIBS: -:0 1 module-not-found failed to locate MIB module `IP-MIB' -:0 1 module-not-found failed to locate MIB module `IF-MIB' -:0 1 module-not-found failed to locate MIB module `TCP-MIB' -:0 1 module-not-found failed to locate MIB module `UDP-MIB' -:0 1 module-not-found failed to locate MIB module `SNMPv2-MIB' -:0 1 module-not-found failed to locate MIB module `RFC1213-MIB' -:0 1 module-not-found failed to locate MIB module `IPV6-ICMP-MIB' -:0 1 module-not-found failed to locate MIB module `IPV6-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-COMMUNITY-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-FRAMEWORK-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-MPD-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-NOTIFICATION-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-PROXY-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-TARGET-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-USER-BASED-SM-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-USM-DH-OBJECTS-MIB' -:0 1 module-not-found failed to locate MIB module `SNMP-VIEW-BASED-ACM-MIB' The Current Path is: C:\wireshark\snmp\mibs;C:\Users\Shawn\AppData\Roaming\Wireshark\snmp\mibs I'm currently on Windows 7, the nondevelopment Wireshark install works fine. Any help would be greatly appreciated. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
Hi, I have committed support for disabling OID resolution and suppressing SMI errors in 32096. Since OID resolution will be disabled by default from now, I hope to make everyone happy. :-) (Except those who want to use non smilint clean MIBS with Wireshark, but they are free to fix libsmi. ;-)) Cheers, Balint Pascal Quantin wrote: Hi, 2010/3/2 Balint Reczey balint.rec...@ericsson.com mailto:balint.rec...@ericsson.com Hi Pascal, It seems that libsmi 0.4.8 is more picky than 0.4.7 I tested my patch with. :-( I plan to remove the workaround from Wireshark as it makes more problems than it solves. It means that https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4174 will remain open. Any objections? Cheers, Balint As far as I'm concerned, I see no objections (but as I'm not using SNMP at all...). Regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
Hi Pascal, It seems that libsmi 0.4.8 is more picky than 0.4.7 I tested my patch with. :-( I plan to remove the workaround from Wireshark as it makes more problems than it solves. It means that https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4174 will remain open. Any objections? Cheers, Balint Pascal Quantin wrote: Hi 2010/2/26 Balint Reczey balint.rec...@ericsson.com mailto:balint.rec...@ericsson.com Balint Reczey wrote: Balint Reczey wrote: Bill Meier wrote: Log: Prevent potential crash in libsmi. From: Vincent Bernat ber...@debian.org mailto:ber...@debian.org Since SVN #32006 was committed, the following messages appear when tshark and Wireshark are started. For Wireshark the messages appear as popup Windows which must be dismissed !! -- tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 -- Needing to dismiss popup windows each time Wireshark is started is obviously a non-starter. :) So; What should be done ?? (I know zilch about SNMP MIBS). Bill I wanted to commit the attached patch, but I realized, that preferences are read _after_ loading the SMI modules. :-( Could we read prefs earlier, maybe twice? Cheers, Balint I also asked Vincent about a potentially better workaround [1]. We can remove the buggy(?) MIBs from the default list of MIBs to be loaded, but it would not help users with older preferences file. :-( I can turn the popup to a debug message, but silently skipping the modules does not seem to be a good idea. Cheers, Balint [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 I've committed a refinement to the workaround based on Vincent's email [1] in 32017. It seems to be working fine on Linux but on Windows I still get a popup when launching wireshark or the following text when launching tshark (SVN revision 32067): tshark: Stopped processing module SNMPv2-SMI due to error(s) to prevent potential crash in libsmi. Module's conformance level: 1. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 Is it a known issue ? Can something be done for us poor Windows user ? ;) Regards, Pascal. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org mailto:wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
Bill Meier wrote:
Log:
Prevent potential crash in libsmi.
From: Vincent Bernat ber...@debian.org
Since SVN #32006 was committed, the following messages appear when
tshark and Wireshark are started.
For Wireshark the messages appear as popup Windows which must be
dismissed !!
--
tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s) to
prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to
prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to
prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
--
Needing to dismiss popup windows each time Wireshark is started is
obviously a non-starter. :)
So; What should be done ?? (I know zilch about SNMP MIBS).
Bill
I wanted to commit the attached patch, but I realized, that preferences
are read _after_ loading the SMI modules. :-(
Could we read prefs earlier, maybe twice?
Cheers,
Balint
Index: epan/prefs.c
===
--- epan/prefs.c (revision 32015)
+++ epan/prefs.c (working copy)
@@ -1206,6 +1206,7 @@
/* set the default values for the name resolution dialog box */
prefs.name_resolve = RESOLV_ALL ^ RESOLV_NETWORK;
prefs.name_resolve_concurrency = 500;
+ prefs.suppress_smi_errors = FALSE;
/* set the default values for the tap/statistics dialog box */
prefs.tap_update_interval = TAP_UPDATE_DEFAULT_INTERVAL;
@@ -1673,6 +1674,7 @@
*/
#define PRS_NAME_RESOLVE name_resolve
#define PRS_NAME_RESOLVE_CONCURRENCY name_resolve_concurrency
+#define PRS_NAME_RESOLVE_SUPPRESS_SMI_ERRORS name_resolve_suppress_smi_erors
#define PRS_CAP_NAME_RESOLVE capture.name_resolve
/* values for the capture dialog box */
@@ -2177,6 +2179,8 @@
}
} else if (strcmp(pref_name, PRS_NAME_RESOLVE_CONCURRENCY) == 0) {
prefs.name_resolve_concurrency = strtol(value, NULL, 10);
+ } else if (strcmp(pref_name, PRS_NAME_RESOLVE_SUPPRESS_SMI_ERRORS) == 0) {
+prefs.suppress_smi_errors = ((g_ascii_strcasecmp(value, true) == 0)?TRUE:FALSE);
} else if ((strcmp(pref_name, PRS_RTP_PLAYER_MAX_VISIBLE) == 0) ||
(strcmp(pref_name, rtp_player.max_visible) == 0)) {
/* ... also accepting old name for this preference */
@@ -3054,6 +3058,11 @@
fprintf(pf, PRS_NAME_RESOLVE_CONCURRENCY : %d\n,
prefs.name_resolve_concurrency);
+ fprintf(pf, \n# Suppress smi errors?\n);
+ fprintf(pf, # TRUE or FALSE (case-insensitive).\n);
+ fprintf(pf, PRS_NAME_RESOLVE_SUPPRESS_SMI_ERRORS : %s\n,
+ prefs.suppress_smi_errors == TRUE ? TRUE : FALSE);
+
fprintf(pf, \n### Taps/Statistics \n);
fprintf(pf, \n# Tap update interval in ms.\n);
Index: epan/prefs.h
===
--- epan/prefs.h (revision 32015)
+++ epan/prefs.h (working copy)
@@ -147,6 +147,7 @@
gint console_log_level;
guint32 name_resolve;
gint name_resolve_concurrency;
+ gboolean suppress_smi_errors;
gchar *capture_device;
gchar *capture_devices_linktypes;
gchar *capture_devices_descr;
Index: gtk/prefs_nameres.c
===
--- gtk/prefs_nameres.c (revision 32015)
+++ gtk/prefs_nameres.c (working copy)
@@ -60,6 +60,7 @@
#endif
#ifdef HAVE_LIBSMI
+# define SUPPRESS_SMI_ERRORS_KEY suppress_smi_errors
# define SMI_TABLE_ROWS 2
#else
# define SMI_TABLE_ROWS 0
@@ -91,6 +92,7 @@
char concur_str[10+1];
#endif /* HAVE_C_ARES || HAVE_GNU_ADNS */
#ifdef HAVE_LIBSMI
+ GtkWidget *suppress_smi_errors_cb;
uat_t *smi_paths_uat;
uat_t *smi_modules_uat;
#endif
@@ -162,6 +164,13 @@
Support for this feature was not compiled into this version of Wireshark);
#endif /* HAVE_C_ARES || HAVE_GNU_ADNS */
#ifdef HAVE_LIBSMI
+ /* Suppress smi errors */
+ table_row++;
+ suppress_smi_errors_cb = create_preference_check_button(main_tb, table_row,
+ Suppress SMI errors:, Some errors can be ignored. If unsure, set to false.,
+ prefs.suppress_smi_errors);
+ g_object_set_data(G_OBJECT(main_vb), SUPPRESS_SMI_ERRORS_KEY, suppress_smi_errors_cb);
+
/* SMI paths UAT */
smi_paths_uat = uat_get_table_by_name(SMI Paths);
if (smi_paths_uat) {
@@ -225,6 +234,9 @@
#if defined(HAVE_C_ARES) || defined(HAVE_GNU_ADNS)
GtkWidget *c_resolv_cb, *resolv_concurrency_te;
#endif /* HAVE_C_ARES || HAVE_GNU_ADNS */
+#ifdef HAVE_LIBSMI
+ GtkWidget *suppress_smi_errors_cb;
+#endif
m_resolv_cb = (GtkWidget *)g_object_get_data(G_OBJECT(w), M_RESOLVE_KEY);
n_resolv_cb = (GtkWidget *)g_object_get_data(G_OBJECT(w), N_RESOLVE_KEY);
@@ -245,6
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
Balint Reczey wrote: Bill Meier wrote: Log: Prevent potential crash in libsmi. From: Vincent Bernat ber...@debian.org Since SVN #32006 was committed, the following messages appear when tshark and Wireshark are started. For Wireshark the messages appear as popup Windows which must be dismissed !! -- tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 -- Needing to dismiss popup windows each time Wireshark is started is obviously a non-starter. :) So; What should be done ?? (I know zilch about SNMP MIBS). Bill I wanted to commit the attached patch, but I realized, that preferences are read _after_ loading the SMI modules. :-( Could we read prefs earlier, maybe twice? Cheers, Balint I also asked Vincent about a potentially better workaround [1]. We can remove the buggy(?) MIBs from the default list of MIBs to be loaded, but it would not help users with older preferences file. :-( I can turn the popup to a debug message, but silently skipping the modules does not seem to be a good idea. Cheers, Balint [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
I would be okay with that, but prefs are still read after loading the MIBs. :-( I could make a hack to store this particular preference in an uat, but this does not seem to be a good idea. :-( The best would be fixing libsmi. Is there anyone familiar with libsmi's code? :-) Cheers, Balint Joerg Mayer wrote: How about an option to NOT load any MIBs at all instead? Rationale: Either you need MIBs, in which case they need to be complete and correct, or you don't. ciao Joerg ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started
Balint Reczey wrote: Balint Reczey wrote: Bill Meier wrote: Log: Prevent potential crash in libsmi. From: Vincent Bernat ber...@debian.org Since SVN #32006 was committed, the following messages appear when tshark and Wireshark are started. For Wireshark the messages appear as popup Windows which must be dismissed !! -- tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to prevent potential crash in libsmi. Module's conformance level: 0. See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 -- Needing to dismiss popup windows each time Wireshark is started is obviously a non-starter. :) So; What should be done ?? (I know zilch about SNMP MIBS). Bill I wanted to commit the attached patch, but I realized, that preferences are read _after_ loading the SMI modules. :-( Could we read prefs earlier, maybe twice? Cheers, Balint I also asked Vincent about a potentially better workaround [1]. We can remove the buggy(?) MIBs from the default list of MIBs to be loaded, but it would not help users with older preferences file. :-( I can turn the popup to a debug message, but silently skipping the modules does not seem to be a good idea. Cheers, Balint [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325 I've committed a refinement to the workaround based on Vincent's email [1] in 32017. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Bug 3871 (Please include source for User's Guide in distributed sources)
Hi, I would like to bring some attention to the mentioned bug [1]. The problem has been reported as a wishlist item several times to the Debian BTS. Probably other distributions would be happy, too, to be able package the documentation for Wireshark in an easy way. Since the bug did not receive any comment and I'm not able to fix it on my own, I would like to ask you to comment on the problem, and if no one objects, have the documentation included in the distributed sources. Thanks, Balint [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3871 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Compile with PIE
Bill Meier wrote: Stig Bjørlykke wrote: Hi, Can we build Wireshark and friends as Position-independent executables (PIE)? The attached patch seems to do this. Any objections against this patch? I've no experience with Position-independent executables; A quick search does suggest that there's a performance hit (every time the program is loaded into memory ??). For example: From: http://www.redhat.com/magazine/009jul05/features/execshield/ Position independent code has a performance overhead on most architectures (x86-64 is the exception to this). For this reason, neither Red Hat® Enterprise Linux® nor Fedora™ Core have the entire distribution compiled as a PIE binary. Only selected, security sensitive programs are compiled as PIEs. Thoughts ?? Recent Debian and Ubuntu packages are already built with PIE and other security related hardening options: http://wiki.debian.org/Hardening http://packages.qa.debian.org/w/wireshark/news/20091006T201929Z.html I haven't tested the speed impacts, but the packaged binaries don't seem to be noticeably slower than the svn builds. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to do a multi-packet dissector
Hi, From http://wiki.wireshark.org/Lua/Dissectors : Like dissectors written in C, Lua dissectors can use Wireshark's ability to reassemble TCP streams: * To not use TCP reassembly, make your Lua dissector function return nothing (nil) or 0 (in case dissector can't dissect packet). * To request reassembly via the pinfo struct as described in README.developers, set pinfo.desegment_len and pinfo.desegment_offset (works from Wireshark 1.1.2). Cheers, Balint Morita, Bill wrote: I am writing a Lua dissector for a streaming protocol that may spread a “record” over several TCP packets. What is a reasonable approach to take with this type of situation?? Thanks in advance. --- Bill Morita Cube 1040 503-495-9513 bill.mor...@arrisi.com ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How about moving from svn to git?
Joerg Mayer wrote: Hello, this is just something that went through my mind yesterday while working on the third patch on the same files and without a chance to commit between the patches. If there is one thing that I don't like (although I do it sometimes) is to do a commit that does several things at once. With git, I could commit each patch (which is done locally) and eventually push all commits to the central repository while maintaing the indivitual character of the commits. I don't like git very much, but that's what various projects I'm tracking use, so that's why I propose the use of git. Also - if I'm not mistaken - some people seem to use tortoise and that tool seems to have git support. Ciao Joerg Hi, I really like the idea and I wanted to propose git, too. It would be much easier to follow changes in the stable/oldstable branches and this is something I need, since I started to maintain the official Debian packages. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] mingw for plugin developement
Hi Angelo, Try Visual C++ 2008 Express Edition, it's free. http://www.wireshark.org/docs/wsdg_html_chunked/ChToolsMSChain.html Cheers, Balint gmail wrote: Hello All, i ha ve developed a dissector, using gcc on windows (mingw). Wireshark says that cannot load the module, i read already the FAQs. So is there any chance to have this mingw dll loadable ? I will not install any M$ payment / cracked M$VC or similar in my PC, and also think that opensource development should keep away from payment stuff. It any suggestion, many thanks Regards, Angelo ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark freeze issue
Could you please file a bug for that problem? https://bugs.wireshark.org/bugzilla/ Cheers, Balint Sam Roberts wrote: Seems some malformed OPC UA traffic causes wireshark to freeze, though it recovers after a few minutes. -- Forwarded message -- Wireshark gets freezed for about two minutes when trying to decode a malformed packet of OPCUA Service CallRequest. There are two malformed CallRequest packets in the pcap, in which the latter one cause the issue. To reproduce: 1. Load the pcap file 2. Open Decode as ... dialog, select Transport source(12001) or destination(12001) as opcua, and press OK 3. Wireshark gets freezed at the dialog for about 2 minutes, and then show the packets as OpcUa. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Port Expert info changes to 1.2.2? -Significant performance improvement.
Joerg Mayer wrote: On Fri, Aug 28, 2009 at 04:28:02PM +0200, Balint Reczey wrote: I think we should stay with the current policy of adding only bugfixes to the stable branch. There have been minor non-bugfixes before - no need to be too strict. IIRC, there have been changes to e.g. the list of supported capture file formats in the past. Yes, there have been, but personally I would prefer a strict bugfix-only policy for stable branches. In Debian, there is an ongoing discussion about allowing whole Wireshark stable branch updates to enter Debian stable, but if we push new functionality into the stable Wireshark branches, this does not seem to be a good idea. That's for Debian to decide, but I don't see any reason that we should base *our* policy on Debian's policy. If we go about the changes carefully, maybe add some sort of Acked-By policy, which means that someone else who feels competent to evaluate that patch and the patch is not too complex, then why should't it go into the stable branch? Yes it is our policy and we have no obligation to base it on others'. I just wanted to point out that others may rely on our policy, and we may consider their standpoint when changing our policy. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Autogen.sh error on ubuntu
I think the easiest way to start development on Debian or any derivative is: (0: remove everything that may interfere with the build from /usr/local) sudo apt-get build-dep wireshark ./autogen.sh ./configure make Cheers, Balint Swapnil Barai (sbarai) wrote: Ok, I can reinstall the packages using apt-get if it makes difference. The output of sh -x ./aclocal-flags : + aclocal --print-ac-dir + aclocal_dir=/usr/local/share/aclocal + pkg-config --variable=prefix glib-2.0 + glib_prefix=/usr + [ -z /usr ] + glib_aclocal_dir=/usr/share/aclocal + dirname ./aclocal-flags + ac_missing_dir=. + echo -I ./aclocal-fallback + tr -d \012 + tr -d \015 -I ./aclocal-fallback+ [ ! -z /usr/local/share/aclocal -a ! -z /usr/share/aclocal -a /usr/local/share/aclocal != /usr/share/aclocal ] + echo -I /usr/share/aclocal + tr -d \012 + tr -d \015 -I /usr/share/aclocal+ echo + exit 0 On Aug 28, 2009, at 12:28 PM, Swapnil Barai (sbarai) wrote: That's true. However as mentioned on http://wiki.wireshark.org/BuildingAndInstalling I wanted to install automake in the same prefix as libtool. Sudo apt-get install automake was putting it in a diff dir. That item applies only if you're installing libtool from source because the version that comes with your OS is 1.5.x and less than 1.5.10 (as it notes, there's a bug in 1.5, fixed in 1.5.10) - *IF* you're installing libtool from source for that reason, *THEN* you have to install automake and autoconf in the same prefix. It doesn't apply to versions that come with the OS - which includes, for Debian and derivatives of it such as Ubuntu, versions installed with an apt-get from the distribution's repository - so if you do an apt-get install of automake, autoconf, and libtool, that should be OK. (If it's not, that's a bug in your distribution.) This is the output: What's the output of sh -x ./aclocal-flags? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Port Expert info changes to 1.2.2? -Significant performance improvement.
Hi, I think we should stay with the current policy of adding only bugfixes to the stable branch. The next development snapshot is scheduled to be released in Q4, 2009 [1] and this enhancement could be distributed in the snapshot. In Debian, there is an ongoing discussion about allowing whole Wireshark stable branch updates to enter Debian stable, but if we push new functionality into the stable Wireshark branches, this does not seem to be a good idea. Cheers, Balint [1] http://wiki.wireshark.org/Development/Roadmap Anders Broman wrote: Hi, As this enhancement is limited to one function and and not that much code (I think ) it's still something to consider as the benefits are great and it can be delivered within a short timeframe. I think we should be strict about new functionality but not rigid. If we want the new packet list in 1.4 there's a lot of work left so a new release might be many month away. Regards Anders *From:* wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] *On Behalf Of *Jaap Keuter *Sent:* den 26 augusti 2009 11:41 *To:* Developer support list for Wireshark *Subject:* Re: [Wireshark-dev] Port Expert info changes to 1.2.2? -Significant performance improvement. Hi, Yeah, i know it's good. Hence it should be the attraction for 1.4, not 1.2. Otherwise where will it end? Again a reason to release stable before sharkfest'10 ;) Thanx, Jaap Sent from my iPhone On 26 aug 2009, at 10:41, Anders Broman anders.bro...@ericsson.com mailto:anders.bro...@ericsson.com wrote: Hi, I've been doing some measurements on the improvements to the Export info functions: 61 Mb file 159047 Packets 118 844 Errors (UDP checksum). WS 1.2.1Trunk Old packet list Trunk New packet list Load file: ~16s ~14s ~4s Memory used: 232 812 kb 182 324 kb 131 716 kb Start: Expert info comp: 1.35s ~10s ~10s Memory used: 299 028241 336 kb 190 832 kb Add Expert info: 1.44s ~12s ~12s Memory used: 363 244 kb 291 528 kb241 032kb As you can see there is a significant reduction in the time required to load the expert data in trunk. Some of the gain is probably Due to other changes but I still believe it would be worth it to port this even if it's new functionality or is the old behavior a bug? ;-) There is no significant change in memmory usage in expert infos. Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 27748: /trunk/plugins/profinet/ /trunk/plugins/profinet/: Makefile.common crc16.c crc16.h moduleinfo.h moduleinfo.nmake packet-dcerpc-pn-io.c packet-pn-rt.c
2009. 03. 17, kedd keltezéssel 00.29-kor Ulf Lamping ezt írta: Joerg Mayer schrieb: On Mon, Mar 16, 2009 at 09:40:03PM +, u...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=27748 crc16 algorithm copied from Linux sources (GPL V2 only!) So far the wireshark sources are v2 or later - so adding a gplv2 only file is not something that should be done without asking *first*, because it has effects for all of Wireshark. Or maybe there already were files that are v2 only and I missed that? I had in mind that we already have GPL V2 only files in Wireshark before, but I may be wrong here. I can remove the two GPL V2 only files, as this is only a CRC16 expert check here. That is the CCITT implementation of CRC16 which is not already existing in Wireshark AFAIK. Having the CCITT CRC16 in Wireshark would be probably a good idea anyway. Some time ago when I actually implemented the stuff I couldn't find a GPL V2 or later implementation. Question is: How to continue? Hi, Could we ask the copyright holder of the CRC16 algorithm to offer the code under GPL V2 or later to the Wireshark project? Regards, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] epan/wslua/Makefile.am: is it right that init.lua in 'dist'?
Committed revision 27094. Thanks, Balint 2008. 12. 23, kedd keltezéssel 11.06-kor yami ezt írta: Hi Dev, I found following lines in epan/wslua/Makefile.am: dist_pkgdata_DATA = \ init.lua \ console.lua \ dtd_gen.lua However init.lua is generated by a script from a template Lua file, which means there is no need to distribute init.lua itself. It does no harm right now, but I don't think it is right. Any comments? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 26986: /trunk/help/ /trunk/help/: Makefile.am
Hi, I already changed it in commmit 26999. Cheers, Balint 2008. 12. 15, hétfő keltezéssel 07.28-kor Bill Meier ezt írta: Stig Bjørlykke wrote: 2008/12/13 wme...@wireshark.org: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=26986 User: wmeier Date: 2008/12/13 07:00 AM Log: Fix to make faq.txt when one or more of elinks,... don't exist I always get this warnings when I only have lynx, and I think they look like errors. /bin/sh: elinks: command not found /bin/sh: links: command not found You're absolutely correct. I'll change the code so are no such messages (unless none of the elinks, ... exist). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] problems with accessing pinfo, tvb in C, pinfo and tvb are passed from lua
Hi,
I think you could create an enhancement request in the bugtracker
about making private_data accessible via Lua API. (Patches are
welcome! ;-))
That way you would not have to deal with the internal changes of the Lua
plugin.
Cheers,
Balint
2008. 12. 9, kedd keltezéssel 17.46-kor yami ezt írta:
Hi dev,
Here is my story: my C dissector stores some information in
pinfo-private_data, then it calls my lua dissector. I also wrote a C
dynamic library which can be called by lua dissector, so that lua
dissector can extract information from pinfo-private_data. The whole
process can be ilustrated by:
C dissector ---calls--- lua dissector
loadlib--- C function extract data from pinfo-private_data
return-data lua dissector
Unfortunately the definition of Pinfo in epan/wslua/wslua.h was
changed from rev. 25844 to rev. 25845 [1]. Due to this change, my code
make wireshark crash.
My question is: how can we prevent this kind of thing in the futhure?
By adding a function (or macro) like this (?)
packet_info* wslua_pinfo(Pinfo pinfo)
{
return pinfo-ws_pinfo;
}
Thanks!
[1] See bug 2453:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2453
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How do you get RTP recognized by Wireshark ?
Hi, I had a similar problem and the easiest way was adding a prepared SDP frame to the beginning of the captured file. Best regards, Balint 2008. 11. 17, hétfő keltezéssel 18.52-kor Anders Broman ezt írta: Hi, I think rtp_add_address() should do it, see packet-uma.c SIP RTCP etc. You might have to add debug code to see where it fails...( if(tree) causing problems?). Regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Lum Sent: den 17 november 2008 17:59 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] How do you get RTP recognized by Wireshark ? Yes, I've tried that, thanks. Wireshark shows the packets as RTP but does not know the payload type. I would like to make modifications to the source so that Wireshark will understand the CODECs specified in the IOS5 signaling and then subsequently call another dissector for RFC3558. Thanks. -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 Star Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhik Sarkar Sent: November 15, 2008 1:53 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] How do you get RTP recognized by Wireshark ? Hi Michael, I don't know much about RTP, but I think I remember someone answering a similar question recently... have you already trying turning on the preference for RTP protocol called Try to decode RTP outside of conversations?. HTH Abhik. On Fri, Nov 14, 2008 at 10:06 PM, Michael Lum [EMAIL PROTECTED] wrote: Hi, I have RTP streams that are set up with an unrecognized signaling protocol. I.e. not SIP/MGCP, etc. Can somebody give me a quick run down on what to change so that the streams can be recognized as RTP ? I thought all I might have to do was add a call to rtp_add_address() with the correct IP address, port, payload, etc. but it doesn't appear to work. Any help would be great. Thanks. -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 Star Solutions ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] pending patches
Hi, I have two pending patch requests for the Lua interface. Could someone check them? It would be great to have them in the next development branch release. 2750: Lua dissectors cannot handle 64 bit integers properly https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2750 1965: playing around with lua dissector https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1965 Cheers, Balint ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Pending patch for #2385 (was: Re: pending patches)
Hi, Could someone check the smaller one, too? The tiny patch feels itself alone. :-) 2385: saving preferences does not handle multiline descriptions properly http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2385 Cheers, Balint 2008. 05. 26, hétfő keltezéssel 13.13-kor Bálint Réczey ezt írta: Hi, I have two pending patch requests without any comments for a few weeks. Could someone check them?: 2385: saving preferences does not handle multiline descriptions properly http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2385 2543: handle LAPD over RTP http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2543 Cheers, Balint ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Lua dll is outdated in windows binaries
Hi, It seems, that the Lua dll bundled with the windows installer is not the latest stable version: [EMAIL PROTECTED]:~$ strings ~/.wine/drive_c/Program\ Files/Wireshark/lua5.1.dll | grep 5.1 $Lua: Lua 5.1 Copyright (C) 1994-2006 Lua.org, PUC-Rio $ lua5.1.dll Lua 5.1 [EMAIL PROTECTED]:~$ strings Downloads/lua5.1.dll | grep 5.1 $Lua: Lua 5.1.2 Copyright (C) 1994-2007 Lua.org, PUC-Rio $ Lua 5.1 lua5.1.dll Could it be replaced with the latest one? Regards, Balint ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] additional lua dissector preference types
Hi, Is there anything i could do to help this patch's inclusion in the svn repo? Regards, Balint 2007. 04. 27, péntek keltezéssel 13.28-kor Balint Reczey (IJ/ETH) ezt írta: Hi, The attached patch adds ability of of creating radio button, drop-down list and range type preference entries to the Lua plugin. It also fixes a lua compile warning/error in wslua_gui.c. The patch is written by Tamas Regos, he asked me to send it to the list. Could someone commit it to the svn repo? Cheers, Balint ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] native little endian ipv4 decoding function for the lua plugin
Hi Luis,
Thanks, it works perfectly.
I would like to handle the rare situation of Little Endian encoded
IP addresses, so i added a function which reads the address with
tvb_get_ipv4(), then swaps the bytes before SET_ADDRESS().
Could you commit it, too?
Regards,
Balint
From: Luis Ontanon [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 21:27:48 +0200
Well I replaced tvb_get_ntohs() with tvb_get_ipv4().
Balint:
Can you test the changes to tvbrange:get_ipv4() in your code and
verify that this works for you as well.
The revision is:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21385
Index: epan/wslua/wslua_tvb.c
===
--- epan/wslua/wslua_tvb.c (revision 21388)
+++ epan/wslua/wslua_tvb.c (working copy)
@@ -702,6 +702,30 @@
WSLUA_RETURN(1); /* the IPv4 Address */
}
+WSLUA_METHOD TvbRange_get_le_ipv4(lua_State* L) {
+ /* get an Little Endian IPv4 Address from a TvbRange. */
+
+TvbRange tvbr = checkTvbRange(L,1);
+Address addr;
+guint32* ip_addr;
+
+if ( !tvbr ) return 0;
+
+ if (tvbr-len != 4)
+ WSLUA_ERROR(TvbRange_get_ipv4,The range must be 4 octets long);
+
+addr = g_malloc(sizeof(address));
+
+ip_addr = g_malloc(sizeof(guint32));
+*ip_addr = tvb_get_ipv4(tvbr-tvb,tvbr-offset);
+*((guint32 *)ip_addr) = GUINT32_SWAP_LE_BE(*((guint32 *)ip_addr));
+
+SET_ADDRESS(addr, AT_IPv4, 4, ip_addr);
+pushAddress(L,addr);
+
+ WSLUA_RETURN(1); /* the IPv4 Address */
+}
+
WSLUA_METHOD TvbRange_get_ether(lua_State* L) {
/* get an Ethernet Address from a TvbRange. */
TvbRange tvbr = checkTvbRange(L,1);
@@ -769,6 +793,7 @@
{le_float, TvbRange_get_le_float},
{ether, TvbRange_get_ether},
{ipv4, TvbRange_get_ipv4},
+{le_ipv4, TvbRange_get_le_ipv4},
{string, TvbRange_get_string},
{bytes, TvbRange_get_bytes},
{tvb, Tvb_new_subset},
___
Wireshark-dev mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [Patch] native little endian ipv4 decoding function for the lua plugin
Hi,
The attached patch adds ability of reading Little Endian encoded IPv4
addresses to the Lua plugin.
Could someone commit it to the svn repo?
Cheers,
Balint
Index: epan/wslua/wslua_tvb.c
===
--- epan/wslua/wslua_tvb.c (revision 21381)
+++ epan/wslua/wslua_tvb.c (working copy)
@@ -702,6 +702,29 @@
WSLUA_RETURN(1); /* the IPv4 Address */
}
+WSLUA_METHOD TvbRange_get_le_ipv4(lua_State* L) {
+ /* get an Little Endian IPv4 Address from a TvbRange. */
+
+TvbRange tvbr = checkTvbRange(L,1);
+Address addr;
+guint32* ip_addr;
+
+if ( !tvbr ) return 0;
+
+ if (tvbr-len != 4)
+ WSLUA_ERROR(TvbRange_get_ipv4,The range must be 4 octets long);
+
+addr = g_malloc(sizeof(address));
+
+ip_addr = g_malloc(sizeof(guint32));
+*ip_addr = tvb_get_letohl(tvbr-tvb,tvbr-offset);
+
+SET_ADDRESS(addr, AT_IPv4, 4, ip_addr);
+pushAddress(L,addr);
+
+ WSLUA_RETURN(1); /* the IPv4 Address */
+}
+
WSLUA_METHOD TvbRange_get_ether(lua_State* L) {
/* get an Ethernet Address from a TvbRange. */
TvbRange tvbr = checkTvbRange(L,1);
@@ -769,6 +792,7 @@
{le_float, TvbRange_get_le_float},
{ether, TvbRange_get_ether},
{ipv4, TvbRange_get_ipv4},
+{le_ipv4, TvbRange_get_le_ipv4},
{string, TvbRange_get_string},
{bytes, TvbRange_get_bytes},
{tvb, Tvb_new_subset},
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
