I live in the CLI, but when it came to discovery and monitoring, I found it limiting. So I built a GUI that brings my favorite tools together in one place.
PingStalker started because I wanted to know if something on the network was scanning my machine. I also wanted quick access to core details—external IP, Wi-Fi data, and local topology. Then I wanted more: fast, reliable scans using ARP tables and ICMP.
As a Wi-Fi engineer, I couldn’t stop there. I kept adding ways to surface what’s actually going on behind the scenes.
A few highlights:
- Performs ARP, ICMP, mDNS, and DNS scans to discover every device on your subnet, showing IP, MAC, vendor, and open ports.
- Continuously monitors selected hosts (“live ping”) to visualize latency spikes, missed pings, and reconnects.
- Detects VLANs on trunk or hybrid ports, exposing when your Mac is sitting on a tagged interface.
- Captures just the important live traffic — DHCP events, ARP broadcasts, 802.1X authentication, LLDP/CDP neighbor data, ICMP packets, and off-subnet chatter — to give you a real-time pulse of your network.
- Decodes mDNS traffic into human-readable form (that one took months of deep dives, but the output is finally clear and useful).
- Built my own custom vendor-logo database: I wrote a tool that links MAC OUIs with their companies, fetches each vendor’s favicon, and stores them locally so scan results feel alive and recognizable.
Under the hood it’s written in Swift. It uses low-level BSD sockets for ping and ARP, plus Apple’s Network framework for interface enumeration. The rest relies on familiar command-line tools. It’s fast.
I’d love feedback from anyone who builds or uses network diagnostic tools:
- Does this fill a gap you’ve run into on macOS?
- Any ideas for improving scan speed or how traffic events are visualized?
- What else would you like to see?
Details and screenshots: https://pingstalker.com
Happy to answer any technical questions about the implementation, Swift APIs, or macOS permission model.
ayewo•3mo ago
Apart from the obvious question of why you didn't opt to open source the tool :), I'm genuinely curious about how you approached development.
How did you decide for this feature A: "I'll just spawn child processes and read the output of `x-y-z` and `a-b-c` CLI tools, while for feature B: "I'll drop-down to BSD sockets"? Perhaps you have a performance budget: if using the Apple-provided CLI utilities are not fast enough then you drop down to writing BSD sockets?
n1sni•3mo ago
So, I struggled with that route so much. I've benefited from open source software throughout my entire life (and have contributed to it as well), and I am truly indebted to it. It is my goal in the future to make this open source, but for now, frankly, the money helps set the time aside needed to make this better. Again, I will revisit this once I hit a goal I have in mind.
So yes, performance budget was a key factor. Some CLI tools provide standard, predictable answers in a set amount of time. Others are all over the place on answers and time. Some commands have options to set timeout, size, syn options, and such, while others do not. I have a few commands that are on my short list to replace with custom code - especially around mDNS.