Re: [Wireshark-dev] [Wireshark-commits] rev 50560: /trunk/ /trunk/packaging/macosx/Resources/bin/: wireshark /trunk/packaging/macosx/: osx-app.sh /trunk/: configure.ac
On Sun, Jul 14, 2013 at 12:43 AM, wrote: > On OS X, set the rpath for executables to include > @executable_path/../lib as well as /usr/local/lib, so we can use @rpath > in the install names in the executables and libraries in the application > bundle. I get this warning when running dumpcap from /opt/local/bin, which makes dumpcap unusable for wireshark: dyld: warning, LC_RPATH @executable_path/../lib in /opt/local/bin/dumpcap being ignored in restricted program because of @executable_path I don't get the warning when running from build dir. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list 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 50560: /trunk/ /trunk/packaging/macosx/Resources/bin/: wireshark /trunk/packaging/macosx/: osx-app.sh /trunk/: configure.ac
On Jul 29, 2013, at 2:13 AM, Stig Bjørlykke wrote: > I get this warning when running dumpcap from /opt/local/bin, which > makes dumpcap unusable for wireshark: > > dyld: warning, LC_RPATH @executable_path/../lib in > /opt/local/bin/dumpcap being ignored in restricted program because of > @executable_path >From looking at the Mountain Lion dyld source, "restricted program" includes >"set-UID or set-GID program"; there's also a code-signing op for the csops() >system call to set a "restricted" flag for the process, but I'm not sure what >causes that to happen. I think a "restricted program" will also not have the library search process affected by the DYLD_ environment variables; in both cases, this is A Feature, intended to keep you from fooling set-UID/set-GID programs into looking in places *you* control for their shared libraries. This means that if dumpcap is to be set-UID or set-GID, it had better have the final location of the GLib libraries and libwsutil wired into it as absolute paths, so that those libraries can't move. One solution to this is not to have dumpcap be set-UID or set-GID on OS X. It's not that way by default; instead, the ChmodBPF startup item is installed and run to make the BPF devices readable and writable by the access_bpf group, and the user who installs Wireshark is put into that group. ___ Sent via:Wireshark-dev mailing list 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 50560: /trunk/ /trunk/packaging/macosx/Resources/bin/: wireshark /trunk/packaging/macosx/: osx-app.sh /trunk/: configure.ac
On Mon, Jul 29, 2013 at 12:06 PM, Guy Harris wrote: > One solution to this is not to have dumpcap be set-UID or set-GID on OS X. > It's not that way by default; instead, the ChmodBPF startup item is installed > and run to make the BPF devices readable and writable by the access_bpf > group, and the user who installs Wireshark is put into that group. Removing --enable-setuid-install from my configure was the solution. Thank you. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list 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] user-guide one html file is missing
This file is missing from: https://www.wireshark.org/docs/wsug_html/ I can download it, but having it online, I can EASILY read it with my chrome extension "table-of-contents": https://chrome.google.com/webstore/detail/table-of-contents-crx/eeknhipceeelbgdbcmchicoaoalfdnhi thank you -- Kaseluris.Nikos.1959 http://synagonism.net Synagonism = ALL winners, Antagonism = ONE winner ___ Sent via:Wireshark-dev mailing list 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] Cov-Build Failing on Fuzz Builder
On 7/28/13 1:16 PM, Evan Huus wrote: > I'm not sure why exactly, it seems to successfully link tshark, > wireshark and the other target binaries. Maybe this is another > side-effect of GTK3-by-default? > > Either way, the public stdio logs don't seem to indicate the actual > cause of the problem... It was producing a lot of errors similar to this: "/usr/include/gtk-3.0/gdk/gdkdisplay.h", line 54: error #1095: attribute "__deprecated__" does not take arguments GDK_DEPRECATED_IN_3_0_FOR(gdk_device_ungrab) ^ I added "#define GDK_DISABLE_DEPRECATION_WARNINGS" to the cov-build configuration, so hopefully it will work now. ___ Sent via:Wireshark-dev mailing list 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 50967: /trunk/epan/ /trunk/epan/: proto.c
Hi, On Sun, Jul 28, 2013 at 08:33:49AM -0400, Evan Huus wrote: > I was poking through this change and I noticed that all three places > that call proto_unregister_field (which is very inefficient at the > moment, possibly traversing the entire linked list twice) do so in a > loop for all their hfs, AFAIK they're doing proto_unregister_field() on user-defined fields, so just a continuous subset. > so I was wondering if it makes sense to > replace it with a proto_unregister_all_fields that just removes the > whole list? I'm not sure if we want to leave proto_unregister_field > around or not in case somebody actually needs it in the future - the > data structures aren't really designed for that operation. Just to note: I still plan to commit patch from: http://www.wireshark.org/lists/wireshark-dev/201307/msg00039.html saving 2 MB is nice (even if it's small fraction...) Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list 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] Remove hf_ variables
Hi, Is anyone attached to hf_ variables? ;) There's no real need of them, and we can just replace them with header_field_info structure. ___ Sent via:Wireshark-dev mailing list 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] Remove hf_ variables
Does this mean that all proto_tree_add_* calls would need to have &hf_name instead of just hf_name? I'm not attached to them in principle (and getting rid of them seems like it would be a performance/memory win) but your description is awfully vague... On Mon, Jul 29, 2013 at 4:12 PM, Jakub Zawadzki wrote: > Hi, > > Is anyone attached to hf_ variables? ;) > > There's no real need of them, and we can just replace them with > header_field_info structure. > ___ > Sent via:Wireshark-dev mailing list > 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 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] Remove hf_ variables
On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki wrote: > Is anyone attached to hf_ variables? ;) > > There's no real need of them, and we can just replace them with > header_field_info structure. I.e., pass a pointer to the relevant structure, rather than an array index into an internal array that can supply that pointer? I'm not sure there's a compelling reason (other than the effort involved in converting code) to keep the variables. ___ Sent via:Wireshark-dev mailing list 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] Remove hf_ variables
On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote: > > On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki wrote: > > > Is anyone attached to hf_ variables? ;) > > > > There's no real need of them, and we can just replace them with > > header_field_info structure. > > I.e., pass a pointer to the relevant structure, rather than an array index > into an internal array that can supply that pointer? Yes. > I'm not sure there's a compelling reason (other than the effort involved in > converting code) to keep the variables. Being devil's advocate I think there's no good reason to convert it. Saving few CPU cycles by not doing: - load variable into memory - avoid PROTO_REGISTRAR_GET_NTH() and some cycles on startup + max 2-3 MB less in binary doesn't seems like good deal against converting 90% of dissectors codebase :) ___ Sent via:Wireshark-dev mailing list 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] Remove ett_variables (was: remove hf_ variables)
On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote: > and some cycles on startup + max 2-3 MB less in binary doesn't seems like > good deal > against converting 90% of dissectors codebase :) Another idea, is to remove ett_ variables, it requires much less rewritting, some proof of concept: http://www.wireshark.org/~darkjames/remove-ett-vars.patch It looks uglier, and little bit strange for users (why '-' ?!). Still proto_register_subtree_array() works, so no API/ABI regression After converting all dissectors this will save something like 360 KB binary size + some CPU on start up. I'm not really fond of this 'compatilibity' #defines, so maybe removing them would be better. Ah, and we no longer catch 'yet another ett_ registration', of course we could pass 'base' index to function... ___ Sent via:Wireshark-dev mailing list 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] Remove hf_ variables
On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote: > On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote: > > > > On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki > > wrote: > > > > > Is anyone attached to hf_ variables? ;) > > > > > > There's no real need of them, and we can just replace them with > > > header_field_info structure. > > > > I.e., pass a pointer to the relevant structure, rather than an array index > > into an internal array that can supply that pointer? > > Yes. > > > I'm not sure there's a compelling reason (other than the effort involved in > > converting code) to keep the variables. > > Being devil's advocate I think there's no good reason to convert it. > Saving few CPU cycles by not doing: > - load variable into memory > - avoid PROTO_REGISTRAR_GET_NTH() > > and some cycles on startup + max 2-3 MB less in binary doesn't seems like > good deal > against converting 90% of dissectors codebase :) If we don't loose functionality, I'd probably like to get rid of the extra variables (both ett_ and hf_) as it makes coding a bit more convenient. In the ett_ case: currently expansion is done similarly for all elements using the same ett variable, how would that be done without these vars? Can you give a sample diff how a dissector would need to be changed? Also: What would be the migration plan: All at once or incremental? Ciao Jörg -- Joerg Mayer 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 Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
