Does 4.0.4 Provide Backwards Compatibility for Plugins/Stats?

asked 2023-03-08 17:26:00 +0000

updated 2023-03-08 17:34:28 +0000

Developing a plugin that has previously worked on 3.6.x and 4.0.x.

I develop on the latest release-x.x branch, on windows and on linux (so that's 4 total plugins).

After 4.0.4 update, I noticed that the statics info I've included in my plugin now only works when it's installed to a Wireshark version v4.0.4, anything older like v4.0.3 will open and dissect, but opening stats for this protocol from the statistics menu crashes

I've noticed this is _only_ on windows and not on linux at all. Also that this is happening between 3.6.12 and 3.6.11 and prior (so stats works for 3.6.12, but not prior).

Sum up my question(s): 1. Is backwards compatibility guarenteed between micro versions? Any 3.6.x plugin should work on any 3.6.x wireshark? 4.0.x plugin will work on any 4.0.x wireshark? 2. Any reason why stats would be breaking only for versions prior to 4.0.4? (and 3.6.12)

Thanks in advance!

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2023-03-09 23:07:50 +0000

Guy Harris
19890 ●3 ●659 ●207

updated 2023-03-09 23:08:47 +0000

Is backwards compatibility guarenteed between micro versions

It's supposed to be, as noted by @Jaap.

Unfortunately, it's not guaranteed to be, as non-compatible changes may unintentionally be made. As @Carl Robert noted, a non-binary-compatible change was made between 4.0.3 and 4.0.4 - a field was added to the middle of a public data structure, which means that any code that depends on the offsets of any fields that are after the inserted field will not work.

edit flag offensive delete link

Comments

That change/bugfix was made by me, overlooking the ABI compatibility. I have reverted the changes for 3.6 and 4.0 (and the change/bugfix will be available in 4.2) to restore ABI compatibilty as soon as the next 3.6 and 4.0 maintenance releases will come out.

Sorry for the inconvenience!

SYN-bit ( 2023-03-13 20:31:11 +0000 )edit

Can you tell me if this issue affects SMTP or IMF protocols?

jlshuman1961 ( 2023-04-05 16:55:00 +0000 )edit

Can you tell me if this issue affects SMTP or IMF protocols?

It does not affect any dissectors - built-in or plugin - that come as part of Wireshark, as they are all recompiled for every release. If you're using Wireshark's built-in SMTP and IMF dissectors, this should not cause any problem if you are using 4.0.4.

It would affect any plugin dissector that's not part of Wireshark and that it provided in binary form and that either fetch fields from the frame_data structure if those fields were after the newly-inserted dependent_frames field or depend on the size of the frame_data structure. That's what happened with @robinuser1's plugin.

Guy Harris ( 2023-04-06 06:29:15 +0000 )edit

As per your other question, you're not using Wireshark's built-in SMTP and IMF dissectors, you're using your own modified SMTP and IMF dissectors.

The problem still isn't one that has anything to do with those protocols, it has to do with dissectors that look at the frame_data structure (i.e., uses the fd variable to point to any field other than num, pkt_len, cap_len, cum_bytes, file_off, or pfd - for example, if it uses fd->visited, it would stop working correctly - or depends on the size of that structure). If your modified SMTP or IMF dissectors did so - whether they did so because the Wireshark built-in dissectors did so and you didn't remove that code, or because you added code to do so - then they would break.

Wireshark's own built-in SMTP and IMF dissectors didn't break because they were recompiled as part of the process ...(more)

Guy Harris ( 2023-04-06 06:52:25 +0000 )edit

add a comment

answered 2023-03-09 16:47:16 +0000

Carl Robert
1 ●1

I also encountered the problem that a plugin developed for 4.0.3 causes a crash of Wireshark 4.0.4. The problem was caused by the new item "dependent_frames" of the struct "_frame_data" in file "epan\frame_data.h"

edit flag offensive delete link

Comments

...and that's the field that we removed in 4.0.5, by backing out the changes that added that field. (I don't know what bugs that this fixed in 4.0.4 will become un-fixed in 4.0.5 as a result, but sometimes there's a tradeoff between binary compatibility and bug fixes; this is why some APIs/ABIs involve opaque data structures whose members are fetched by accessor routines.)

Guy Harris ( 2023-04-06 06:23:40 +0000 )edit

add a comment

answered 2023-03-08 22:22:13 +0000

Jaap

13742 ●711 ●115

Compatibility between micro versions is part of our release policy
It could be that your code is triggering a bug that has been fixed in 4.0.4 (and 3.6.12)

edit flag offensive delete link

Comments

Thanks Jaap! Very helpful, I'm investigating based off your lead now.

My guess is likely wmem related -> any idea why that might only occur on linux and not on windows? I could understand if there was such a bug on wireshark that my plugin triggered, but why would that cause crash on windows only, and not linux?

robinuser1 ( 2023-03-09 03:35:49 +0000 )edit

Once you realise that Windows and Linux are totally different beasts 'under the hood', you may appreciate that certain bugs on one platform manifest themselves very different on the other. This even goes so far that we had to have certain code specifically written toward these platforms (ie., Win32 and !Win32). How that results in your scenario is very much depending on the bug. Without debugging the code (and your code) this is impossible to predict.

Jaap ( 2023-03-09 06:13:20 +0000 )edit

No problem, thank you again for the great help

robinuser1 ( 2023-03-09 14:46:36 +0000 )edit

add a comment