We build Asia VPN. This is our second app, and it comes from the situation every one of these blog posts eventually describes: you are standing in front of a network, you did not set it up, and you need to know what is actually going on.
A camera that should be streaming is not. A Wi-Fi network that shows four bars is unusable. Something on the LAN is answering on port 8080 and nobody knows what it is. The tools that answer those questions exist, but they are scattered across five apps, three of which want an account.
NetTools: Network Analyzer is those tools in one place, with no account, no sign-up, and nothing it measures leaving your phone.
What you are actually connected to
The first screen answers the question you always ask first. IPv4 and IPv6 address, gateway, subnet, DNS servers, MTU, interface, ISP and public IP.
On mobile data it goes further and shows the radio: RSRP, RSRQ, SINR, Cell ID, TAC, PCI and MCC-MNC. Those are the numbers that tell you whether "bad signal" means weak signal or a congested cell, which are different problems with different fixes.
One detail we care about: a VPN connection is shown as a VPN. Plenty of network info apps report whatever the default route says and quietly present the tunnel as your real connection. If you are on Asia VPN, or WireGuard, or a corporate client, NetTools says so.
MTU deserves a mention here because it is the one field people ignore until it ruins a day. If a tunnel is up, ping works, and HTTPS to some sites hangs forever, MTU is where you look - we wrote about why that happens and how to find the right value.
Wi-Fi, with a channel chart
Signal strength in dBm, updated about once a second, with a plain-language rating next to it so you do not have to remember that -67 dBm is fine and -85 is not.
The part that changes decisions is the channel chart for 2.4 GHz, 5 GHz and 6 GHz. Picking a Wi-Fi channel without looking at what your neighbours are on is guessing, and "auto" on a consumer router is frequently a bad guess that then persists for years. Look at the chart, pick the gap.
Also: channel width up to 320 MHz for Wi-Fi 7, band, BSSID, link speed and security. There is a home-screen widget and a Quick Settings tile if all you want is the current dBm without opening anything.
One honest limitation, surfaced rather than hidden. Android itself rate-limits how often an app may scan for nearby networks. Most Wi-Fi analyzers respond to this by appearing to refresh continuously while actually serving you a cached list. NetTools shows a real cooldown timer instead. A stale reading that looks live is worse than a number with a timestamp on it.
Who is on my network
The LAN scan sweeps the whole subnet and lists every host that answers: hostname, IP, response time and open ports.
Sweeping alone gives you a list of addresses, which is not the same as knowing what they are. So mDNS, SSDP and ONVIF discovery run alongside the sweep - devices that announce themselves get named properly rather than appearing as a bare IP.
Scans keep running in the background as a foreground service, because a full subnet sweep on a busy network takes longer than you will stare at a screen. Finished scans save under a site name and can be exported.
Finding the devices with no screen
This is the case NetTools was really built for.
A camera, an NVR or a network printer has no display to tell you its address. It is also, reliably, the device you most need to find on a network somebody else installed and did not document.
Two things help here. The LAN sweep probes RTSP on 554 and carries a camera port set covering the ports the major brands ship with. And ONVIF WS-Discovery goes further than probing: a camera that speaks ONVIF reports its own manufacturer, model and location. That label is fact, not inference.
The distinction matters, and it is the difference between a tool you can trust on site and one you cannot. An open port is a guess about what a device is. A device telling you its own model is not.
Speed test, and what the number means
Download, upload, latency, jitter and packet loss, measured over Cloudflare's anycast network with multiple parallel streams, with a live chart while it runs. The reported figure is total bytes over total time rather than a peak.
Now, we have argued on this blog that speed tests measure the wrong path, so it would be strange to pretend otherwise about our own. Both things are true:
What this number is good for: checking whether your line delivers roughly what you are paying for, and comparing the same connection over time. That is a real question and this answers it.
What it is not: a measurement of the path to any particular server. If your
game server or your VPS feels slow, throughput to Cloudflare's edge does not
tell you why - you want ping, traceroute and per-hop timings against that
specific host, which are in the app, or iperf3 against a box you control.
Three things we did try to get right. Total bytes over total time is the honest statistic, not the highest instantaneous reading. Jitter and packet loss are shown next to the throughput rather than buried, because for anything interactive they matter more. And every completed test is saved with the network that produced it, since a speed with no context cannot be read a month later.
Ping, traceroute, DNS, WHOIS, port scan
The standard toolkit, with the details that usually get left out:
- Ping with min/avg/max RTT and true packet loss.
- Traceroute hop by hop with real round-trip times, and a WHOIS lookup on any hop you tap - so "where does this path leave the country" is two taps rather than a research project. The usual reading discipline applies: loss at an intermediate hop is often the router rate-limiting its own replies, not loss. We wrote up how to read this without misdiagnosing it.
- DNS lookup for A, AAAA, MX, TXT, NS, CNAME and more, against any server you name. Ask your router and 8.8.8.8 the same question and compare the answers - that one comparison resolves a surprising share of "the internet is broken" reports.
- WHOIS that follows the registry referral chain instead of stopping at the stub answer, which is why it returns the actual registrant data rather than a pointer to another server.
- Port scanner with common, camera and custom port sets.
History and export
Save a scan under a site name and it stays. Any scan or speed test exports as CSV or JSON - UTF-8, so it opens straight into Excel or Google Sheets with accented site names intact rather than as mojibake.
If you look after more than one site, this is the feature that turns the app from a live readout into a record.
Ten languages
English, Tiếng Việt, Bahasa Indonesia, Bahasa Melayu, ไทย, Filipino, हिन्दी, 한국어, 简体中文 and 繁體中文.
What NetTools will not do
It will not invent a reading.
Vendor lookup is best-effort. Android blocks apps from reading another device's MAC address, so the vendor field is inference and is never presented as certain.
An open port tells you what is listening, not what brand the device is. The app says so on the screen instead of labelling a guess as a finding.
Where the platform limits what is knowable, we say so. On site, that is more useful than a confident wrong answer - you can work around a gap you know about, and you cannot work around one you have been told does not exist.
Permissions
Location, or Nearby Wi-Fi devices on Android 13 and later, is required by Android for any app that reads Wi-Fi names and scan results. There is no way to build a Wi-Fi analyzer without it.
NetTools does not collect your location, and nothing it measures is uploaded anywhere. The scans, the speed tests and the history live on your phone.
Price
Free, with a one-time in-app purchase to remove ads. No subscription, no account, no tracking.
Cover photo by Valentin Lacoste on Unsplash.
