Wireshark upgrade 4.4.3
Hi @dehydr8
Thank you so much for your work on Wiregasm!
We attempted to upgrade using the feat/wireshark-update branch but ran into a couple of issues:
-
Patch issue: One out of one hunk failed, resulting in a reject file:
cmake/modules/FindLEMON.cmake.rej -
Missing dependency: If we comment out the failing patches, we encounter an error stating that
wireshark_common is not found.
I would appreciate any guidance on resolving these issues.
Thanks in advance for your help!
Hi @dipeshwalia, I can look at it over the weekend and try to debug what the issue is.
From what I recall, I was able to build it successfully at the time with the updated version.
Thank you @dehydr8
Hi @dipeshwalia
The branch builds just fine, here's what I tried:
# on a fresh clone, checkout the branch
git checkout feat/wireshark-update
# build the library (using the docker builder)
npm run build:emscripten
# install the required deps
npm ci
# validate everything works
npm run test
Can you try again and see if it works for you on a fresh clone?
Ignore my previous comment, I somehow missed that you were trying to upgrade to 4.4.3.
The feat/wireshark-update only works for 4.2.5 or might work for patch bumps.
Interesting, thank you. Any idea what might be done to make this work with 4.4.x
I was able to build the lib with a modified patch, but it fails during runtime. I'll investigate more and will update you.
@dipeshwalia I was able to get it working, the runtime error was caused by report_message_routines not being defined as the lua plugins weren't being loaded correctly.
A note on upgrading wireshark versions: Our patches might conflict/break if something changes in the same file the patch is being applied to, so it's tricky for every update.
Try out the code in feat/wireshark-update-4.4.5 and see if it works for you.
The way lua plugins are loaded has changed between 4.2.5 <> 4.4.5, it now adds extra arguments (plugin name, path) when loading it, which was causing it to error out. And since the error routine wasn't defined, it was crashing instead of reporting the error.
Wow, thanks @dehydr8! I've been working on integrating some of the code from wireshark/file.c for find packet functionality:
Working with code from v4.4.5 is way nicer. However, the color filters don't seem to be working correctly - the frames returned by getFrames() now have an fg of 0 and bg of 1.
Working with code from v4.4.5 is way nicer. However, the color filters don't seem to be working correctly - the frames returned by getFrames() now have an fg of 0 and bg of 1.
Hi @radiantly, you're right. The color filters are indeed broken. We never had tests to cover if the filters work which is why it went unnoticed.
I investigated briefly and the lib does appear to load the color filters correctly and prepares everything, the colorfilters file does exist and gets loaded correctly:
// prepares the frame for colors
if (dissect_flags & WG_DISSECT_FLAG_COLOR)
{
color_filters_prime_edt(&edt);
fdata->need_colorize = 1;
}
...
// fdata->color_filter doesn't get set after the frame is done processing, which is why you see the default values
if (fdata->color_filter)
{
f.bg = color_t_to_rgb(&fdata->color_filter->bg_color);
f.fg = color_t_to_rgb(&fdata->color_filter->fg_color);
}
This needs more investigation. I'll keep you updated.
hi @dehydr8
While debugging an issue related to setPref, I noticed that the API does not throw any errors. However, the expected result is not produced. This functionality works as expected in version 4.0.x
I’m not sure how to proceed with further debugging. Any insights, suggestions, or guidance on how to investigate this would be greatly appreciated.
Hi @dipeshwalia
Is there a way to reproduce the issue you're facing?