[HN Gopher] Show HN: Network Monitor - a GUI to spot anomalous c...
___________________________________________________________________
Show HN: Network Monitor - a GUI to spot anomalous connections on
your Linux
A real-time network connection monitoring tool built with Rust and
GTK4, displaying active connections with live I/O statistics in a
modern graphical interface. https://github.com/grigio/network-
monitor
Author : grigio
Score : 149 points
Date : 2025-11-24 09:30 UTC (6 days ago)
| SlavikCA wrote:
| That screenshot / video on README page is mostly unreadable.
| Can't get anything out of it.
| voodooEntity wrote:
| Same for me.
|
| What info does it show more than a:
|
| "netstat -tulpn"
|
| Wrote myself a script years ago that basically loops netstat
| -tulpn watch like for the same purpose - just wondering if your
| tool shows me more than that.
| Simon-curtis wrote:
| modern graphical interface, for a start
| voodooEntity wrote:
| I was asking which information it shows not what output it
| uses to display that information....
| hamburglar wrote:
| Come on, now. You can see that it supports today's most
| critical feature: it has dark mode _and_ light mode.
|
| /s
| noir_lord wrote:
| If you live in the terminal it's all dark mode*
|
| * unless you are one of those weirdo's who has a black on
| white terminal in which case you should be on a watch list
| (/s in case wasn't immediately obvious).
| hamburglar wrote:
| I am exactly that kind of weirdo, but then again I've been
| reading black on white books for my entire life and I never
| thought to complain about it.
| bolangi wrote:
| I've been there since the DOS days when it was all dark
| mode, green phosphor characters on a black CRT. I was there
| when amber monitors were the new thing. (I still love
| sunglasses with brown lenses.) And I watched the early
| Apple computers with graphics and black-characters-on-white
| display style that has been the rage ever since... well
| since the recent new thing being dark mode.
|
| It reminds me of fashion trends, miniskirts then maxis, up
| and down past the knee like tides.
|
| Fads, that's the word.
| IshKebab wrote:
| This app is clearly a demonstration of GTK4's light/dark
| transition animation. Looks like it works perfectly to me!
| mordechai9000 wrote:
| Nice work!
|
| I do want to say, I don't like having to rely on scraping ss
| output. But that's not a comment on this project - I have done
| the exact same thing. It just proved to be the most expedient way
| given the constraints I was under. I suspect there is a lot of
| devops and CI/CD code out there that relies on the output format
| of ss. My concern is that parsing text intended for human
| readability and not machine processing is brittle and prone to
| failure due to unforeseen circumstances, or a package upgrade
| that changes the behavior.
| mbana wrote:
| I was going to say the same thing.
|
| I really like the eBPF approach as pointed out to by the other
| comments. I feel like this is the ideal approach, please
| correct me if I'm wrong.
|
| A callback based approach as opposed to (constantly) polling
| the output of some command is ideal.
| khimaros wrote:
| it sounds like you want
| https://github.com/evilsocket/opensnitch
| WD-42 wrote:
| Nice work. I've been writing an app using the same stack. The
| gtk-rs bindings are actually pretty productive once you get used
| to it! And it's so fast.
| mroche wrote:
| Cool project! As a more advanced form, I _think_ it should be
| possible to get all this information via eBPF rather than ss
| output and scraping /proc.
|
| Food for thought!
| rlmp_89 wrote:
| https://github.com/pythops/oryx
|
| -> voila!
| mentalgear wrote:
| BTW: This is also a TUI - much preferred !
| arcanemachiner wrote:
| The OP's project shows process names, which I do not see in
| this program.
| curcbit wrote:
| Nice but it feels too much AI slop
| oneshtein wrote:
| eBPF doesn't work on locked down kernels (stock kernels in
| Secure Boot mode).
| mroche wrote:
| eBPF is restricted when booted in a SB environment, but it's
| not nonfunctional. The default config puts the kernel into
| "integrity" mode of Kernel Lockdown, which reduces scope of
| access and enforces read-only usage.
|
| Whether or not the specific functions needed to replicate
| this tool are impacted is beyond my knowledge.
| grigio wrote:
| I think this is a great point, eBPF is cool but probably less
| popular than ss
| pm2222 wrote:
| eBPF/XDP is nice and hard to use. Packet capture is so common
| that I wish that there were a simpler way like pcap.
| rlmp_89 wrote:
| https://github.com/pythops/oryx
| jrm4 wrote:
| Fantastic, more of this. I don't know if I'm just missing it or
| what, but I'd love a GUI thing that showed all the devices on my
| network maybe even with a graph view.
|
| I'm using an Eero router out of laziness and even it has some
| features here that I'd like to see more of in polished "home-
| user" style network tools; especially since it seems as if more
| are getting into the "homelab"/"selfhosted" thing.
| bongodongobob wrote:
| That's impossible to do reliably without using agents, SNMP, or
| some other kind of communication protocol that you'll have to
| set up on each device. If you're ok with that, use SNMP. If you
| want topology, you'll have to have an agent that logs into all
| your networking gear and parses the configs.
| jrm4 wrote:
| "Reliably" is doing a lot of heavy lifting; I'm aware that
| with a combination of all the netstats and pings and nmaps
| there are ways to poke around.
| 0134340 wrote:
| Do you mean something like nmap's network topolgy view?
| https://nmap.org/book/zenmap-topology.html
|
| Just for visualizing network topology on Linux, there's a lot
| of tools.
| jdthedisciple wrote:
| Is there a version of this for the CLI?
| dwattttt wrote:
| bandwhich[0] is a recent one I'm familiar with
|
| [0] https://github.com/imsnif/bandwhich
| arunc wrote:
| Unfortunate to see this project in passive maintenance! Hope
| the get the required funding/human power.
| XiS wrote:
| So nethogs, but with a gui?
| lone-cloud wrote:
| The code is partly refined AI generated slop and the UX is
| lacking. The functionality is very basic and needs to be more
| thoroughly tested. This type of project is half a work day tops
| for a senior+ dev to create with agentic coding.
| johannesrexx wrote:
| May I ask how you made the determination that network-monitor
| is "partly refined AI generated slop"?
| LoganDark wrote:
| I came to this conclusion as well. The README gives off some
| vibes but the sheer volume and writing style of the code
| comments is what really sells it for me. For example:
|
| https://github.com/grigio/network-
| monitor/blob/9dc470553bfdd... // Enhanced
| styling with column-specific classes and alignment
|
| This sort of marketing-speak isn't what people typically put
| in their code, LLMs love buzzwords. It's not just this, it's
| everything, but hopefully you get what I mean.
| lone-cloud wrote:
| The mindless code comments are a dead giveaway. It's always
| the same pattern of: "a thing" <--- here is a thing Generally
| a dev would clean these up, but when they don't it's a major
| red flag to me that it's just unreviewed vibe coded slop.
| neilv wrote:
| Thanks especially for using GTK with Rust to do this. We need to
| keep desktop Linux GUI libraries alive and viable (as an
| alterative to Web site GUI frameworks, Electron apps with Web
| frameworks, and proprietary mobile app platforms).
| hombre_fatal wrote:
| Though I was let down last week when I ported a TUI to GTK4 and
| found out that even a hello world gtk4.h C app uses 200mb RAM.
|
| I haven't tried it yet but I believe Qt will weigh around the
| same.
|
| The TUI I ported uses <8mb RAM so I kinda lost interest in the
| GUI endeavor for my tools since I like to have one running in
| each project workspace.
| exploraz wrote:
| > Though I was let down last week when I ported a TUI to GTK4
| and found out that even a hello world gtk4.h C app uses 200mb
| RAM.
|
| Bit of a rant I wanted to share here:
|
| I've seen the same happened on zenity (a GUI dialog utility
| for shell scripts) since they migrated from GTK3 into GTK4.
|
| Now zenity took almost 2 seconds to launch instead of .5 to a
| second when they still used GTK3.
|
| This might be an issue on both libadwaita and GTK4 itself.
|
| Both pavucontrol (which uses GTK4 but not libadwaita, at
| least for now) and even a simple dialog in zenity
| (GTK4+libadwaita) consumed over 100 MiB of memory according
| to btop measurement, while both thunar and engrampa, which is
| both GTK3 apps, only consumed half the amount of memory usage
| (about 50 MiB according to btop).
|
| However, I've noticed that zenity, GNOME apps, and other apps
| that uses libadwaita took longer to launch compared to apps
| that only used GTK4 (pavucontrol), which launched as fast as
| other GTK3 apps does.
| exploraz wrote:
| Update: It turns out that in GTK4, half of the memory usage
| were dedicated to OpenGL hardware rendering alone.
|
| Using GSK_RENDERER=cairo almost halved the memory usage of
| most GTK4 apps, but it doesn't fix the startup time.
| hombre_fatal wrote:
| Hmm, maybe looking at btop memory usage is too naive.
|
| I'm not very knowledgeable here, but apparently that
| includes the memory of libraries that other gtk4 apps would
| share.
|
| If I launch 5x instances of my app and look at
| /proc/<pid>/smaps: | PID | Private |
| PSS | |--------|---------|----------|
| | 360955 | 65.4 MB | 133.0 MB | | 360956 | 52.1 MB
| | 105.0 MB | | 404303 | 65.8 MB | 132.9 MB |
| | 404304 | 65.8 MB | 133.2 MB | | 404305 | 65.9 MB
| | 132.6 MB |
|
| Looks like PSS includes private memory + shared libraries
| divided by the processes using them, so a little better
| than the 200mb that btop shows, but still over 2x heavier
| than, say, a hello world on macOS.
| BoppreH wrote:
| Cool project, I wish we had more GUIs for these OS functions. How
| was your experience with GTK4 and Rust?
|
| And it's a bit sad that in the year of our lord 2025, the best
| way to get such fundamental information is by using regexes to
| parse a table[1], generated by a 6000-line C program[2], which is
| verified by (I hope I'm wrong!) a tiny test suite[3]. OSQuery[4]
| is also pretty cool, but it builds upon this fragile stack.
|
| That's something I miss from Windows, at least PowerShell has
| built-in commands that give you structured output.
|
| [1] https://github.com/grigio/network-
| monitor/blob/9dc470553bfdd...
|
| [2] https://github.com/iproute2/iproute2/blob/main/misc/ss.c
|
| [3]
| https://github.com/iproute2/iproute2/blob/main/testsuite/tes...
|
| [4] https://osquery.io/
| typpilol wrote:
| I am in the process of building myself a cross platform GUI for
| network monitoring.
|
| Simply because I need one for non-critical stuff and things
| like uptime robot are enterprise geared and too expensive for
| me to entertain.
|
| I wish there was an uptime robot for like 25 cents a monitor a
| month.
| arcanemachiner wrote:
| Uptime Kuma is FOSS, not sure if it is missing any features
| you might be expecting. Very easy to set up as well.
|
| https://github.com/louislam/uptime-kuma
| simoncion wrote:
| > It's a bit sad that [we're parsing output] ... generated by a
| 6000-line C program[2] ...
|
| > That's something I miss from Windows, at least PowerShell has
| built-in commands that give you structured output.
|
| It sure is _something_ to disparagingly point to the LoC of
| 'ss' in one sentence, then pine for both PowerShell and the
| Windows infrastructure that supports it in the next.
|
| You mentioned processing the output with regexes. That's
| definitely a code smell, but this is one line of the data from
| the 'ss' command in question, with fancily-aligned header line
| included, but with vast tracts of whitespace removed. The regex
| you pointed out is processing the column whose comma-separated
| data is enclosed in parens: Netid State
| Recv-Q Send-Q Local Address:Port Peer Address:Port Process
| tcp LISTEN 0 666 [::]:22
| [::]:* users:(("sshd",pid=1337,fd=7)) ino:1338 sk:2024
| cgroup:/openrc.sshd v6only:1 <->
|
| They _definitely_ didn 't have to use a regex to process that,
| but chose to.
|
| You could argue that a system that let you write client code
| that goes something like
| socket[i].process.users[0].cmd, socket[i].process.users[0].pid,
| socket[i].process.users[0].fd
|
| is superior to one that requires writing something that makes
| use of the moral equivalent of 'cut'. I'd argue two things, one
| of them informed by my professional experience with PowerShell
|
| 1) What happens when the "structured" data you rely on changes
| shape? When that system that produces that "structured" data
| changes 'users' to 'user_list', 'cmd' to 'local_command', or
| deletes 'process' and moves 'users' up into its place, you're
| just as screwed as if 'ss' changed its output format in a way
| that wasn't backwards-compatible.
|
| 2) The core Microsoft tools might all produce "structured"
| data, but -in my professional experience- so, very, very little
| "community-provided" PowerShell code does. Why? I don't know
| for sure, but probably because it's notably more difficult to
| make a script or library produce that sort of data than it is
| to just emit regularly-formatted text.
| BoppreH wrote:
| The problem of data changing shape can happen regardless, but
| with text you have the added danger of escaping characters
| and ambiguities. Not to mention there are ad-hoc text formats
| for each and every tool, which can change from one version to
| another.
|
| And you're right, PowerShell is far from perfect. I miss some
| of its design goals, not the whole thing.
| rickydroll wrote:
| > And it's a bit sad that in the year of our lord 2025, the
| best way to get such fundamental information is by using
| regexes to parse a table[1],
|
| Look at nutshell an see if that gives you what you are looking
| for https://www.nushell.sh/
| heybrendan wrote:
| I see that you're parsing `ss` output in
| 'src/services/network.rs' (L22-L31) [1]. I find this to be a
| rather shaky foundation as any future drift or deviation in the
| `ss` utility's output could potentially yield unforeseen
| consequences.
|
| I'm vaguely aware that there are crates available in the Rust
| ecosystem for interrogating and manipulating sockets much more
| directly as well as high level abstractions for all things
| netlink (read: AF_NETLINK). Is wielding Rust's socket/netlink
| libraries unsuitable in some way, or was it merely deemed out of
| the design scope?
|
| Very cool project, please keep going!
|
| [1] https://github.com/grigio/network-
| monitor/blob/master/src/se...
| a-dub wrote:
| maybe consider support for the opensnitch ebpf backend?
| grigio wrote:
| I tried to do the most simple thing, thanks for the feedback
| gdevenyi wrote:
| Instead of directly parsing ss, use the jc program to produce
| JSON.
|
| https://kellyjonbrazil.github.io/jc/docs/parsers/ss.html
| Beijinger wrote:
| On a first look: The same as the shell tool nethogs, just with a
| GUI
| kazishariar wrote:
| Submitted a pull request for MacOS Support - please approve. Tnx!
| cookiengineer wrote:
| This shows only the contents of /proc fs, right?
|
| If you want realtime connection details, eBPF and XDP allow much
| more insights for that, as you can also parse network protocol
| payloads and implement adapters for each network protocol.
| k_bx wrote:
| I wish Linux had two more things:
|
| - https://github.com/winsiderss/systeminformer power-user process
| explorer
|
| - something akin windows system monitor, gnome's needs an upgrade
| butz wrote:
| First, a praise: Thank you for using native desktop UI, not some
| web framework and shipping additional browser along. And a bit of
| critique: Main screenshot should be bigger, and present the main
| view of the application. Ability to switch light/dark mode comes
| by default and target audience is more likely to see what data
| application displays and how.
| grigio wrote:
| Welcome, yes i put a better screenshot
___________________________________________________________________
(page generated 2025-11-30 23:02 UTC)