Remember settings on application closure

[Nyalnara]

Hello there!

It would be awesome if the app could save settings, both for what adapter is being listened to and what are the filters applied (because most people won't keep switching between network adapters), and also any modification done in the settings pop-in, since at the moment none of that persists through the app closure. (Also I'd love to be able to set where the sniffnet_report folder should be.)

Basically that would mean looking up a setting file somewhere predefined like ~/.sniffnet on app startup and loading whatever values are written on initialisation, creating it with default values if absent, and writing to it on inspection start (maybe add a checkbox remember this setting so that it is not automatically saved for people actually using multiple adapters), and on either modification or exit on the settings pop-in.

Thanks for reading, and also thanks for the awesome app!

[GyulyVGC]

Hey @Lysarion, thanks for the very detailed issue!

I have some good news already:

• the settings of the pop-up (notifications, style, and language) was already meant to be saved in v1.1.0; please, try closing settings touching a point on the background and let me know if they are actually saved. There was a bug causing settings not to be saved when closing the pop-up from the 'x' button on the top right corner, but it has already been solved with 2705b54 and the fix will be published in the next release
• I already implemented adapter-remembering (55eee9f) and it will be introduced in the next release as well; the application will save and remember an adapter without the need of specifying it, it will always remember the last adapter for which some packets were successfully sniffed by the user
• I also worked on the output folder of the report and, following the suggestions mentioned in thread 'thread_write_report' panic when run not as root. additionally, it'd be nice to save report file in a fixed location independently from running directory. #51, I decided to save it in a fixed location which is coincident of that of the configuration files used for remembering the settings and the adapter. Every time the inspection is restarted, the file is overwritten and if you'd like to save the file of a particular inspection you just have to open it and save it wherever you want. I would appreciate having a further discussion on this point with you though.
• For what concerns filters, I still have not saved them into a configuration file but I could consider it. Also for this point, don't hesitate to share your thoughts.

[Nyalnara]

Can confirm the settings not being saved was me clicking the X button.

For some reason my report is generated in C:\Windows\System32\sniffnet_report\report.txt, it's running as admin from C:\Program Files\sniffnet\bin\.
As for report retention, I'd probably just append to the current file (as each line is timestamped anyway) but that's only logical to do so if the same adapter is being monitored, or include in the filename the timestamp for the current session.

[GyulyVGC]

I think that most users are interested in monitoring the traffic in real-time (through the GUI) rather than a posteriori (through the textual reports).

For this reason I think that generating a different report for each session or a single huge report common to all sessions would be just a waste of memory for the vast majority of users.

[Nyalnara]

Can confirm that's my case too, I mostly see sniffnet as a good Glasswire replacement (as the free feature-set of Glasswire is pretty bare, and the default color-scheme they use is horrendous).

About that, I'd point the fact that the non-GUI part could be started in a minimized state rather than it's own independent window, to reduce clutter.

[GyulyVGC]

About that, I'd point the fact that the non-GUI part could be started in a minimized state rather than it's own independent window, to reduce clutter.

I will see if I can do something about that.

[GyulyVGC]

Settings configurations problems have been solved and published in today's release.

I moved your last advice in a new issue: #85.

[GyulyVGC]

About that, I'd point the fact that the non-GUI part could be started in a minimized state rather than it's own independent window, to reduce clutter.

A new release solving this issue has just been published!