robertdavidgraham
#559 still not fixed? (`CONF: unknown config option: nocapture=servername`)
I echo a configuration into a file:
seed = 9576739939856650050
rate = 500000.000000
shard = 1/1
nocapture = servername
# TARGET SELECTION (IP, PORTS, EXCLUDES)
ports = 443
range = 0.0.0.0-255.255.255.254
I resume it with masscan -c masscan.conf:
CONF: unknown config option: nocapture=servername
It looks as if the issue has already been documented and fixed in #559 - 3 years ago! For some reason, after installing masscan today with sudo pacman -S masscan, it's still broken.
masscan --version:
Masscan version 1.3.2 ( https://github.com/robertdavidgraham/masscan )
Compiled on: Feb 9 2021 23:48:38
Compiler: gcc 10.2.0
OS: Linux
CPU: unknown (64 bits)
This seems to also be the latest release on github. Why is it still a problem?
I have exactly the same behaviour under Arch. I deleted the line and was able to continue the scan, but I would agree with Blayung's question.
Same issue here. Using masscan version 1.3.2 compiled on feb 2 2021 11:13:27 with gcc 10.2.1 20210110.
Same issue here. Using masscan version 1.3.2 compiled on feb 2 2021 11:13:27 with gcc 10.2.1 20210110.
This just in: 4 year old build has 4 year old bugs in it 😂
As I understand it, you should be reporting this to the masscan package maintainer for Arch.
For future reference, though, don’t use distribution packages. Always build from github source. A lot has changed over the past few years. Even more than usual as @p-l- & co started making enhancements for ivre
Here ya go, package page for Arch:
https://archlinux.org/packages/extra/x86_64/masscan/
@mzpqnxow Why don't they release newer versions on github at least? The package maintainer must have seen that they aren't releasing anything on github (just pushing code) and so he didn't update his package.
@mzpqnxow Why don't they release newer versions on github at least?
If you're referring to binary builds- personally, I don't see any value in binary builds for masscan, it has close to zero build-time dependencies and building it is (literally!):
$ apt-get install build-essential libpcap-dev && git clone ... && make -j && make install
Maybe they share my opinion. Or maybe it's a pain to build for all of the supported platforms and nobody had the time or interest to own it
The package maintainer must have seen that they aren't releasing anything on github (just pushing code) and so he didn't update his package.
I think it's more likely they're just busy, and users are complaining about issues upstream (here!) rather than to him 😆
Teasing aside, really, send the dude a note- odds are he doesn't follow the project or use it that often; it's a niche tool. Maybe you can take over for him, or help him out. At the very least, let him know there's an issue
Regardless of whether the distributions get their stuff together (Kali probably has an even older version) I would still advise any user to always use the github source, and always check open issues.
Unlike many other ubiquitous security tools, there's not really a big developer community, funding, etc. for masscan. And it's barely even a side project for Rob. So there's not really any release cycle or meticulously updated changelog. There's only an occasional tagging of a branch.
@p-l- may correct some of my statements above, I'm actually not certain if he has started (or is planning to start) tagging source releases, or making binary builds available.
For reference, the merge of the PR (which I actually forgot was one I submitted) is @ https://github.com/robertdavidgraham/masscan/commit/90791550bbdfac8905917a109ed74024161f14b3
I just tested with a build from master. While I see a quirk, I don't see the issue as described
After building:
9:24:41 › bin/masscan --version
Masscan version 1.3.9-integration ( https://github.com/robertdavidgraham/masscan )
Compiled on: Apr 28 2025 09:10:26
Compiler: gcc 12.2.0
OS: Linux
CPU: x86 (64 bits)
GIT version: 1.3.2-211-ga31feaf
Trying to reproduce the initial issue as described:
9:18:15 › cat > masscan.conf << 'EOF'
heredoc> seed = 9576739939856650050
rate = 500000.000000
shard = 1/1
nocapture = servername
# TARGET SELECTION (IP, PORTS, EXCLUDES)
ports = 443
range = 0.0.0.0-255.255.255.254
heredoc> EOF
Then, resume as described (note that the --exclude 255.255.255.255 is required as a confirmation to scan such a large range - if you don't need to do this, it's an indicator that your build is out of date)
9:18:35 › sudo bin/masscan -c masscan.conf --exclude 255.255.255.255
Starting masscan 1.3.9-integration (http://bit.ly/14GZzcT) at 2025-04-28 13:18:50 GMT
Initiating SYN Stealth Scan
Scanning 4294967295 hosts [1 port/host]
I do not see the error CONF: unknown config option: nocapture=servername, so I think it is just an issue with downstream distributions not building from master, not a regression associated with #559
I understand that some users and maintainers might prefer the traditional <major>.<minor> versioning convention, but for better or worse, masscan uses the git commit ID as the version identifier, because there is no formal release cadence.
While this may sound difficult for a package maintainer, it's actually just as easy to use a commit ID in place of a branch - simply use --branch <commitid> rather than --branch X.Y.Z
@mzpqnxow Why don't they release newer versions on github at least?
If you're referring to binary builds- personally, I don't see any value in binary builds for masscan, it has close to zero build-time dependencies and building it is (literally!):
$ apt-get install build-essential libpcap-dev && git clone ... && make -j && make install
It's generally a bad practice to install things manually outside of a development environment, you will end up with inconsistent versions across hosts, and no central way to see what versions you have or keep them up to date. Package management provides a lot of highly useful functions.
Also I think the parent was referring to release tags, and then someone else builds the binary versions.
Maybe they share my opinion. Or maybe it's a pain to build for all of the supported platforms and nobody had the time or interest to own it
The package maintainer must have seen that they aren't releasing anything on github (just pushing code) and so he didn't update his package.
I think it's more likely they're just busy, and users are complaining about issues upstream (here!) rather than to him 😆
Generally you push code during development, and tag releases for production ready versions. Most package maintainers would not grab a random snapshot from a git repo as this usually represents highly unstable in-development code.
Also packaging tools are set up for the traditional x.y.z release system, as they will automatically assume that x+1 is newer than x etc. If the release tag is a hash there's no way to order them without additional information.
😞
I'm trying to help you, sir/madam.
Generally you push code during development, and tag releases for production ready versions.
Perhaps, though generally, you don't send millions of SYN packets across the Internet either 😊
Most package maintainers would not grab a random snapshot from a git repo as this usually represents highly unstable in-development code.
I agree, that would be a silly novelty distribution ("DiceOS: Roll the dice, hope it works!")
... but nobody is suggesting anything "random".
Commit IDs are barely different from tags. Use the right one and you're all set.
Also packaging tools are set up for the traditional x.y.z release system, as they will automatically assume that x+1 is newer than x etc. If the release tag is a hash there's no way to order them without additional information.
Which packaging systems are you referring to? The most commonly used systems only reference an internal build number which is increased with each build. They only consider the package name and that build number
This is how apt/dpkg work for almost all packages. Ditto for yum/rpm.
... for a reason.
It had to be this way, for situations like this; distributions often release the same version multiple times, with custom or back-ported fixes applied.
Also- surprise, masscan is not the only project that doesn't defer to distribution maintainers on how to version or release their software. Some don't tag releases at all. Some use non-conforming versioning schemes, some are inconsistent or change the scheme in the middle of a minor release.
I'm not too familiar with more niche packaging systems, but I do know that Arch, as one example, seems to be designed specifically for handling situations like this, where there is no release tag. Guess what they use?
In Arch:
foo-git 20230914.r45.gabcdef1-1
^-- 20230914 = snapshot date, 45 commits after the last tag, from commit ID gabcdef1
My point is that this is not a process or technology issue and it will not be solved by release tags.
It's a human issue, you need to communicate to a human, rather than argue with me (especially as I have no commit privileges to this repository; also, I'm probably a bot)
You are empowered to solve it for everyone, with minimal effort.
Do this:
- Contact the maintainer of the package for your distribution
- Cite this Issue
- Instruct them to base a new build of the package on the current last commit ID
- Consider offering to take over maintenance of the package if it'a burdensome for them
Next, your package will be released in your distribution with an internal build number one greater than the previous, and your update will work. Everyone will laud you as a hero. And this issue can be resolved
Or, you can wait to have a dialogue with a maintainer here, while solving nothing for anyone. Either way, I can't help you beyond this advice.
Note, I still suggest you create a separate issue, asking if the maintainers would mind tagging a release. I prefer having release tags also, for the aesthetics 😀