Added network monitor support for Linux platform

[AKJ7]

This pull request adds supports for displaying network (TCP) speed statistics per process. Precisely, the following have be added:

• New tab showing net statistic per process (TCP upload and download):

- Net monitoring doesn't require any priviledge access. - Support only available under linux - HTTP3 not supported - Extension to UDP is possible

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (1)

docs/styleguide.md — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: dfae80fe-23e8-4f85-a3d4-7f0199597fe6

📥 Commits

Reviewing files that changed from the base of the PR and between c03c93b and b46bd84.

📒 Files selected for processing (3)

• linux/LinuxProcess.c
• linux/NetSpeed.c
• linux/Platform.c

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

The pull request adds CMake build configuration, including platform detection, dependency probes, optional features, executable targets, and install rules. It also adds Linux TCP traffic-rate monitoring, per-process upload and download fields, and a Network Monitor screen. Platform cleanup functions now accept a machine pointer, and Linux cleanup releases network-monitoring resources.

Suggested reviewers: benbe

Priority: ➖ Normal

Change: Feature

Merge Risk: 🟡 Moderate · up to b46bd

Linux refreshes now perform extra process-descriptor scans even when the network view is unused, and long sessions can accumulate monitoring state; the monitor can also display stale rates. Address or explicitly accept these risks before merging.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to b46bd

Linux monitoring now runs on every rescan, even outside the Network Monitor screen. Socket history has no eviction bound, and some process-rate updates can allocate objects without retaining an owner. Local socket activity can therefore increase the monitor's memory consumption over time. The demonstrated exposure is limited to monitoring instances that can observe those processes; privilege escalation or cross-service compromise was not established.

Retained concerns

• Medium · security · inferred: The new always-on scan path does not bound retained socket history and can create process objects without transferring or releasing ownership. Local activity involving observable TCP sockets can grow monitoring memory across repeated scans. In particular, machine scans continue while process-table updates are paused, allowing a newly observed PID to remain absent from the table across repeated rate updates. The potential availability impact is inferred from source; its practical rate was not measured.

Security review details

Security Blast Radius

• inferred — The supported resource-exhaustion path affects Linux monitoring instances that can map the relevant processes' socket descriptors. Local users can influence their own socket lifetimes and traffic without controlling serialized kernel replies. Broader observation depends on the monitor's existing permissions; no privilege gain or cross-service authority expansion was established.

Security Findings and Attack Paths

• inferred — Observable socket churn introduces new retained traffic nodes without scan-time eviction. Separately, when a mapped PID is absent from the process table, a qualifying repeated sample constructs a process object that the rate producer neither inserts nor deletes. Continued machine scans during paused table updates make that ownership mismatch reachable across repeated samples.

Trust Boundaries and Controls

• observed — Per-scan inode-cache rebuilding removes previous PID mappings, and failed proc reads do not bypass filesystem access controls. Counter decreases are clamped to zero. However, traffic history identifies sockets only by inode, so these controls neither bound retained history nor distinguish an old socket from a later socket reusing that inode.

Resilience and Maintainability Implications

• observed — Initialization failure frees nested allocations and the monitor frees and clears its owner pointer, permitting a later retry. Collection failure instead leaves incremental updates in place and its result is ignored by the machine scan. Rates for processes not subsequently touched can remain stale because clearing is conditional on a diagnostic update and NetSpeed_dirty is a no-op.

Hardening Proposals

• proposed — Bound or expire traffic history using scan participation and socket-lifetime identity, update only table-owned process objects, and make failed or incomplete telemetry explicitly invalid. These changes would separate diagnostic collection from process creation and strengthen resource and recovery invariants.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{TCP currents cross the screen
Socket counters mark their flow
Process rates take shape in scans
Build checks choose the paths to go
CMake gathers targets, flags
Cleanup closes where streams once ran}

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 20

---

ℹ️ Review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 1e2636ec-e8cd-4ec6-88cb-b06c4ec930b7

📥 Commits

Reviewing files that changed from the base of the PR and between d76b23e and 200f6a2.

📒 Files selected for processing (33)

• CMakeLists.txt
• CMakeLists3.txt
• CommandLine.c
• Config.h.in
• Machine.h
• Makefile.am
• darwin/Platform.c
• darwin/Platform.h
• dragonflybsd/Platform.c
• dragonflybsd/Platform.h
• freebsd/Platform.c
• freebsd/Platform.h
• linux/LinuxMachine.c
• linux/LinuxMachine.h
• linux/LinuxProcess.c
• linux/LinuxProcess.h
• linux/LinuxProcessTable.c
• linux/NetSpeed.c
• linux/NetSpeed.h
• linux/Platform.c
• linux/Platform.h
• linux/ProcessField.h
• netbsd/Platform.c
• netbsd/Platform.h
• netmonitor.c
• openbsd/Platform.c
• openbsd/Platform.h
• pcp/Platform.c
• pcp/Platform.h
• solaris/Platform.c
• solaris/Platform.h
• unsupported/Platform.c
• unsupported/Platform.h

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

[coderabbitai]

📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Rename the generic HASH_SIZE and CACHE_TTL_SEC macros.

LinuxMachine.h includes this header, so many translation units see these macros. HASH_SIZE is a common name, and a collision with another header causes a redefinition or silent behavior change. CACHE_TTL_SEC is not used, because the TTL check in NetSpeed.c is commented out. Rename the macros with a NETSPEED_ prefix, or move them into NetSpeed.c.

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Free the NetMonitoringData allocation. NetSpeed_monitor allocates netMonitoringData. NetSpeed_cleanup frees only the struct's members, and no code frees the struct.

• linux/Platform.c#L1184-L1185: after NetSpeed_cleanup, call free(linuxMachine->netMonitoringData) and set the pointer to NULL.
• linux/LinuxMachine.h#L105-L105: document that the LinuxMachine owner frees this pointer during platform cleanup.

📍 Affects 2 files

• linux/Platform.c#L1184-L1185 (this comment)
• linux/LinuxMachine.h#L105-L105

[BenBE]

This duplicates functionality already present in #2105 …

Also, please take a very close look at the style guide and contribution documents. Your code style is all over the place.

[fasterit]

Closing as the already existing #2105 PR is more advanced