# Masscan: an Internet-scale port scanner with its own TCP/IP stack

> Masscan is an asynchronous SYN scanner written in C that can sweep the whole IPv4 space from one machine. It is fast, deliberately narrow in scope, and it fights your operating system's network stack unless you configure around it.

**robertdavidgraham/masscan** — TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.

- Repository: https://github.com/robertdavidgraham/masscan
- Stars: 26,047 · Forks: 3,241
- Language: C
- License: AGPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/robertdavidgraham-masscan

## The problem Masscan solves: breadth, not depth

Most port scanners are built to interrogate a host thoroughly. Masscan is built to ask one narrow question across an enormous number of addresses: is this port open? The README states the tool can scan the entire Internet in under five minutes, transmitting 10 million packets per second from a single machine, and that its parameters and output resemble nmap's. The resemblance is intentional and partial. The README is explicit that features supporting widespread scanning of many machines are supported, while in-depth scanning of single machines is not. That sentence is the whole design brief.

The audience is therefore narrow. Network operators mapping their own address space, researchers measuring exposure across the Internet, and red teams that need a fast first pass before spending time on individual hosts. If you want service version fingerprints, NSE scripts or OS detection for a handful of machines, Masscan is the wrong instrument and the README says so indirectly by pointing you at nmap's feature set with that caveat attached.

## Asynchronous transmission and the ad hoc TCP/IP stack

Masscan does not use the operating system's TCP stack to open connections. The README describes asynchronous transmission, similar to scanrand, unicornscan and ZMap, and notes that Masscan is more flexible in allowing arbitrary port and address ranges. Rather than tracking a bounded set of sockets, it emits SYN packets as fast as the interface allows and matches the replies it gets back, which is what makes 10 million packets per second plausible from one host.

That choice has a direct consequence. The README warns that Masscan uses its own ad hoc TCP/IP stack and that anything beyond simple port scans may conflict with the local stack. When the kernel sees a SYN-ACK for a connection it never opened, it answers with a RST and kills the exchange before Masscan can read anything. This is not a bug to be patched away; it is the price of bypassing the kernel. The documented workarounds are to run from a different IP with --src-ip, or to pin Masscan to a source port with --src-port and then firewall that port so the local stack never sees the reply. The README also notes Windows does not respond with RST packets, so neither workaround is strictly needed there, though it still recommends running Masscan on its own IP.

## Installing Masscan from source on Debian or Ubuntu

There is no package manager step in the README. The documented path is a C compiler, make, git and the source tree. On Debian or Ubuntu the README gives this sequence, which installs the build tools, clones the repository and compiles it:

```bash
sudo apt-get --assume-yes install git make gcc
git clone https://github.com/robertdavidgraham/masscan
cd masscan
make
```

The binary lands in the masscan/bin subdirectory after the build finishes. If you want it on the system path, the README gives a separate install target:

```bash
make install
```

The README notes the source is split into many small files, so a parallel build is much faster, but warns that using all available threads needs more than 2 GB of RAM on a Raspberry Pi and breaks there. A smaller job count is the documented alternative:

```bash
make -j4
```

Linux is the primary target, but the README lists Windows with Visual Studio, Windows with MinGW, macOS with Xcode or the command line, and FreeBSD with gmake. Cygwin is called out as not working. On macOS the README states the x86 binaries appear to run just as fast under ARM emulation.

## A first real scan and the --echo round trip

The README's basic example scans two subnets for port 80 and the range 8000 to 8100, 102 ports in total, and writes results to stdout:

```bash
masscan -p80,8000-8100 10.0.0.0/8 2603:3001:2d00:da00::/112
```

For anything you intend to repeat, the --echo flag is the more useful entry point. It dumps the current configuration and exits, and the README states that output can be fed back in as input:

```bash
masscan -p80,8000-8100 10.0.0.0/8 2603:3001:2d00:da00::/112 --echo > xxx.conf
masscan -c xxx.conf --rate 1000
```

That second line is where you control the packet rate. The README shows a rate of 1000 in the example rather than the default, which matters because the default is tuned for the Internet-scale case and will saturate a small link or trip intrusion detection on a corporate network. If you want banner information rather than just open or closed, add --banners and reserve a source address first, for example masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200. The README warns the address must be on the local subnet and not in use by another system, and that picking a bad one can disrupt that machine's communications for several minutes.

## Banner grabbing and why it needs a reserved source port

Masscan can complete a TCP interaction far enough to collect a banner. The README lists FTP, HTTP, IMAP4, memcached, POP3, SMTP, SSH, SSL, SMBv1, SMBv2, Telnet, RDP and VNC as supported protocols. The --heartbleed check is described as a form of banner checking and needs the same setup.

The setup is the awkward part. Because the local stack answers the target's SYN-ACK with a RST, banner collection fails unless the kernel never sees that packet. The documented Linux approach is to drop incoming traffic on the port Masscan uses and then tell Masscan to use it:

```bash
iptables -A INPUT -p tcp --dport 61000 -j DROP
masscan 10.0.0.0/8 -p80 --banners --source-port 61000
```

Choosing 61000 is not arbitrary. The README points at /proc/sys/net/ipv4/ip_local_port_range to see what the kernel hands out for outgoing connections, and notes that on Kali Linux as of August 2018 that range was 32768 to 60999, so a source port below 32768 or at 61000 and above avoids a collision. On macOS and BSD the equivalent question is answered by sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last, with ipfw on FreeBSD and older macOS and pf on newer macOS and OpenBSD. The README gives block in proto tcp from any to any port 40000:40015 as the pf.conf line and pfctl -E or pfctl -f /etc/pf.conf to apply it. One detail worth flagging: the README states an iptables rule only lasts until reboot, and that saving it is distro-specific via iptables-save or iptables-persistent. Nothing in the README automates that persistence.

## Where Masscan is the wrong tool

The README's own warning is the strongest limitation on the page. It states plainly that scanning the entire Internet is bad, that parts of the Internet react badly to being scanned, and that some sites track scans and add you to a ban list, which gets you firewalled from useful parts of the Internet. The 0.0.0.0/0 -p0-65535 example is presented as what the tool is designed for, not as a recommendation.

Beyond etiquette, there are mechanical limits. The ad hoc stack means any scan that needs a real TCP handshake, application-layer negotiation or stateful follow-up is out of scope; the README frames the tool as supporting widespread scanning of many machines and not in-depth scanning of single machines. Running it on a laptop over WiFi is a documented problem case, because you cannot always assign a second IP and must fall back to firewalling a source port. And the build itself has a memory floor: the README notes a full parallel make on a Raspberry Pi needs more than 2 GB and breaks without it, which is an unusual constraint for a tool with, in its own words, no dependencies other than a C compiler.

## Masscan versus Nmap, and versus ZMap

The README names nmap as the reference point for usage and output, and names scanrand, unicornscan and ZMap as the asynchronous scanners it resembles internally. The practical difference against Nmap is architectural rather than cosmetic. Nmap uses the host's networking to open connections and can therefore do service version detection, OS fingerprinting and scripted probes, at a rate bounded by connection tracking. Masscan bypasses that path entirely to reach packet rates the kernel would not sustain, and gives up the depth that comes with using the kernel.

Against ZMap the README's stated distinction is flexibility: Masscan allows arbitrary port and address ranges, where the asynchronous model in that family of tools is often paired with a fixed probe design. If your scan is one port across one address block, the difference is small. If you need 102 ports across a /8 and a /112 at the same time, as in the README's own example, Masscan's range handling is the reason to pick it. Neither comparison is settled by benchmarks here; the README makes the architectural claim and leaves measurement to the reader.

## Maintenance, licensing and what the repository shows

The last push to the master branch was on 2026-04-23, and the repository is not archived. The most recent tagged release listed is 1.3.2 from 2021-01-31, with 1.3.1 and 1.3.0 in the same month. That gap between commit activity and releases is worth knowing if you depend on versioned artifacts rather than building from a checkout; the README's build instructions are all source-based, and the Makefile derives a version string from git describe --tags, falling back to "unknown" when that fails. The Makefile also carries a note that macOS is not part of the author's regular regression environment and that something might be broken there at any given time, while Linux is where the automated tests run.

The licence is AGPL-3.0. That is a copyleft licence with a network-use clause, which is a materially different obligation from the permissive licences many network utilities carry. Anyone embedding Masscan in a hosted service or a commercial product should read the licence text in the repository rather than assume it behaves like a BSD-style tool; this is a description of the licence identifier, not legal advice. The README separately asks for donations to a Bitcoin address, which is not a licensing term.

## Conclusion

Adopt Masscan when the job is breadth: sweeping large address ranges for open ports and then handing the interesting hosts to a slower, deeper tool. Do not adopt it as a replacement for Nmap on single-host enumeration, service version detection or scripted checks, and do not run it with banners enabled on a host whose source IP and source port you have not reserved first. Before a first production run, verify three things on the target machine: that the build produces bin/masscan, that the chosen --source-port or --source-ip is outside the range reported by /proc/sys/net/ipv4/ip_local_port_range, and that the firewall rule blocking that port survives a reboot. The AGPL-3.0 licence is the other thing to settle early, because it reaches further than most network tools' licences do.

## FAQ

### What is Masscan?

Masscan is an Internet-scale TCP port scanner written in C. The README describes it as able to scan the entire Internet in under five minutes, transmitting 10 million packets per second from a single machine, using asynchronous transmission and its own ad hoc TCP/IP stack.

### What are the key differences between Nmap and Masscan?

Masscan's parameters and output are similar to nmap's, but the README states that features supporting widespread scanning of many machines are supported while in-depth scanning of single machines are not. Nmap uses the host's networking and can go deeper on one host; Masscan bypasses the kernel to reach much higher packet rates.

### How do I scan all ports using Masscan?

The README gives the full-range form as masscan 0.0.0.0/0 -p0-65535, and immediately warns that scanning the entire Internet is bad, that parts of the Internet react badly to being scanned, and that some sites will add you to a ban list.

### How do I install Masscan on Ubuntu?

The README's Debian and Ubuntu path is sudo apt-get --assume-yes install git make gcc, then git clone https://github.com/robertdavidgraham/masscan, cd masscan and make. The binary is placed in the masscan/bin subdirectory, and make install installs it on Linux.

### How do I install Masscan on Kali Linux?

The README does not give a Kali-specific install command; its documented build path is the Debian and Ubuntu one using git, make and gcc. Kali does appear in the README as the source of the observed source-port range of 32768 to 60999, which is the range to avoid when choosing --source-port for banner grabbing.

### How do I use Masscan on Windows?

The README lists Windows with Visual Studio via the VS10 project and Windows with MinGW by typing make; cygwin is stated not to work. It also notes Windows does not respond with RST packets, so the source-IP and source-port workarounds needed for banner grabbing on Linux are not strictly necessary there.

## Sources

- [Issues](https://github.com/robertdavidgraham/masscan/issues)
- [License: AGPL-3.0](https://github.com/robertdavidgraham/masscan/blob/master/LICENSE)
- [README](https://github.com/robertdavidgraham/masscan/blob/master/README.md)
- [Releases](https://github.com/robertdavidgraham/masscan/releases)
- [robertdavidgraham/masscan on GitHub](https://github.com/robertdavidgraham/masscan)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/robertdavidgraham-masscan