On May 22, 2021, at 1:46 PM, Vincent Randal <vtrandal@xxxxxxxxx> wrote:
> On Sat, May 22, 2021 at 3:51 AM Guy Harris <gharris@xxxxxxxxx> wrote:
>> On May 21, 2021, at 8:03 PM, Vincent Randal <vtrandal@xxxxxxxxx> 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