Netfox 0.18.0 — is it my connection, or is it the internet? 🔌
Hey everyone 👋
New module shipped, and it answers one question without a terminal, a router admin page or a speed test: is my connection the problem, or is it something past my door?
The Link panel on the Netfox Overview — the wired half, the radio with its headroom and its rate, the error counters, and the first-hop split
🔌 What the cable negotiated, against what it could have. A 10-gigabit port that settled for 1 Gb/s is not broken and nothing in macOS tells you it happened. Netfox names it, and names the two usual reasons — the cable, or the switch at the other end.
📡 What the radio is really doing. Not just "Wi-Fi 7 at 720 Mb/s", but how much room you have: 39 dB of headroom, signal against noise. And whether that rate is holding — the panel takes two samples and says steady, up or down. During development the radio moved half a gigabit in two seconds, same network, same room. One reading would have called that a property of the link 🤷
✅ Whether anything is being dropped — right now, and since boot. Two separate claims, because a link that has been clean for weeks can start dropping frames this second.
📍 And how far away the delay starts. "First hop 3.6 ms, then 11 ms more past the router." That split is the whole point: it is the difference between a problem you can fix and one you can only wait out.
My favourite part is what it refuses to say 🤐 A radio that is off has no band, so those pills are left out rather than filled with "Unknown". A link nothing crossed gets no clean bill of health — it has not been shown to be fine, it has not been shown anything. And a router that ignores pings is reported as untimeable, not as a fault, because plenty of them drop pings by policy.
No new permissions, no helper, no extra traffic except the latency check — which rides the switch you already have. Six languages. Free 🦊
👉 Try it, or see what's new: https://netfox.app
Would love to hear what you want to see next.
Replies
Bababot
The first hop split is interesting. seeing 3.6 ms to the router, then +11 ms seems way more useful than just getting one latency number.
Netfox
@adams_parker yeeeah, and the split has a weak spot worth knowing: it needs a reachable reference host past the router... when that's unreachable you get the first hop on its own rather than an invented total - less satisfying, but imo a missing half beats a made-up one
Bababot
@gfazioli That is actually a good approach. Knowing the first hop on its own is still useful, especially when the next reference host is not reachable.
Does netfox show which side is actually limiting the ethernet speed the cable & adapter or switch?
Netfox
@jabari_zuri You've gone straight at the bit that warning is deliberately vague about, and the honest answer is that it rules out one of your three and can't separate the other two, tbh.
The ceiling it compares against comes from your own port's supported-modes list, so when it says "1 Gb/s on a port that does 10", the Mac's side is definitively not the limit — that one's eliminated. Cable vs switch it genuinely can't split, because autonegotiation reports the rate it settled on and never why.
There's a folk heuristic that a bad cable shows up in the error counters while a switch capped at 1G gives you a clean link — I've left it out of the app on purpose, because I can't back it. Both machines I have read zero errors over about 19 million packets, so I've got no observation either way, and a plain Cat 5e cable negotiates 1G perfectly cleanly anyway. If you ever catch the counters moving on a cable swap I'd genuinely like to see it.
@gfazioli Got it that distinction makes sense. I would still find it useful to know which side can be ruled out, especially when troubleshooting a slower connection.
Netfox
@jabari_zuri ngl that's the better ask. The elimination is already in the maths . the warning only fires when your port advertises a higher mode than the one it settled on, so by the time you're reading it the Mac's side is out of the running. It just never says so out loud. Going on the list: "your port is fine, it's the cable or the switch" is a better sentence than the one that's there now
can this work properly with a Mac connected through a USB-C/Thunderbolt dock or is it mainly aimed at built in netwok interfaces?
Netfox
@alira_salu should work the same — nothing in there keys on "built in". Interfaces come straight from getifaddrs and every one of them gets the same query, so a dock's Ethernet is just another interface as far as the panel is concerned....
The honest part: I don't own a dock, so that path has never been run against real hardware. and there's one specific way it could come up short. The "could do more" warning needs the adapter's driver to publish its supported-modes list; if it doesn't, you'd still get the negotiated speed and the error counters, but no under-negotiation warning at all - the ceiling would be unknown, and it refuses to guess rather than call an unknown ceiling "fine".
If you do try it I'd really like to hear which way it went 🙏
@gfazioli Good to know. I use a dock pretty often, so I would be curious to see how it behaves with different USB-C Ethernet adapters in practice.
Netfox
@alira_salu Please do, if you get the chance --- I've got no dock here, so that path is the one part of the panel that has never been run against real hardware. The tell is small: if the adapter shows a negotiated speed but nothing about the ceiling, its driver isnt publishing what it can do, and the app would rather say nothing than call an unknown ceiling fine. That's the case I'd most like to see either way
i really like that it does not call a router broken just because it ignores ping. thats a small detail but it avoids a pretty misleading diagnosis.
Netfox
@andrew_dale2 that's the detail I was most worried nobody would notice, so thanks for calling it out. It has a cost worth naming though: a router that drops ping by policy and one that's genuinely wedged look identical from here, so "can't be timed" is also what you get when something really is wrong. I'd rather under-claim there than hand someonea red flag pointing at the wrong box
@gfazioli Yeah, that distinction makes sense. A tool should probably be careful about calling something broken when there is not enough information to know for sure.
Promomix
The two sample approach for Wi-Fi makes sense. A single 720 Mb/s reading can look great while the connection is actually bouncing around.
Netfox
@irsa_doham exactly that. two samples is the least that can say anything moved, which is also why the panel says nothing at all on the first render instead of showing a "steady" its got no second reading to back...