WEB GUI

[backl1n]

Describe the solution you'd like A clear and concise description of what you want to happen.

if its possible to add web ui for use on server

[GyulyVGC]

The library I used to develop the GUI actually supports web. This is something I'm interested in but unluckily not in the short term, due to servers cost and to the fact that I'm giving precedence to the development of new functionalities for the native app. I'll leave this issue open and maybe one day it'll happen. Thanks for your suggestion!

[acolombier]

That would also be a feature very useful in my case - few servers I would benefit this application in.

I had a look at the library, and I am not sure this will be as straightforward as a few component are entangled within the GUI crate (e.g, the control of the packet capture )

I believe this could be achieved by serving an HTTP actix-web server that distribute the pre-build WASM interface on the root and serve an update websocket to tunnel stats from the server to the web client.

If that sounds good, I can get started with this under a web feature as it seems it isn't something you would be looking at. Long term, perhaps we could consider using command argument (clap-rs maybe?) to allow the two modes as part of the same binary.

[GyulyVGC]

You could start trying something if you really want to, but at the moment I cannot assure you that a web feature will actually be included in the next releases. Of course when the process will be mature and if the results will be satisfying, we could start collaborating and work on this feature together. I would definitely prefer having the two modes as part of the same binary by the way.

[backl1n]

2 mode in binary with you do choice with option when you execute the binary

[acolombier]

SGTM - and thanks for the fair warning. Most of all, I would like and try to do this in the start-of-the-art, I cannot promise it will be within the same binary at first. I would rather iterate on that piece of work and make sure every development decisions fit within what you have in mind/you would accept in the project.

[GyulyVGC]

SGTM - and thanks for the fair warning. Most of all, I would like and try to do this in the start-of-the-art, I cannot promise it will be within the same binary at first. I would rather iterate on that piece of work and make sure every development decisions fit within what you have in mind/you would accept in the project.

Sounds good to me, your help is very much appreciated. I'll be looking forward to your work, and you don't have to feel any pressure about it! Everything you do will be fine as long as it will be discussed together!

[matbgn]

Also very interested to run sniffnet on servers :smile:

[GyulyVGC]

Also very interested to run sniffnet on servers :smile:

Nice to hear! If you don't mind sharing, could you describe more precisely the scenario you have in mind for a possible usage?

[backl1n]

@GyulyVGC monitor all network traffic from this server sorry i dont see your message

[matbgn]

If the web version is available we have two options, either we could connect to the server IP + PORT like this http://192.168.1.X:9999 to quickly see traffic in its own perspective. Or we could be even be more minimalist on headless servers and use Carbonyl directly with http://localhost:9999 (see https://github.com/fathyb/carbonyl )

[backl1n]

I didn't understand well, I was talking about a web interface installed on a vm that can be checked from a client pc and that from this interface we can see all the network traffic machine by machine thanks to a data centralization @matbgn

[matbgn]

Describe the solution you'd like A clear and concise description of what you want to happen.

if its possible to add web ui for use on server

🤣 OK maybe to concise this time. Nevermind ignore my comment if wanted.

[backl1n]

I would like you to create a web interface that can see all the interface machines on the network. I think if you create a model with an agent and a centralized server, you can centralize all the bandwidth and data usage that is used by machines like this model -https://www.google.com/url?sa=i&url=http%3A%2F%2Fparallel.vub.ac.be%2Fdocumentation%2Fpvm%2FExample%2FMarc_Ramaekers%2Fnode8.html&psig=AOvVaw20DKesLhIrzUwUSkI7iuDL&ust=1684621840200000&source=images&cd=vfe&ved=0CBEQjRxqFwoTCNDc88S3gv8CFQAAAAAdAAAAABBO @matbgn

[matbgn]

As I'm not maintainer of this project and have no impact on decisions here, maybe it will be better to ping @GyulyVGC at least 😉

[GyulyVGC]

Thanks guys for the feedback.

I have a bunch of other goals for the short term, but if I will be able to keep working on Sniffnet even after the GitHub Accelerator, I will definitely consider developing a web version.

[tocuto]

Hello! I'm thinking of giving this feature a try, and I wanted to first check with you about possible approaches.

As far as I am aware, Iced supports the Web platform (presumably utilizing WebAssembly). A way of implementing a web gui could be accomplished by completely separating the graphical part of the project and making it able to run in a headless state, with some way of extracting the data (maybe gRPC?) and then spawning a sidecar that would contain the interface. This interface could be in the form of a web server or a standalone Iced application. This gives the flexibility of running the project as a desktop application, exposing only said internal API (and then running the web server/desktop application in a client machine), or also hosting the web server along with Sniffnet.

The main problems I can see with this approach would be that this internal API would also be detected by Sniffnet, potentially creating an infinite and exponential recursion (detect internal API packet -> send it to client -> detect new packet -> repeat...) unless we implement a queue and send in batches (every 1s, for example) Another (I believe) problem is that separating the graphical part of the project is not going to be so easy: a quick search for iced in the project says that most references are in the gui directory (which is really beneficial), but there are some scattered references in other files (report, networking, ...).

I would love to know what your thoughts are on this approach or if we should simply think of another way of doing stuff.

[GyulyVGC]

Hey @tocuto thank you so much for your interest.

Honestly, I haven't a really clear plan concerning this issue. Ideally I'd like to change as least as possible, reusing most of the stuff that's already there. Something I'd really like to do, and which would allow to satisfy the previous point, is to keep using iced and finding a way to make it work on the web as is, if that's possible.

We should understand which portions of Sniffnet cannot be kept as they are now: for example whether we can inspect system network interface directly from the web environment or not. Then, exclusively for the features that can't be used as they are now, as you said we should find a gRPC-like mechanism to send the needed data. As you understand this is the part that requires major restructuring of the app and that's why in an ideal world I'd love to avoid it completely. But in case the web environment doesn't let us do some OS-level stuff, of course we should adapt the app to share proper data with the interface.

Feel free to start experimenting if you feel to, and let me know in case of doubts.

[tocuto]

We should understand which portions of Sniffnet cannot be kept as they are now: for example whether we can inspect system network interface directly from the web environment or not.

If the goal is to spin up a web browser and access the data sniffnet needs from there, this is a big no-no as the browser sandbox doesn't allow this kind of stuff.

As you understand this is the part that requires major restructuring of the app and that's why in an ideal world I'd love to avoid it completely.

I understand that you'd want to avoid this restructuring, but I really can't think of a way that doesn't require it. I feel like it's either moving only the gui part to the web and keeping the rest in a headless state; or moving the app as a whole to the web and making a sort of slim proxy for OS-level stuff.

I find the first approach better, as it would be way more extensible, but more time consuming. I will try to strip off all the OS components from the project and make that slim proxy for now tho.

[GyulyVGC]

I really appreciate your attempt, however keep in mind that I've been pretty busy lately and the time I plan to dedicate to Sniffnet will prioritise the Desktop application, since it will remain the most important goal of the project.