Question about the report.txt file in Linux : still there ?

[Alex47260]

Is there an existing issue for this?

• I have searched the existing issues.

What's the problem?

Hi Giuliano,

Thanks very much for developing Sniffnet : it's a great tool, and I have been a keen user of this software on Linux for some time now :)

The introduction of the pcap recording has been a very good feature too, and it's easy and practical to use. My question pertains to the report.txt file that could be previously produced before the pcap. Is it still there or possible to have it produced ?

I am running Sniffnet on Fedora and I used to be a fan of those report files.

From what I can see, there is still a report.txt in /home/.config/sniffnet but the file seems to remain empty. Checked also the Wiki Sniffnet (and the Master thesis), read through the issue - including issue #77 but it looks that the question hasn't been asked yet (or maybe no one has met the same issue ?)

Your insights would be most welcome!

Cheers,

Alex

How did you install the app?

downloaded one of the provided packages

Operating System

Linux

Additional context

No response

[GyulyVGC]

Hi @Alex47260, I really appreciate your kind words.

As you mentioned, no one asked this specific question in the past months, and this isn't even very well documented.
I only included a note about it in the CHANGELOG for v1.3.0, but I will definitely include this also in the Wiki FAQs.

To answer your question – no, there isn't a way to generate the textual report in the 1.3.x versions of the app, and the report.txt file you still have is there because it was generated from previous versions of the application.

It was a hard decision, but in the end I decided to replace it with PCAP which is a well known and standardised format.
Under these circumstances, I thought there was no point to keep also producing the textual file.
I've always considered the textual report as a workaround and to be honest I didn't like it that much because it was difficult to read/parse/interpret.

Feel free to let me know your thoughts about it.

[GyulyVGC]

Added the answer to this question in the FAQs.

[Alex47260]

Hi @GyulyVGC , many thanks for your swift reply!

Well, well, that's a kind of sad then :-/ My thoughts are that this report is actually a powerful feature, and that it complements a pcap capture very well.

As you mentioned it in the wiki, a pcap file provides much insight but the files can become quite big too, and fill a disk. This makes it something that users start for rather short moments or specific operations, in addition to the live GUI.

The report.txt, in contrast, are light weight but provide interesting information that can be collected for the whole day, and kept as logs (eg 7 rolling days). This can be very helpful for instance both for network monitoring or cybersecurity. And again, the size of it makes it very easy to record and store it - personally, I don't have a report.txt that reaches 1Mb, but I suppose that even active users (eg SOHO) wouldn't get daily files that exceed a few Mb, making it very manageable.

Would something such as getting a second tick-box (back) would be an option? Or maybe a setting that enables users to produce these files in the background (either up to user to chose how many rolling days they want, or just to have the file produced or not).

And I agree with you too when you wrote that people are interested in the live GUI : personally, Sniffnet runs almost always, in the background or on a second screen :)

[GyulyVGC]

As you said PCAP files are way bigger.
You probably know why, but I want to make sure we are on the same page: while a PCAP file registers every single packet separately, the old textual report was agglomerating packets grouping them by network 5-tuple (i.e., source IP and port, destination IP and port, and transport protocol).
Most of the packets nowadays are encrypted so actually registering every single packet as PCAP/Wireshark is doing most of the times doesn't add much information and ends to be overwhelming.
And this is also the concept around which I built Sniffnet: for the reason previously stated, the app wants to represent network data grouped by connection/host/protocol.

Something I forgot to mention is that the current Inspect page is what is really taking place of the textual report; in fact, such table reports in GUI the same exact structure of the old report file – the difference is that now you can easily sort it, filter it, and examine more in detail each entry by clicking on it.

That being said, this is the real reason why I removed the txt report generation: because it felt to me that the Inspect page is an improved version of it.

Anyway, I also understand that you may be interested in having reports of past captures available.
I have a question for you: did you use to duplicate the textual report generated by Sniffnet to have a copy of the data?
In such case, yes: you are right in saying that currently that functionality is missing.
But if you weren't duplicating the file in another directory, it would've been overwritten by the next run of the app, thus making it pointless in maintaining that feature because you already have the aforementioned table directly in GUI.

A possible solution for you request that comes to my mind is to add a button in the Inspect page of the app to export the current table view (with or without filters and/or sorting applied) to a custom file; in this way we'd lose the ability to generate it automatically but at the same time it'd be more powerful since it'd allow to save a version possibly filtered and sorted according to different criteria.

[Alex47260]

Hi @GyulyVGC, great response, thanks again for responsiveness!

About the pcap and the concept behind Sniffnet, fully in sync with your approach again : providing an easy-to-read set of network data grouped by connection/host/protocol is a powerful tool.

I also use the Inspect panel, and often drill into the host data : btw, the country/ASN data a just great information to figure out what kind of network traffic is really going on.

The Inspect panel is also fine to get further insight and pick a service to view related connections : eg. what's happening to my computer's NTP? or why is the DNS not responding?

So, indeed, the Inspect panel provides great insight, and in live mode compared to the report.txt. And if it were possible to press a button and export the Inspect panel data to get the enriched 5-tuple formerly provided by Sniffnet, that would be great. Just adding something that is probably obvious : the report exported from the Inspect panel would also benefit to include the timestamps (start/end), such as it was in report.txt (not easy to display that information on a screen, but in the file it should be ok).

This timestamp topic leads me to the point you made about the former report.txt file that could be erased by the following report if you didn't rename it, is that what you meant?

If yes, I know that topic too, as that caused me a few "Oh noooo!" moments :-D when I forgot to rename the previous report.txt which got erased by the following one. Actually, this was the only thing that I would have thought to modify back then in Sniffnet: eg. would it have been possible to make it error-proof so that the name of the report.txt be automatically produced, including the start timestamp (kind of YYYY-MM-DD_HHMM_report.txt or something like the format of the "'initial timestamp" from the report.txt )?

In a nutshell, with an export button in the Inspect panel, that would be fantastic! :)

Cheers,

Alex

[GyulyVGC]

This timestamp topic leads me to the point you made about the former report.txt file that could be erased by the following report if you didn't rename it, is that what you meant?

Yes, exactly.

If yes, I know that topic too, as that caused me a few "Oh noooo!" moments :-D when I forgot to rename the previous report.txt which got erased by the following one. Actually, this was the only thing that I would have thought to modify back then in Sniffnet: eg. would it have been possible to make it error-proof so that the name of the report.txt be automatically produced, including the start timestamp (kind of YYYY-MM-DD_HHMM_report.txt or something like the format of the "'initial timestamp" from the report.txt )?

Now it makes sense, if you're used to save past capture data and at the same time you don't want the size bloat of a PCAP, having textual reports is the best solution.
If I'll end up introducing a button to export data to a custom file, there shouldn't be the need to include a timestamp in the file name because while exporting users could directly define the file name they want.

The only pitfall is that since it's not an automatic process, users should remember to export the file otherwise the data would be lost.
But I think it's reasonable since I believe most of the times users aren't interested in such an export and are just "playing around", but when more attention is needed, they would be free to export data.

[Alex47260]

Hi @GyulyVGC ,

Thanks for your follow up.

The only pitfall is that since it's not an automatic process, users should remember to export the file otherwise the data would be lost.

In sync, that's why I think a timestamp+"sniffnet_report.txt" could mitigate loss of data - especially when it might be started in a hurry to observe some events - but still, it should be manageable as it is currently with the naming of pcap captures.

But I think it's reasonable since I believe most of the times users aren't interested in such an export and are just "playing around", but when more attention is needed, they would be free to export data.

Exactly, that would enable a focus when needed, and get the 5-tuple from the Inspection panel in cases the pcap capture wasn't started and more information would be useful.

Cheers,

Alex