Hello, I am developing a custom protocol dissector plugin and I have a scenario wherein I need to modify a preference for my custom protocol through the dissector. I am able to modify the value of a preference through the dissector by either directly modifying the preference variable or by using Is there any possibility to trigger the process of storing the modified parameters to the preferences file through a custom dissector? Any help/suggestion is greatly appreciated. Thanks in advance. asked 07 Dec '16, 07:07  sherlock_000 |
One Answer:
Is there some reason why you wouldn't want to use Wireshark's existing profile mechanism? That lets the user have multiple profiles, which cover all Wireshark preferences, so the user could set the preferences for various dissectors, including your custom dissector, to values appropriate in some cases, save that as a named preference, and, if they're analyzing a file that requires different settings, they'd change the preferences again and save the setting as a different named preference. Then they could select the appropriate preference for each file they read. answered 08 Dec '16, 14:11  Guy Harris ♦♦ Your suggestion seems good. There is no specific reason why I didn't want to use the existing profile mechanism. But it seemed more appropriate to have the option as part of the preferences within the custom protocol section. So is it never allowed to modify a preference from the dissector code? And I was also thinking, will an "Apply" button in preferences UI be useful in such a scenario? However, I have tried the "Apply" button in Gtk version of Wireshark, and that doesn't seem to reflect the modifications done to the preferences through the dissector code. (09 Dec '16, 00:35) sherlock_000
Not if you want the changes saved. There's no form of magic that detects stores into preference variables and causes the preferences to be saved, and If the idea is that the protocol has some "profiles" such that several preferences should have particular values with that profile, then there are a couple of possibilities: 1) if there are no interesting values for those preferences other than the ones for the profile, you could just get rid of the other preferences and have just the profile preference; 2) if it's useful to have most, but not all, of the preferences in the question set to the appropriate value for the profile, you might be able to have one of the possible values for each of those preferences be "use the default value for the profile". (09 Dec '16, 01:25) Guy Harris ♦♦ I am not able to understand your second suggestion. You mean to say that one of the possible values for each preference that might be dependent on profile could be "use the default value for the profile"? If so, then this might be only applicable to enum preferences, but I am also using string and UINT preferences. (09 Dec '16, 07:13) sherlock_000
@Guy Harris : I think I might be using your suggestion, so could you please mark that as an answer? (15 Dec '16, 06:23) sherlock_000 |
Do you mean that the preference is modified by code in the dissector, not the the user?
The default value for the preference will be set by the user, but it might be modified by the dissector code too.. This is because some of the fields in preferences might also be seen in the actual protocol communication and if the values in the actual messages are different, then they have to be used as reference for future messages. Is my reasoning understandable?
I think that's a bit odd, why should the dissector be able to change a persisted preference, overriding a users settings?
If the dissector is free to ignore preference settings and modify its behaviour dynamically based on packet content, then maybe those values shouldn't be preferences as the users wishes are being ignored or overridden.
So are you saying that the dissector whose preference you want to modify might have the way its dissection modified either by 1) the user explicitly specifying "dissect it this way" via a preference or by 2) some earlier packet, dissected by your custom dissector, or the same packet, with a lower layer dissected by your custom dissector and a higher level dissected by the other dissector, specifying something in its contents indicating that the other dissector's protocol should dissect packets in a particular way?
Or perhaps the custom dissector is the one modifying its own preferences?
Sorry, but I made a mistake in my previous comment about changing the preferences based on packet content. The dissector will not change the preferences based on packet content, but it will just inform the user through expert info that the values are different and use the new value within the dissector for further dissection. Sorry again for a misleading comment!
Now coming back to my initial question, the reason behind modifying the preferences through the dissector code is as follows. There are several preferences related to the custom protocol and I would like to provide the user with the possibility to change all of them at once (by having a separate drop-down preference that has different profiles corresponding to each set of values). Currently, when the user selects a profile option from the drop-down box and selects OK, the custom dissector will update the relevant preference values directly from the code. Even though the preference values are updated, they are not stored to the preferences file. To store it, the user has to open the protocol preferences and again select OK. Only then, the actual values are being stored.
It would be really helpful to know how to achieve the scenario that I have described above without the user having to open preferences again and selecting OK.
@Guy Harris: Yes, the custom dissector is the one modifying its own preferences