On May 22, 2021, at 1:46 PM, Vincent Randal <vtran...@gmail.com> wrote:
> On Sat, May 22, 2021 at 3:51 AM Guy Harris <ghar...@sonic.net> wrote:
>> On May 21, 2021, at 8:03 PM, Vincent Randal <vtran...@gmail.com> wrote:
>>
>>> 1. Before running cmake how can I tell the appropriate "with-lua" sort of
>>> switch is enabled?
>>
>> By making sure that the appropriate package for Lua is installed. That's
>> liblua5.2-dev.
>>
>> The easiest way to make sure it's installed is to run
>>
>> tools/debian-setup.sh --install-optional
>
> Thank you. Graham had the same suggestion. This helped tremendously. I was
> doing it the hard way trying to manage dependencies myself.
The UNIX section (which should perhaps be called "UN*X" or "UNIX and
UNIX-like", as it also applies to systems such as most Linux distributions and
the *BSDs that aren't licensed for the UNIX trademark):
https://www.wireshark.org/docs/wsdg_html_chunked/ChapterSetup.html#ChSetupUNIX
has been expanded recently to give ore instructions on setting up a development
environment (it's not quite at the "IKEA motorcycle engine", to quote our
illustrious founder, level that Windows is at, but it *does* involve some work
for which we should and now do give some help).
It mentions the "set up the development environment scripts" for
Debian-flavored Linux distributions, RPM-based Linux distributions, Alpine
Linux, the *BSDs, and macOS.
>>> 3. If it does not find Lua how do I fix that?
>>
>> Make sure liblua5.2-dev is installed. (If you've already run CMake before
>> running tools/debian-setup.sh --install-optional, you *might* have to remove
>> the directory in which you ran it, create a new directory in which to do the
>> build, and re-run CMake, so that there isn't any cached "sorry, I didn't
>> find Lua" indication left around.)
>
> Thank you. I did have to remove the build directory and re-run cmake in a
> fresh new (empty) directory.
CMake leaves a bunch of cache information around so it doesn't redo tests that
it's already done and that "shouldn't" give different results when redone; if
you change things that CMake doesn't realize *will* change those results, it
won't retry them.
There may be less "nuke it from orbit, it's the only way to be sure" solutions,
e.g. removing some specific cache files.
>>> 4. When the build succeeds how do I compensate for the difference sudo and
>>> non-sudo seem to have on tshark? Non-sudo invokation runs my lua scripts.
>>> Sudo invocations don't.
>>
>> Don't run with sudo. You should *NEVER* run TShark or Wireshark under sudo.
>> To quote section 3.11.1 "Packaging Guidelines":
>>
>> ...
>>
>> Instead, run CMake with the option -DDUMPCAP_INSTALL_OPTION=capabilities.
>> Then, if you install Wireshark with "sudo cmake install", it will install
>> the dumpcap program with sufficient Linux capabilities to do capturing on
>> network interfaces.
>
> Thank you. That works. And -DDUMPCAP_INSTALL_OPTION=suid also seems to work.
It also works. If you don't care about capturing raw USB traffic,
-DDUMPCAP_INSTALL_OPTION=capabilities is sufficient, and doesn't grant dumpcap
quite as much privilege when it starts up (it relinquishes privileges as soon
as it can, but the less privilege, the better); annoyingly, the devices for
snooping raw USB traffic require root privilege (at least it's not as annoying
as macOS Big Sur, where it requires sufficient privilege *and* disabling System
Integrity Protection - I guess some vendors of USB peripherals asked Apple to
protect them from reverse engineers or something such as that).
>> 5. And assuming (with some help) I get past the above issues, how much
>> control can lua scripts expert over tshark and Wireshark?
>>
>> To see what Lua scripts can do, see Chapter 10 "Lua Support in Wireshark":
>>
>> ...
>>
>> If what you want to do is *not* there, then a Lua script probably *can't* do
>> it.
>
> Exactly. I should set my expectations accordingly. Thank you.
And if there's something you'd *like* it to be able to do, please file an
enhancement request as an issue at the Wireshark issue list:
https://gitlab.com/wireshark/wireshark/-/issues
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
