WireShark Linux Ubuntu 22.04

[dfdias]

Hello

When I try to open a capture file there is a dissector problem at Lua: Error during execution of initialization: /home/duarte/.local/lib/wireshark/plugins/v2gmsg.lua:133: bad argument #2 to 'add' (DissectorTable_add: must be either Proto or Dissector)

/home/duarte/.local/lib/wireshark/plugins/v2gmsg.lua: attempt to index global 'p_v2gmsg' (a nil value)

I know the windows version works, so do you have any reports in similar problems ?

Thanks in advance.

[barsnick]

Same here. I get it as a modal popup (which hides some of the message), with another message popup on top. But the dissector does seem to work.

Did you get it to work with Wireshark 4.2? I needed to change a lot of code for the binary plugin to load properly.

[TGruett]

Hi,

I have tried to reproduce your errors on a clean Ubuntu 22.04 installation, but everything works perfectly for me. I have tried using Wireshark 3.6.2 from the default apt sources and I also tried Wireshark 4.2.4 (built locally via 'cmake .. && make install'). The only things I have come up with are the following:

• Make sure that the Wireshark installation is compiled with Lua, GnuTLS and LibXML2. You can check this in the "About Wireshark" Window. If you have built the Wireshark installation locally, make sure the corresponding packages are installed ('sudo apt install liblua5.2-dev libgnutls28-dev libxml2-dev') before running 'cmake'
• Make sure you have at least read permissions for all .lua and .so files
• For now, the .so files have to be placed in the execution directory of Wireshark. For example, if you have copied the .so files into '/usr/lib/x86_64-linux-gnu/wireshark', make sure you run the wireshark binary in exactly that directory. Alternatively, you can put the *.so files in one of the following directories (and again, make sure you granted read permissions!):
  • '/usr/local/lib/lua/5.2/'
  • '/usr/lib/x86_64-linux-gnu/lua/5.2/'
  • '/usr/lib/lua/5.2/' We are working on a better way to handle the *.so files for the next release.

If any of this helps you with your problem, i'll be happy about some feedback. Otherwise, could you provide me some more details about your full setup and captured file?

[TGruett]

UPDATE: if finally managed to get the same error message: ~/.local/lib/wireshark/plugins/v2gmsg.lua:133: bad argument to 'add' (DissectorTable_add: must be either Proto or Dissector)

This only seems to happen if you put the .lua file in the ~/.local/lib/wireshark directory. I've tested the Linux plugin version by putting the .lua files in /usr/lib/x86_64-linux-gnu/wireshark or /usr/local/lib/wireshark (whatever $whereis wireshark told me).

I will take a closer look at this, but for now i recommend to remove the files from the ~/.local/lib/wireshark and use the "Global Lua Plugins" directory. You can find the specific path in the Wireshark GUI -> Help -> About Wireshark -> Folders.

[barsnick]

This only seems to happen if you put the *.lua file in the ~/.local/lib/wireshark directory.

Interesting, I would never have guessed this. Same for the shared objects - these can usually be located in ~/.local/lib/wireshark/plugins.bak/{3.6,4.0}/epan/, making it a classical "plugin", unlike an integrated dissector. Using this location does not work for the libraries in your binary package (at least for Wireshark 4.x) or compiled from source, as these "local" binaries require additional symbols. (I have a local patch for that.) It would be great to be able to use this like a classic plugin (just through the files into these user-owned locations).

[TGruett]

If you add the additional (dummy?) symbols to the binaries, doesn't it make the binaries Wireshark version dependend (like 'classical plugins')? This was actually the reason i have not done that

[barsnick]

I'm thinking in terms of being able to compile and install something as a user without system privileges. That's why I'm aiming at this approach. (Install wireshark-dev or wireshark-devel, make, copy to ~/.local/ as a process. I consider having to install to /usr as root a hack.)

In terms of distributed "generic" binaries, you're probably correct regarding 3.x vs. 4.x and the Wireshark API - you would have to distribute different binaries. I don't see an issue though using a plugin compiled against e.g. 4.0 with 4.2.x. (I don't actually know whether you can make 4.x plugins binary compatible with 3.x. I looked into Wireshark plugins a lot when reviewing CHARGEPOINT's, but my knowledge is mostly Google and trial-and-error.)

Yes, that would imply different conditional code paths and compile paths (and CI workflows). Not sure you want to go that path. 😉

[TGruett]

Fixed in Release 1.3.1

[dfdias]

Thanks Mates :) well done :+1: