DEV Community: Dmytro Tishchenko

0.0000008 Mbps: the silent 403 that hid half of my bufferbloat test

Dmytro Tishchenko — Tue, 29 Sep 2026 15:38:43 +0000

The download half of my bufferbloat test was measuring an idle line. The code asked Cloudflare's speed endpoint for a gigabyte, got back a 403 with a one-byte body, and never looked at the status. The pings kept running, the grades kept coming out, and every result looked like data.

I build NetDiag+, an iOS network toolkit, and wrote here before about ping and traceroute without entitlements and measuring latency without root. In that last post I showed the bufferbloat classifier, including this branch:

if dnN >= upN * 2 { return .ispDownstream }

"Download latency rose much more than upload: the queue is on the provider's downstream path." It reads well. It could almost never run.

This post is about how that happened, how I found it, and the lesson I took from it: a load generator has to measure its own load. The feature that exposed the bug is a Health Score that turns one run of about 40 seconds into a number and a verdict on who is to blame.

How a bufferbloat test works

Bufferbloat is latency that appears only when the line is busy. An idle ping to 1.1.1.1 says 14 ms; start a big download on the same connection and the same ping says 180 ms, because packets are now waiting in an oversized buffer somewhere between you and the internet. That is what makes a video call stutter while someone else in the house updates a game.

The test is simple in principle:

Baseline: ping the home gateway and an internet target for five seconds with the line idle.
Download: saturate the downlink for ten seconds while the same two pings keep running.
Recovery: two seconds of nothing, so buffers drain.
Upload: saturate the uplink for ten seconds, pings still running.

The grade (A+ to F) comes from how far the internet ping rises over its baseline under load. The attribution comes from the gateway ping: if the gateway climbs too, the queue is between the phone and the router, i.e. Wi-Fi; if the gateway stays flat and the internet leg climbs, the queue is past the router. Comparing the two load phases then separates the router's upload buffer from the provider's downstream queue.

The physics behind the attribution is the old argument from every bufferbloat thread: the queue forms at the bottleneck. Toward your home, the bottleneck is usually the provider's equipment, so download bloat lives there. Toward the internet, the bottleneck is usually your own modem or router, so upload bloat is yours. That asymmetry is why comparing the two load phases can separate them at all.

It also shapes the fix: upload bloat is solved on your router with fq_codel or cake; download bloat can be tamed from home by shaping inbound traffic a few percent below line rate, or handed to the provider as evidence. (Details in the bufferbloat guide.)

Every one of those steps assumes the load phases actually load something.

The load that wasn't

Here is the download saturation as it shipped:

private static let downloadURL =
    URL(string: "https://speed.cloudflare.com/__down?bytes=1073741824")!  // 1 GB — we cancel by time

private static func saturateDownload(duration: TimeInterval) async {
    let session = URLSession(configuration: .ephemeral)
    defer { session.invalidateAndCancel() }
    do {
        let (bytes, _) = try await session.bytes(from: downloadURL)
        let deadline = ContinuousClock.now.advanced(by: .seconds(duration))
        for try await _ in bytes {
            if ContinuousClock.now >= deadline { break }
            if Task.isCancelled { break }
        }
    } catch {
        // network error — measurement still yields whatever ICMP got.
    }
}

Ask for a gigabyte, drain it for ten seconds, cancel. Nothing in it is wrong as Swift. Three things in it are wrong as a measurement:

The response is never looked at. (bytes, _) throws away the URLResponse. Whatever status came back, the loop ran.
Nothing is counted. The function returns Void. There is no way for the caller to learn whether ten seconds of saturation moved ten gigabits or ten bytes.
The failure path is silent by design. The comment even says so: whatever happens, "the measurement still yields whatever ICMP got".

So I asked the endpoint directly:

$ curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
    "https://speed.cloudflare.com/__down?bytes=99999999"
200 99999999

$ curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
    "https://speed.cloudflare.com/__down?bytes=104857600"
403 1

Anything from 100 MB up gets a 403 with a one-byte body, with any user agent. I cannot say whether that limit was already there when I wrote the code. The code gave itself no way to notice either way. The "download phase" had been ten seconds of pings over an idle line.

What it did to the verdicts

Tracing it through the classifier is the uncomfortable part. With no download load, the download rise over baseline is roughly zero. Then:

let worstRise = [dnNetRise, upNetRise].compactMap { $0 }.max()
let grade = Grade.from(latencyRiseMs: worstRise)   // effectively: upload only
...
if grade == .aPlus || grade == .a || grade == .b { return .clean }
if upN >= dnN * 2 { return .uplinkQueue }          // true for any upload bloat over ~0
if dnN >= upN * 2 { return .ispDownstream }        // unreachable
return .modemOrLine                                 // nearly unreachable

The grade was an upload-only grade. A line that was clean under upload and awful under download got an A.
Any real bloat was blamed on the router's upload queue, because "upload rose at least twice as much as download" is true when download rose by nothing.
"ISP downstream", the verdict the tool exists to produce for a support ticket, could not fire.

Gateway attribution still worked, since the upload phase did load the line, so Wi-Fi faults were caught. But the one number people screenshot for their provider was half a measurement.

How it surfaced

Not from a user report. It surfaced when I started reusing the load phases for something new.

The new feature, Health Score, wants a speed number, and running a separate speed test next to a bufferbloat test is wasteful: both saturate the same line. So the plan was to count the bytes the load phases already move. The first simulator run came back with:

score 89/100 · Excellent · grade A+
download 0.0000008 Mbps · upload 65.0 Mbps

An excellent connection that downloads at less than one bit per second is a contradiction you cannot miss. The upload number was plausible; the download number was the single byte the 403 carried, spread over ten seconds. The moment the load had to report its own size, the lie had nowhere to go.

That is the general lesson I took: a load generator has to measure its own load. If the part of a test that is supposed to stress the system cannot fail visibly, it will eventually stress nothing, and every number downstream of it will still look like data.

The fix

Download is now 50 MB requests back to back until the window closes, with bytes counted in the data delegate:

private static let downloadURL =
    URL(string: "https://speed.cloudflare.com/__down?bytes=52428800")!  // 50 MB, under the limit

private static func saturateDownload(duration: TimeInterval) async -> Double? {
    let counter = ByteCounter()
    let session = URLSession(configuration: .ephemeral, delegate: counter, delegateQueue: nil)
    let start = ContinuousClock.now
    let deadline = start.advanced(by: .seconds(duration))
    let loop = Task {
        while ContinuousClock.now < deadline, !Task.isCancelled {
            await counter.run(session.dataTask(with: downloadURL))   // 50 MB chunk
        }
    }
    try? await Task.sleep(nanoseconds: UInt64(duration * 1_000_000_000))
    loop.cancel()
    session.invalidateAndCancel()
    let seconds = elapsedSeconds(since: start)
    guard seconds > 1, counter.bytes > 0 else { return nil }
    return Double(counter.bytes) * 8 / seconds / 1_000_000
}

Two details that matter:

The delegate counts whole buffers. didReceive data: hands over chunks of tens of kilobytes. The old for try await _ in bytes iterated one byte at a time, which on a fast line is a CPU benchmark, not a network one: the phone gives up well before a gigabit connection does.
The function returns a rate, or nil. A nil propagates into the result as "no speed measured", and the grade logic can see it.

Upload got the same treatment for a different reason. It used to POST one 32 MB body. On anything faster than about 25 Mbps that finishes early and the uplink sits idle for the rest of the phase, exactly when the test wants the queue full. It is now 8 MB POSTs back to back until the window closes, counted in didSendBodyData.

After the fix, on the same Wi-Fi: 455 Mbps down, 62 Mbps up, grade A instead of A+, because the download phase now finally adds a few milliseconds.

Health Score: one run, one number, one culprit

With the load phases honest, Health Score is mostly orchestration of tools that already existed:

Phase	What runs	Time
Idle	ICMP to 1.1.1.1 and 8.8.8.8, TCP connect to 1.1.1.1:443, gateway ping	~8 s
Load	the Bufferbloat probe, now counting bytes	~27 s
Recovery	ten more pings to 1.1.1.1	~3 s

The phases are sequential on purpose. Throughput and latency cannot be measured cleanly at the same time: the throughput test fills the queue, and a filled queue corrupts the latency number. That corruption is bufferbloat. So the latency you care about for gaming is measured idle, and the latency you care about for "everything lags when someone downloads" is measured under load.

The score is a weighted sum of five components:

Component	Max	What earns the points
Responsiveness under load	35	the Bufferbloat grade: A+ 35, A 30, B 22, C 12, D 5, F 0
Idle latency	20	under 20 ms 20, under 40 ms 16, under 80 ms 10
Stability	20	idle jitter under 5 ms 20; any loss −6, 10% or more zeroes it
Speed	15	download tiers up to 12, upload up to 3; gentler curve on cellular
Local link	10	gateway RTT and jitter; points given on cellular

Responsiveness gets the biggest weight deliberately. Most people's complaint is not "my internet is slow" in the speed-test sense; it is that it becomes unusable at certain moments, and that is a queueing problem, not a bandwidth one.

Under the number there are three rows: Wi-Fi, Router, ISP, each ok, suspect or at fault. They come from the same rules as the Bufferbloat verdict, plus the idle numbers that load never touches: a gateway that already answers in 30 ms is Wi-Fi's fault, loss on the idle path with a healthy gateway is the provider's.

One more lesson from the first runs. Idle loss was originally the worst row: a single refused TCP handshake out of ten gave that row 10% "loss", which cost eight points and blamed the ISP for one dropped SYN. It is now the mean over the ICMP rows, twenty scored samples. Averaging where you have the samples and taking the worst where you do not is a choice worth writing down.

Nothing leaves the phone. The scoring is a pure function over the numbers in one run, and every row expands on tap to show its thresholds, so a user can see why they got 64 and not 80.

This is what the Health Score detail rows look like, from another run on the same Wi-Fi:

Metric	Value
Bufferbloat grade	A
Idle latency	14 ms
Jitter	1 ms
Loss	0%
Download	447.5 Mbps
Upload	68.4 Mbps
Gateway	3 ms

Three iOS networking gotchas from the same release

VPN Check. Is a tunnel up, what is your public identity, what NAT type does STUN see, and does the system resolver agree with Cloudflare DoH. On iOS, the presence of utun interfaces tells you nothing, since every iPhone has several for system services; a VPN shows up as a utun/ipsec key under __SCOPED__ in CFNetworkCopySystemProxySettings(), or as a tunnel interface in the current NWPath.
HTTP Headers with the full redirect chain. App Transport Security refuses plain http:// in URLSession, and the http→https hop is the one people most want to see, so that single hop is a raw HTTP/1.1 exchange over NWConnection. ATS stays on for everything else.
Reverse DNS via getnameinfo with NI_NAMEREQD, forward-resolving hostnames first and showing the in-addr.arpa name so the answer can be repeated with dig -x.

Limitations

The released version still doesn't check the response code. 50 MB chunks fit under today's Cloudflare limit, but if it drops, the download would read near zero again. That is the exact failure this post is about, so in the next version a non-2xx answer stops the phase and the speed is marked "not measured" instead of a tiny number.
Cloudflare is the load target. If a network throttles or blocks speed.cloudflare.com, the speeds in the report are low, and they are speeds to Cloudflare, not your plan.
One stream. Chunks go one after another over a single connection. Speed tests usually open several in parallel; on high-RTT lines one stream may not reach the plan's rate, which understates both speed and queueing.
The phone is the bottleneck on very fast lines. Above roughly a gigabit, Wi-Fi and the device limit throughput before the line does. The score rewards 100 Mbps and up the same way for that reason.
Health Score is a heuristic. The weights are opinions written down as code. They are public in the app's help screen, and I would rather be argued with over a table than hide it.
Earlier Bufferbloat grades should be read as upload-only. If you saved results from 1.4.5 to 1.4.8, don't rely on the download rows: I don't know when the limit appeared, and in the latest of those versions they certainly measured an idle line.

Links

NetDiag+ on the App Store (free; $2.99 one-time premium): https://apps.apple.com/app/apple-store/id6761954529?pt=128748487&ct=devto&mt=8
What bufferbloat is and how to fix it: https://netdiag.online/guides/bufferbloat/

Have you had a benchmark, load test or health check that quietly stopped doing its job while still producing plausible numbers? I'm curious how you found out. And if you think the Health Score weights are wrong, the table above is there to be argued with.

Your speed test lies: measuring latency on iPhone without root, and the ICMP bug that made two pings swap replies

Dmytro Tishchenko — Tue, 22 Sep 2026 13:32:28 +0000

NetDiag+ 1.4.7 went live this week — the iOS network toolkit from my v1.3 and v1.4 posts, now 27 tools, 13 languages, BSD sockets through C-interop, no private entitlements. This release adds one tool, a Latency Dashboard, and fixes one bug that had been shipping quietly since 1.3. Both taught me more about measurement than the other 25 tools combined.

Why a speed test does not answer "why do I lag"

Most of my users are in Saudi Arabia, Turkey, Egypt and Russia, and the most common support question is some version of "the speed test says 180 Mbps but PUBG is unplayable". Both are true at once. A speed test measures throughput to a CDN edge placed deliberately close to you. A game talks UDP to a datacentre in a region — Bahrain, Frankfurt, Mumbai — and what hurts there is round-trip time and how much it wobbles between packets. Throughput to a nearby edge says nothing about either.

My own app had the same blind spot. Site Reach, the censorship tool from 1.4, measures TLS handshake time to 35 web frontends and sorts them alphabetically; in the Gulf nothing is blocked, so it returns 35 green rows and the worst latency hides mid-alphabet. The Latency Dashboard is the opposite question with the same machinery: what is far from here, and what is unstable?

The catalog is the product

The value is in which endpoints get measured, and that has to be per market — a Saudi gamer does not care about Steam's Frankfurt CM; they care about AWS me-south-1, where PUBG Mobile's Middle East matchmaking lives.

So the table is keyed off the App Store storefront (SKStorefront.countryCode), not the UI language — a Saudi expat in London still wants the Gulf table. Five tables, 13–14 rows each across cloud regions, game ping hosts, CDN edges and carrier resolvers, plus four global anchors as a baseline. Every row carries a port (0 = ICMP, otherwise TCP connect — AWS/GCP/Azure drop ICMP by policy), a confidence and a note saying what the number actually measures:

.init(id: "aws-me-south-1", displayName: "AWS Bahrain",
      hostOrIP: "ec2.me-south-1.amazonaws.com", port: 443, category: .cloudRegion,
      confidence: .medium, note: "Degraded post Mar 2026 — PUBG-M ME hosted here"),
.init(id: "fortnite-me", displayName: "Fortnite Middle East",
      hostOrIP: "ping-me.ds.on.epicgames.com", port: 0, category: .gaming,
      confidence: .high, note: nil),

Two curation rules. Do not invent hosts: PUBG Mobile, Free Fire, CoD Mobile, Discord voice and Riot Direct publish no per-region ping hostnames, so the nearest cloud region stands in as a labelled proxy. A failing row is data: AWS Bahrain has been degraded since March 2026 and Valorant MENA moved to Mumbai; a red Bahrain row next to a green Mumbai row is the diagnosis.

Rows sort worst-first by median plus jitter, and the gateway is measured before everything else, alone. If the router already answers in 30 ms, every remote number inherits that and a banner says so instead of blaming geography.

[SCREENSHOT: Latency Dashboard, SA storefront — gateway header, worst-first rows with median / jitter / loss columns, Bahrain "No reply" next to a green Mumbai row]

Measurement engineering: seven rounds against a Mac

I no longer trust a phone-only latency number. The tool was tuned against a MacBook on the same Wi-Fi running the identical probe sequence from a script, in the same minute. Seven device rounds, five defects, each one looked like "the network" until the Mac said otherwise.

Warm-up. First run: 8 of 9 rows "Unstable", jitter 384–402 ms on paths with 56–195 ms medians. The first concurrent chunk was paying ~1.5 s for Network.framework path setup and the radio leaving power save. Fix: probes are lists of attempts ([Double?], nil = no answer) and attempt #1 is discarded whether it answered or not — otherwise a warm-up that misses the 2 s timeout becomes 20% fake loss. One throwaway TCP connect warms the path before the fan-out.

Wi-Fi power-save doze. Gateway 3 ± 1 ms, yet Frankfurt 68 ± 36 against 29 ± 3 from the Mac, and one target swung 38 → 2 → 1 ms of jitter across three back-to-back runs. A gateway reply at 3 ms lands while the radio is still awake; a reply from 30–170 ms away lands after it dozed and waits on the AP for the next beacon. No gateway statistic can predict that, so the fix removes the cause: a second PingService fires ICMP at the gateway every 50 ms during the fan-out (started after the gateway row so the baseline stays untouched). Not cheating: game and voice traffic hold the radio awake anyway, so those are the numbers the user plays on.

Address alternation. Long paths settled (Tokyo jitter 42 → 6) but CDN rows went bimodal: Snapchat median 24, jitter 230 — samples alternating 24, 250, 24, 250. A radio does not do that. A fresh NWConnection by hostname per attempt does: short-TTL CDN names plus Happy Eyeballs racing v6/v4, the winner changing between attempts. The Mac script had resolved once and connected to the IP, so now the app does too (pinnedIPv4: resolve once, connect to the literal, hostname fallback when there is no A record). A TCP-connect time is only an RTT if every attempt hits the same address.

A statistics defect. Residual short-path jitter 16–29 ms vs the Mac's 2–6. TCP rows had 6 attempts → 5 samples → 4 deltas, and sorted[count / 2] on four values is the upper median — the second-largest. One residual spike became "jitter". Fix: 11 attempts everywhere (10 scored, 9 deltas) and a true median. Jitter is the median of consecutive |Δ|, not the mean, and "Unstable" is relative — 12 ms of wobble matters on a 30 ms path and is noise on a 260 ms one:

let median = trueMedian(samples)
let deltas = zip(samples, samples.dropFirst()).map { abs($1 - $0) }
let jitter: Double = deltas.isEmpty ? 0 : trueMedian(deltas)
let unstableAt = max(measurement == .tcpConnect ? 20 : 15, median * 0.2)

let verdict: LatencyResult.Verdict = {
    if loss > 0 { return .losing }
    if jitter >= unstableAt { return .unstable }
    if median >= 60 { return .far }
    return .closeStable
}()

One more rule: an ICMP target with zero replies is re-asked over TCP on the port it actually speaks (:53 for resolvers, :443 otherwise) and, if that answers, marked ICMP filtered rather than unreachable. After that the TCP rows matched the Mac to within a few ms. Then round 6 happened.

The bug: two pings that swapped replies

Round 6: every ICMP row read median 0 ms, loss 0%, "Close & stable". Including Fortnite Middle East, which had honestly said "No reply" for the previous five rounds.

The v1.3 post showed how iOS lets you ping without entitlements: socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP). What I did not know then, and what the 50 ms keepalive made impossible to miss, is how Darwin demultiplexes those sockets. On Linux, an unprivileged ICMP socket receives replies matching its identifier. On Darwin, every echo reply reaching the host is delivered to every unprivileged ICMP socket in the process; the kernel does not filter on the identifier you put in the packet.

The 1.3–1.4.5 receive path did one receive() per send and accepted any echo reply:

// PingService, 1.3 – 1.4.5
try sock.send(data: packet, to: dest)
let (data, fromIP) = try sock.receive()          // one receive per send
guard let header = ICMPHeader.parse(data),
      header.type == ICMPType.echoReply.rawValue // any echo reply will do
else { continue }

With one ping running, that is fine. With a gateway keepalive answering every 50 ms, each row's receive() returned the gateway's reply microseconds after its own send: 0 ms RTT, zero loss, for a host that was not answering at all.

The uncomfortable part: this was not a new bug. Bufferbloat (1.4.5) runs two PingService instances concurrently — gateway and 1.1.1.1 — precisely to compare them, and under load their samples could be swapped: a 3 ms gateway reply booked to the internet leg and vice versa.

The fix lives in PingService so every caller inherits it. Loop on receive() until identifier and sequence match, re-arming SO_RCVTIMEO with the remaining time each iteration — otherwise every skipped foreign reply resets the full timeout:

let sendTime = CFAbsoluteTimeGetCurrent()
let deadline = sendTime + timeout

do {
    try sock.send(data: packet, to: dest)

    // Accept only our identifier + this sequence; skip the rest until deadline.
    while true {
        let remaining = deadline - CFAbsoluteTimeGetCurrent()
        guard remaining > 0 else { throw SocketError.timeout }
        sock.setTimeout(seconds: max(remaining, 0.001)) // 0 would block forever
        let (data, fromIP) = try sock.receive()
        let recvTime = CFAbsoluteTimeGetCurrent()

        guard let header = ICMPHeader.parse(data),
              header.type == ICMPType.echoReply.rawValue,
              header.identifier == identifier,
              header.sequenceNumber == UInt16(seq)
        else { continue }

        continuation.yield(PingResult(sequence: seq, bytes: data.count, ttl: 0,
                                      rtt: recvTime - sendTime, from: fromIP,
                                      timestamp: Date()))
        break
    }
} catch SocketError.timeout {
    // don't yield, count as lost
}

The max(remaining, 0.001) matters: a zero timeval means "no timeout" to SO_RCVTIMEO. Found out the hard way.

Round 7, after the fix: Fortnite Europe 41/4, Fortnite Asia 257/6, Bahrain back to "No reply", TCP rows within 2–5 ms of the Mac. Closed. If you run concurrent ICMP anywhere on Darwin and do not check identifier + sequence on receive, you have this bug.

Bufferbloat: attribution, not just a grade

The bufferbloat tool from 1.4.5 inherits the reply-matching fix, which matters because its whole point is two pings at once. Baseline 5 s, saturate download 10 s, recover 2 s, saturate upload 10 s — with ICMP to the gateway and to 1.1.1.1 throughout at 200 ms spacing. Grading is the Waveform-style scale on latency rise under load (under 5 ms A+, 30 A, 60 B, 200 C, 400 D, else F), but the grade is not the interesting output. The gateway differential is:

// Gateway itself climbs (>30 ms) under load: the queue is between the
// phone and the router. Overrides any ISP-side interpretation.
if let dnGw = dnGwRise, dnGw > 30 { return .localWifi }
if let upGw = upGwRise, upGw > 30 { return .localWifi }

if grade == .aPlus || grade == .a || grade == .b { return .clean }

// Asymmetric: whichever direction is worse ≥ 2x names the queue.
if upN >= dnN * 2 { return .uplinkQueue }
if dnN >= upN * 2 { return .ispDownstream }
return .modemOrLine

Gateway flat while the internet leg climbs: the queue is past the router, ISP side. Gateway itself climbs: it is your Wi-Fi, and complaining to the ISP will not help. Medians and p95 rises only, so one stray 400 ms spike cannot flip a diagnosis. Results are stored as structured History entries and read back oldest-first as a trend, so you can see whether the router firmware update did anything.

[SCREENSHOT: Bufferbloat result — grade, gateway vs internet latency-under-load chart, verdict "Queue is on the ISP side"]

Limitations, and what iOS forbids

Honest list:

ICMP RTT is not in-game ping. Protocol overhead, server tick rate and matchmaking region sit on top. The row says "network latency to the region where those servers run", never "your PUBG ping". TCP-connect rows are labelled as such and get a higher Unstable floor.
No raw sockets, so no TTL on replies (the IP header is stripped) and no kernel-side identifier filtering — hence the check in user space. No background sampling either; everything runs while the tool is open.
No cellular keepalive. The 50 ms trick targets Wi-Fi power save; cellular DRX has no gateway to ping.
Carrier portal rows are web front doors. stc.com.sa answers from a CDN edge 17 ms from Slovenia — not Saudi Arabia. They carry a "not the carrier's network" note until an in-country tester finds real on-net hops.
A phone-only reading is not evidence. Run the same probe from a laptop on the same Wi-Fi before touching a threshold; all five of my defects were invisible without it.

What I learned building 9 network tools on iOS without entitlements

Dmytro Tishchenko — Thu, 04 Jun 2026 09:08:23 +0000

A few weeks ago I shipped NetDiag+, an iOS network toolkit — ping, traceroute,
DNS, whois, port/LAN scan — built entirely on BSD sockets through C-interop, with
no private entitlements. I wrote up the ping/traceroute internals here.

Then I spent a month adding 9 more tools. I expected "more of the same" — wrap a
socket, draw a SwiftUI list. Instead almost every tool turned into its own little
research project. Here are the parts that surprised me.

1. MTR — a continuous traceroute that can't be slow

mtr keeps probing every hop and accumulates per-hop loss + RTT stats. My first
version probed hops sequentially: TTL=1, wait for reply or timeout, TTL=2, wait…
On a 12-hop path where a couple of routers rate-limit ICMP, one cycle took 5-7
seconds. Set the interval to "1 second" and the cycle counter ticks every five.

Fix: fire all probes in a cycle at once and collect replies in a single window.
The trick is matching an incoming ICMP reply to the TTL that triggered it. I give
each probe a unique destination UDP port (base + ttl + cycle_offset). When a router
returns ICMP Time Exceeded it includes the first bytes of the original packet — UDP
header included — so I demultiplex on that port:

/// Pull the dest port out of the UDP header embedded in an ICMP Time-Exceeded
/// error, so we know which outstanding probe this reply belongs to.
static func extractInnerDestPort(from data: Data) -> UInt16? {
    let bytes = Array(data)
    let icmpHeader = 8
    guard bytes.count > icmpHeader else { return nil }
    let ihlBytes = Int(bytes[icmpHeader] & 0x0F) * 4   // inner IP header length
    guard ihlBytes >= 20 else { return nil }
    let innerUDP = icmpHeader + ihlBytes
    guard bytes.count >= innerUDP + 4 else { return nil }
    return (UInt16(bytes[innerUDP + 2]) << 8) | UInt16(bytes[innerUDP + 3])
}

Now cycle time ≈ probeTimeout, independent of how many hops are timing out.

For the stats, storing every RTT and recomputing stddev leaks memory in a tool that
runs forever. Welford's online algorithm updates mean + variance in O(1):

recv += 1
let delta = rttMs - mean
mean += delta / Double(recv)
m2 += delta * (rttMs - mean)
// ...
var stdDevMs: Double? {
    guard recv >= 2 else { return nil }
    return (m2 / Double(recv - 1)).squareRoot()
}

2. Path MTU — the obvious approach silently lied

Path MTU = the largest packet that reaches the destination unfragmented. Classic VPN
debugging: if your tunnel caps MTU at 1420 and the app sends 1500 with DF set, packets
vanish and "the internet works but half the sites don't load."

The algorithm is a binary search: send a Don't-Fragment packet of growing size, watch
for ICMP "Fragmentation Needed." My first version sent UDP to a random high port
and treated ICMP Port Unreachable as the "it arrived" signal.

Testing against 1.1.1.1 it reported Path MTU = 688 bytes — nonsense. Cloudflare
(like most well-run hosts) silently drops UDP to random ports, so Port Unreachable
never comes back. Every timeout looked like "too big" and the search converged on junk.

Rewrote it on ICMP Echo with DF. Public hosts answer pings reliably, so "it fit"
became a real signal. And when a router returns Frag-Needed it includes its next-hop
MTU (RFC 1191), so you can jump straight to the answer:

static func extractNextHopMTU(from data: Data) -> Int? {
    let bytes = Array(data)
    guard bytes.count >= 8 else { return nil }
    let mtu = (UInt16(bytes[6]) << 8) | UInt16(bytes[7])
    return mtu > 0 ? Int(mtu) : nil
}

Bonus: the discovered value hints at the link type — 1492 → PPPoE, 1480 → GRE,
1420-1440 → WireGuard, 1400 → OpenVPN/IPSec.

3. Site Reach — TCP success doesn't mean "reachable"

A tool that checks whether popular sites are reachable. Naive version: TCP-connect to
443, success = "reachable." That misses the dominant modern block.

National/corporate DPI often lets the TCP handshake complete and only injects RST after
seeing the forbidden hostname in the SNI field of the TLS Client Hello. From the
device's view, TCP connected — so a TCP-only probe reports "reachable" while HTTPS
is actually dead.

To catch it, go all the way to the TLS handshake. Two probes, compared:

TCP	TLS	Verdict
fail	fail	IP block (or DNS pointing at a dead IP)
ok	fail	SNI / TLS block — DPI killed the Client Hello by hostname
ok	ok	actually reachable

The TLS probe uses NWConnection with NWProtocolTLS, which sets SNI to the
connection's hostname automatically — exactly what trips SNI-aware DPI. Flagged sites
get an "SNI" badge so they're distinct from plain unreachable ones.

The other six, briefly

TLS Inspector — probes TLS 1.0–1.3 in parallel (one NWConnection per version, min/max pinned), shows the negotiated cipher, flags deprecated 1.0/1.1 and weak ciphers.
Encrypted DNS — resolves a domain over DoH and DoT at Cloudflare/Google/Quad9/ NextDNS, compares answers + latency. Hand-rolled minimal DNS wire codec.
STUN / NAT — real RFC 5389 Binding Request to several servers, parses XOR-Mapped-Address, classifies NAT (Open / Cone / Symmetric) by whether the external port differs per server. The signal for whether VoIP/WebRTC/P2P will work.
Bonjour browser — NWBrowser over ~20 mDNS service types (AirPlay, Chromecast, HomeKit, printers) with TXT-record parsing.
HTTP/3 (QUIC) — real QUIC handshake via NWConnection + NWProtocolQUIC with ALPN "h3" on UDP/443. URLSession won't attempt QUIC without a cached Alt-Svc hint, so this is the only honest way to check whether your network passes QUIC.
IPv6 Check — local v6 enumeration with tunnel awareness (utun → iCloud Private Relay / NAT66), NAT64/DNS64 detection (RFC 7050), v4-vs-v6 latency.

Four takeaways

The "obvious" probe usually lies. UDP-to-random-port (Path MTU), TCP-only (Site Reach) — both give false results on real networks. Only a real protocol exchange — ICMP Echo with DF, a full TLS handshake — tells the truth.
Raw ICMP/UDP on iOS is more accessible than you'd think — a SOCK_DGRAM ICMP socket needs no entitlements and covers ping, traceroute, MTR, Path MTU. Raw SYN, ARP, and packet capture are still off-limits.
Test on two networks. Half my bugs only showed up comparing a clean European Wi-Fi against a cellular CGNAT/symmetric-NAT link — the false "blocks" lived there.
Network.framework is the right tool for TLS/QUIC. Where ICMP means BSD sockets, TLS Inspector and HTTP/3 are cleaner with NWConnection: version pinning, ALPN, a real QUIC handshake — all built in.

Everything still runs without private entitlements, and your diagnostic results never leave the device. The app does use Google AdMob and — added after this post — Google Analytics for Firebase for aggregate usage, both gated on consent where required. Full details: https://netdiag.online/privacy/

NetDiag+ on the App Store: https://apps.apple.com/app/apple-store/id6761954529?pt=128748487&ct=devto&mt=8 (13 languages, 25 tools)

Two write-ups from the same work:

Finding your Path MTU on iPhone — with a reference table of common values and the manual ping -f -l method: https://netdiag.online/guides/path-mtu-iphone/
Where the MTU field hides on Huawei / ZTE / TP-Link / Zyxel / Nokia routers: https://netdiag.online/guides/router-mtu/

Happy to answer implementation questions in the comments.

How I implemented ping and traceroute on iOS without entitlements

Dmytro Tishchenko — Thu, 21 May 2026 10:51:49 +0000

I just shipped v1.3 of a network diagnostics app I've been building on evenings and weekends — NetDiag+. It does ping, traceroute, DNS lookups, whois, LAN scanning, port scanning, SSL cert checking, BGP/ASN lookups, plus a host monitor that does background pings and pushes a notification when something goes down.

Stack: pure SwiftUI, iOS 16+, Swift Concurrency throughout, Darwin C-interop where it has to be. No third-party networking libraries — everything on raw BSD sockets through C-interop.

Wanted to share the implementation notes I would have appreciated finding myself when I started. A few things on iOS work differently than you'd expect from a Unix background, and the gotchas aren't where you think they are.

Spoiler on conclusions: the most painful part wasn't networking, it was integrating Google's UMP consent SDK for AdMob.

ICMP ping without entitlements

The first surprise: on iOS, you can open an ICMP socket without any special entitlement and without root, which is something you'd need CAP_NET_RAW or setuid for on Linux. Apple exposed this to regular sandboxed processes through SOCK_DGRAM (not SOCK_RAW):

final class ICMPSocket {
    private let fd: Int32

    init() throws {
        fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)
        guard fd >= 0 else {
            throw SocketError.creationFailed(errno)
        }
    }

    deinit {
        close(fd)
    }
    // ...
}

This is the same model macOS ping(8) has used since some old version when Apple dropped the setuid bit. The kernel writes the correct ICMP header for you (type/code/checksum for echo request), and rewrites the identifier to one it generates. That last bit is the first gotcha: on recv you don't get back the identifier you sent, so the standard logic of matching responses by identifier doesn't work.

The fix: match on sequence number and payload. I put my own marker in the payload and verify it on receive:

// Send
var header = ICMPHeader()
header.type = ICMPType.echoRequest.rawValue
header.code = 0
header.identifier = 0   // kernel will overwrite
header.sequence = currentSequence.bigEndian

let payload = makePayload(sequence: currentSequence)
let packet = header.bytes + payload
try socket.send(data: packet, to: address)

// Receive
let (data, fromIP) = try socket.receive()
guard let received = ICMPHeader.parse(data),
      received.type == ICMPType.echoReply.rawValue,
      received.sequence == currentSequence.bigEndian
else { continue }

Second gotcha: timeouts. recvfrom without SO_RCVTIMEO blocks indefinitely, which in Swift Concurrency means a stuck Task you then can't cancel cleanly. So I set a recv timeout on the socket:

func setTimeout(seconds: Double) {
    var tv = timeval(
        tv_sec: Int(seconds),
        tv_usec: Int32((seconds.truncatingRemainder(dividingBy: 1)) * 1_000_000)
    )
    setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, socklen_t(MemoryLayout<timeval>.size))
}

On EAGAIN/EWOULDBLOCK I throw my own SocketError.timeout, which higher up in the stack becomes a normal "timeout" hop in the result list.

Apple's SimplePing sample is the OG reference here — it's Objective-C, dated, but you can crib a lot from it. I ended up writing my own thin wrapper because SimplePing doesn't play nicely with modern Swift Concurrency and gets awkward for multi-host pings. No regrets.

Traceroute that actually works

Standard Unix traceroute has three flavors: ICMP echo (the Windows tracert style), UDP to closed ports (classic BSD), or TCP SYN (paris-traceroute, traceroute-tcp).

I tried the ICMP variant first. The idea is straightforward — send ICMP echo with a low TTL, listen for ICMP Time Exceeded from an intermediate hop, increment TTL. On paper, fine. In practice I hit two problems on iOS:

setsockopt(IP_TTL) on a SOCK_DGRAM ICMP socket behaves inconsistently. Some networks worked, others wouldn't return Time Exceeded reliably.
Matching incoming responses. On receive you get back an ICMP Time Exceeded, and the inner payload contains the original packet you sent. Matching the response to a specific TTL step means parsing inner payloads, which felt fragile.

So I switched to the classic BSD approach: UDP packets to closed ports with incrementing TTL, with a passive ICMP socket listening for Time Exceeded:

let icmpSock = try ICMPSocket()  // receive-only
icmpSock.setTimeout(seconds: timeout)

for ttl in 1...maxHops {
    let udpSock = try UDPSocket()
    udpSock.setTTL(ttl)

    var dest = address
    dest.sin_port = (port + UInt16(ttl - 1)).bigEndian  // 33434, 33435, ...

    let probe = Data(repeating: 0x40, count: 32)
    let sendTime = CFAbsoluteTimeGetCurrent()
    try udpSock.send(data: probe, to: dest)

    let (data, fromIP) = try icmpSock.receive()
    let rtt = CFAbsoluteTimeGetCurrent() - sendTime
    // ...
}

The 33434+TTL port choice is traceroute(8)'s historical pick from the 80s — those ports are unlikely to be open on the destination, so you're guaranteed to get either ICMP Time Exceeded from an intermediate hop or ICMP Port Unreachable from the destination, and both cases are handled uniformly.

Key insight: UDP_TTL works fine on iOS via setsockopt(IP_TTL), unlike the ICMP variant. The ICMP socket is purely a passive receiver — we never send from it, only read incoming Time Exceeded packets.

Final hop detection is two-way:

let isFinal = fromIP == destIP
    || header.type == ICMPType.destinationUnreachable.rawValue

Either the response came from the destination IP (meaning it sent us Port Unreachable), or the ICMP type is Destination Unreachable.

LAN scanner: no ARP for you

This is where iOS cuts harder. You don't get the system ARP table in userspace. There's no getarp(), no /proc/net/arp like on Linux. So the obvious "read the ARP table and list neighbors" idea is dead on arrival.

What you do get:

Concurrent TCP connect on common ports (80, 443, 22, 8080, etc). If a host responds (SYN+ACK or RST), it's alive. Raw SYN is locked down — only a full TCP handshake works.
mDNS / Bonjour discovery via NetServiceBrowser or NWBrowser. Partial coverage — only sees devices that advertise services.
NSLocalNetworkUsageDescription in Info.plist is mandatory. Without it, the first attempt to connect to a local IP triggers a "Local Network Access" alert, and nothing works until the user answers. Burned half an evening figuring this out the first time.

I went with the TCP connect approach via withThrowingTaskGroup:

private static let maxConcurrentProbes = 20

func discoverHosts(localIP: String, subnetMask: String) -> AsyncThrowingStream<LANDevice, Error> {
    AsyncThrowingStream { continuation in
        Task.detached {
            let range = Self.calculateSubnetRange(ip: localIP, mask: subnetMask)

            try await withThrowingTaskGroup(of: LANDevice?.self) { group in
                var activeCount = 0
                for ip in range {
                    if activeCount >= Self.maxConcurrentProbes {
                        if let device = try? await group.next() {
                            if let d = device { continuation.yield(d) }
                        }
                        activeCount -= 1
                    }
                    group.addTask {
                        try await Self.probeHost(ip: ip)
                    }
                    activeCount += 1
                }
                for try await device in group {
                    if let d = device { continuation.yield(d) }
                }
            }
            continuation.finish()
        }
    }
}

One connect() to port 80 with a 500ms timeout per IP across a /24 — the host responds with SYN+ACK (alive), RST (alive but port closed, also counts as alive), or times out (dead or filtered). With maxConcurrentProbes = 20 the whole /24 finishes in 2-3 seconds.

iOS 17 gotcha: the "Local Network Access" alert shows only once. If the user denies it, subsequent connect() calls just silently time out, with no clear error. Had to add a UI hint nudging the user to Settings.

Host monitor: BGTaskScheduler as it is

The most engineering-painful part of the app. The user-facing requirement: "I add hosts to monitor, and if one goes down I get a push, like UptimeRobot." On iOS you can't do this properly because:

No persistent background thread. iOS kills your app ~30 seconds after backgrounding.
Silent push as a wake mechanism exists but needs a server, and I wanted everything local.
BGTaskScheduler gives you ~30 sec of CPU maybe once every 15+ minutes. iOS decides when based on user behavior patterns.

So monitoring precision on iOS is fundamentally worse than on a server. You have to accept that and design around it.

What I do:

BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.netdiag.hostmonitor", using: nil) { task in
    Task {
        await HostMonitorService.shared.runMonitoringPass()
        task.setTaskCompleted(success: true)
    }
    submitNext()
}

let request = BGAppRefreshTaskRequest(identifier: "com.netdiag.hostmonitor")
request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
try BGTaskScheduler.shared.submit(request)

Inside runMonitoringPass():

Fetch all monitored hosts
Ping them in parallel (withTaskGroup) — fit within the 30-second budget
For each: if state changed (up→down or down→up), fire a local notification
If state unchanged, stay quiet

No "host still up every 5 minutes" pings. Only state transitions. This both helps with iOS background limits and respects the user.

Debugging gotcha: BGTaskScheduler doesn't fire in the simulator unless you manually trigger it via debugger:

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.netdiag.hostmonitor"]

Found this in some old DTS thread. Without that command, debugging background logic is impossible. On real devices the system runs your tasks unpredictably.

AdMob and UMP — the part that actually hurt

Networking was a pleasure to write. AdMob integration was a separate ordeal.

AdMob via the GoogleMobileAds Swift Package itself is fine — MobileAds.shared.start(), banners through BannerView in a UIViewRepresentable, standard stuff.

The pain begins with GDPR / CCPA consent, which Google requires through their UMP SDK (GoogleUserMessagingPlatform). Two problems:

SwiftUI documentation is essentially nonexistent. Every Google example is Objective-C or old UIKit. You figure out the SwiftUI integration by trial and error.
AdMob won't activate your privacy message until you ship a "revocation link" in the live app — that is, a button in Settings that re-opens the consent form. The business logic is: build the revocation link in code → ship that build → then go back to AdMob and confirm "yes, my app has the revocation link, please activate the message." Nowhere is this clearly stated. I sat on a configured but inactive consent message for a week before figuring it out.

The integration looks like this:

@MainActor
final class ConsentManager: ObservableObject {
    static let shared = ConsentManager()

    @Published private(set) var adsStarted = false
    @Published private(set) var privacyOptionsRequired = false

    func requestConsentAndStartAds() {
        let parameters = RequestParameters()

        ConsentInformation.shared.requestConsentInfoUpdate(with: parameters) { [weak self] error in
            ConsentForm.loadAndPresentIfRequired(from: Self.topViewController()) { [weak self] formError in
                self?.updatePrivacyOptionsAvailability()
                self?.startAdsIfNeeded()
            }
        }
    }

    func presentPrivacyOptionsForm() {
        guard let root = Self.topViewController() else { return }
        ConsentForm.presentPrivacyOptionsForm(from: root) { [weak self] error in
            self?.updatePrivacyOptionsAvailability()
        }
    }

    private func startAdsIfNeeded() {
        guard ConsentInformation.shared.canRequestAds else { return }
        MobileAds.shared.start { [weak self] _ in
            self?.adsStarted = true
        }
    }
    // ...
}

The key part: MobileAds.shared.start() is only called after the UMP flow returns canRequestAds == true. If a user in the EEA refuses, canRequestAds stays true anyway, ads just become non-personalized. The same flow covers both GDPR (EEA/UK) and US state privacy (CCPA in California and other regulated states), because UMP under the hood inspects geo and serves the matching message.

Another gotcha: ATTrackingManager.requestTrackingAuthorization (the ATT prompt) must come before the UMP flow, because UMP checks the ATT state when building the request:

ATTManager.requestTrackingIfNeeded {
    ConsentManager.shared.requestConsentAndStartAds()
}

Wrong order and UMP might think tracking is granted, then ATT denies, creating a mismatch AdMob can later flag.

For debug builds I force the geography to test the flow:

#if DEBUG
let debugSettings = DebugSettings()
debugSettings.geography = .EEA  // or .regulatedUSState
parameters.debugSettings = debugSettings
#endif

Without this, from a non-EEA IP the consent form never shows and you can't validate the flow at all.

Localization

12 languages (en, ru, uk, de, es, pt-BR, fr, it, pl, ja, ko, tr) using the new Xcode String Catalogs (.xcstrings). After years of Localizable.strings, the Catalog format is just nice — JSON, diffs reasonably in git, Xcode has a usable GUI for translation, automatic pluralization. If you're still on .strings, migrate, you're losing nothing.

What I'd do differently

Don't skimp on tests for ICMP header parsing. I have decent tests on DNS resolver and whois parser, but I debugged the ICMP path against live networks. It worked for 30 hosts; then two days after release I found a bug with big-endian sequence numbers. Embarrassing.
Build UMP from day one, before submitting to TestFlight. Retrofitting UMP after the fact rewrites your AdMob initialization order, ATT timing, etc. Just bake it in.
Don't trust the simulator for anything touching background tasks, mDNS, or push notifications. I had several "green in simulator, dead on device" moments.

Numbers and context

App went live a few weeks ago. ~30 total installs at the time of writing — basically zero marketing happened. This post is part of changing that.

AdMob after the first week post-approval: $1.19 eCPM, 85% match rate — "normal for a utility at launch" according to indie folks I've asked.

If you've done iOS network programming and hit different walls, I'd love to compare notes. Apple's networking stack isn't where most iOS devs spend their time and good references are scattered.

Links

App Store: https://apps.apple.com/app/apple-store/id6761954529?pt=128748487&ct=devto&mt=8
How to find your Path MTU on iPhone — reference table of common values and the manual ping -f -l method: https://netdiag.online/guides/path-mtu-iphone/
Where the MTU field hides on Huawei / ZTE / TP-Link / Zyxel / Nokia routers: https://netdiag.online/guides/router-mtu/
Apple's SimplePing sample (historical reference): https://developer.apple.com/library/archive/samplecode/SimplePing/Introduction/Intro.html
BGTaskScheduler docs: https://developer.apple.com/documentation/backgroundtasks
Google UMP SDK docs: https://developers.google.com/admob/ios/privacy

App is free with a banner, one-time IAP to remove ads. No accounts. Analytics is Google Analytics for Firebase (aggregate usage only, gated on the same consent flow as ads) — added after this post was written; diagnostic results never leave the device. Full details: https://netdiag.online/privacy/