Debugging network connections on macOS with nettop

Recently I’ve been learning Rust, and by far the simplest way to install that is to use Rustup. That works really well on my home computer, but I wanted to try solving a problem I had at work using Rust, so I tried it on my work Mac. My company’s network has a fairly restrictive set of firewalls, and I found that rustup was somehow failing to connect to the network to download the indexes it needs. The verbose output didn’t give me any clues, and I found it hard to narrow down what it was trying to do using tcpdump.

After some searching, I came across nettop. It seems to a tool originating from BSD that is mostly used for monitoring network activity across the system, but it’s also possible to narrow it down to a single process:

sudo nettop -p rustup -L 0

This shows all the network connections being made processes called rustup, in this sort of format:

21:40:52.233621,tcp4 192.168.33.10:50963<->server-99-84-8-62.lhr62.r.cloudfront.net:443,utun1,SynSent,0,0,0,0,0,0.00 ms,131072,0,BE,-,cubic,-,-,-,-,

This indicates that rustup is trying to connect to port 443 on a server in Cloudfront.

The rustup issue

In this case, it turns out that for some reason it was trying to connect to our corporate web proxy on port 8080 instead of port 80. The proxy is set in my environment as http://corporate-proxy.example.org:80. I tweeted about this, and Daniel Silverstone found that there was an edge case in the url crate used by the env_proxy crate, in turn used by Rustup to parse the https_proxy environment variable–it would omit the port 80 as that is the default for HTTP, and then env_proxy would assume that because the port had been omitted it should try 8080. This should be fixed shortly! Thanks again to Daniel for the help.