Support for port range input like `1-22,661-669,8888` for both CLI and library usage

[Autumn-27]

Hi, thanks for the great work on RustScan. I’m referring to the previous pull requests #661 and #761. I’d like to reopen the discussion around supporting input like 1-22,661-669,8888 for port ranges.

In practice, when using RustScan either via CLI or as a library, it's quite common to specify ports using a format like 1-22,661-669,8888, especially when scanning common top ports. For example, a typical top 100 or top 1000 port list may include ranges and individual ports like:

21,22,23,25,53,67,68,80,110,111,139,143,161,389,443,445,465,512,513,514,873, 993,995,1080,1000,1352,1433,1521,1723,2049,2181,2375,3306,3389,4848,5000, 5001,5432,5900,5632,5900,5989,6379,6666,7001,7002,8000,8001,8009,8010,8069, 8080,8083,8086,8081,8088,8089,8443,8888,9900,9200,9300,9999,10621,11211, 27017,27018,66,81,457,1100,1241,1434,1944,2301,3128,4000,4001,4002,4100, 5800,5801,5802,6346,6347,30821,1090,1098,1099,4444,11099,47001,47002,10999, 7000-7004,8000-8003,9000-9003,9503,7070,7071,45000,45001,8686,9012,50500, 11111,4786,5555,5556,8880,8983,8383,4990,8500,6066

When this list includes ranges (like 7000-7004), it's not currently possible to pass them directly to RustScan in a user-friendly way. Users must extract and separate the ranges manually, which is especially cumbersome with larger lists like top 1000.

---

Why this matters

• Many common port dictionaries or scan profiles use the 1-22,80,443,8080-8090 style.
• When using RustScan programmatically, parsing and splitting these manually reduces efficiency and increases code complexity.
• Adding support for this notation would greatly improve usability and flexibility for both CLI users and developers using the RustScan crate.

Would it be possible to natively support this range notation?

Thanks again!

[PsypherPunk]

Hey, @Autumn-27.

I missed this discussion being raised and started taking a swing at the format mentioned in your PR with --port and --range still separate but would accommodate the above with:

rustscan … \
    --ports 21,22,23,25,53,67,68,80,110,111,139,143,161,389,443,445,465,512,513,514,873, 993,995,1080,1000,1352,1433,1521,1723,2049,2181,2375,3306,3389,4848,5000, 5001,5432,5900,5632,5900,5989,6379,6666,7001,7002,8000,8001,8009,8010,8069, 8080,8083,8086,8081,8088,8089,8443,8888,9900,9200,9300,9999,10621,11211, 27017,27018,66,81,457,1100,1241,1434,1944,2301,3128,4000,4001,4002,4100, 5800,5801,5802,6346,6347,30821,1090,1098,1099,4444,11099,47001,47002,10999,9503,7070,7071,45000,45001,8686,9012,50500,11111,4786,5555,5556,8880,8983,8383,4990,8500,6066 \
    --range 7000-7004 \
    --range 8000-8003 \
    --range 9000-9003

…however, having done it, I'm not particularly fond of it.

I think I'm in favour of your suggestion; a proposal for how to proceed would be:

1. update --ports to accommodate the format you suggest (comma-separated list of either single-ports or port-ranges)
   • I presume we'd want to deduplicate here to avoid repeat connections (that feels like a nice interview-style question)
2. keep --range (and the conflicts_with) but with the intention of deprecating it in a future version

Tagging @bee-san for their view…?

[Autumn-27]

In the scenario of quickly scanning the port, one is that it is convenient to scan the full port directly to 1-65535, but in most scenarios, it is to scan the top-level port list, which means that it is necessary to maintain a list of rustscan parameters, even if it sacrifices some small performance (negligible) in exchange for the convenience of parameters.

Integrating rustscan into automated programs will also cause inconvenience in operation.

[luckman212]

This would be a wonderful feature!