What is the problem your feature is trying to solve?
Testrun currently only carries out a UDP port scan for the ~15-20 port numbers explicitly referred to in test configurations. By default, this scan takes ~1-2 minutes to complete on my various Testrun machines against a range of DUTs, with the vast majority of the execution time consumed by nmap carrying out the version detection step (the actual UDP port open/closed detection step only takes ~15-20 seconds).
I believe historically there was a design decision made to not carry out a UDP scan against all ~65K ports for speed purposes. This is understandable, but I do believe Testrun could leverage some of the nmap tuning options to scan a larger range than the ~15-20 it does currently, and still complete in a reasonable time.
Describe the solution you think would solve the problem
UDP scans in nmap can be sped up considerably be reducing the --version-intensity as described here. By way of illustration, the below is a UDP scan against 1000 ports of an iSMA-B-MIX18-IP, a device that implements BACnet/IP.
C:\Users\DuncanGreene>nmap -sU -sV -Pn -n -v -T3 --scan-delay 2ms --version-intensity 0 --top-ports 1000 10.10.10.20
Starting Nmap 7.94 ( https://nmap.org ) at 2026-05-20 15:39 GMT Summer Time
NSE: Loaded 46 scripts for scanning.
Initiating ARP Ping Scan at 15:39
Scanning 10.10.10.20 [1 port]
Completed ARP Ping Scan at 15:39, 0.09s elapsed (1 total hosts)
Initiating UDP Scan at 15:39
Scanning 10.10.10.20 [1000 ports]
Completed UDP Scan at 15:40, 16.48s elapsed (1000 total ports)
Initiating Service scan at 15:40
Scanning 1 service on 10.10.10.20
Completed Service scan at 15:40, 5.01s elapsed (1 service on 1 host)
NSE: Script scanning 10.10.10.20.
Initiating NSE at 15:40
Completed NSE at 15:40, 0.00s elapsed
Initiating NSE at 15:40
Completed NSE at 15:40, 0.00s elapsed
Nmap scan report for 10.10.10.20
Host is up (0.00066s latency).
Not shown: 999 closed udp ports (port-unreach)
PORT STATE SERVICE VERSION
47808/udp open|filtered bacnet
MAC Address: 00:1E:C0:FC:7D:D5 (Microchip Technology)
Read data files from: C:\Program Files (x86)\Nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 22.05 seconds
Raw packets sent: 1046 (49.372KB) | Rcvd: 1041 (58.268KB)
You'll see the entire scan was completed in 22 seconds, far quicker than the ~1-2 minutes Testrun currently takes to carry out its default UDP scan of ~15-20 ports.
You will see that the port state isn't gleaned quite so cleanly in the above, and so even if you ramped the --version-intensity back up to the default value of 7 (which is implied if not specified in the command), you'll see that the port state is now gleaned more thoroughly, and the scan still only took ~2 minutes (albeit only 1 port required service/version detection).
C:\Users\DuncanGreene>nmap -sU -sV -Pn -n -v -T3 --scan-delay 2ms --version-intensity 7 --top-ports 1000 10.10.10.20
Starting Nmap 7.94 ( https://nmap.org ) at 2026-05-20 15:41 GMT Summer Time
NSE: Loaded 46 scripts for scanning.
Initiating ARP Ping Scan at 15:41
Scanning 10.10.10.20 [1 port]
Completed ARP Ping Scan at 15:41, 0.06s elapsed (1 total hosts)
Initiating UDP Scan at 15:41
Scanning 10.10.10.20 [1000 ports]
Completed UDP Scan at 15:42, 16.89s elapsed (1000 total ports)
Initiating Service scan at 15:42
Scanning 1 service on 10.10.10.20
Completed Service scan at 15:43, 102.65s elapsed (1 service on 1 host)
NSE: Script scanning 10.10.10.20.
Initiating NSE at 15:43
Discovered open port 47808/udp on 10.10.10.20
Completed NSE at 15:43, 0.03s elapsed
Initiating NSE at 15:43
Completed NSE at 15:43, 0.00s elapsed
Nmap scan report for 10.10.10.20
Host is up (0.00051s latency).
Not shown: 999 closed udp ports (port-unreach)
PORT STATE SERVICE VERSION
47808/udp open bacnet
MAC Address: 00:1E:C0:FC:7D:D5 (Microchip Technology)
Read data files from: C:\Program Files (x86)\Nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 120.11 seconds
Raw packets sent: 1046 (49.372KB) | Rcvd: 1042 (58.324KB)
Feel free to experiment yourselves, but with an eye on Testrun scanning the full ~65K port range for TCP, which presumably is done for a specific reason, it seems odd to constrain the port range for UDP, where optimisations can be leveraged to improve scan time.
If version detection isn't specifically required (is it?), then as you'll see in the above excerpts, the actual UDP scan for 1,000 ports can be completed within ~15-20 seconds, before the version detection step is carried out afterwards. Obviously this is very device dependent, but it could be worth investigating. Even the top 100 UDP ports could be seen as better than the ~15-20 currently specified in test configurations.
Additional context
Above correct as of Testrun v2.3.3.
What is the problem your feature is trying to solve?
Testrun currently only carries out a UDP port scan for the ~15-20 port numbers explicitly referred to in test configurations. By default, this scan takes ~1-2 minutes to complete on my various Testrun machines against a range of DUTs, with the vast majority of the execution time consumed by nmap carrying out the version detection step (the actual UDP port open/closed detection step only takes ~15-20 seconds).
I believe historically there was a design decision made to not carry out a UDP scan against all ~65K ports for speed purposes. This is understandable, but I do believe Testrun could leverage some of the nmap tuning options to scan a larger range than the ~15-20 it does currently, and still complete in a reasonable time.
Describe the solution you think would solve the problem
UDP scans in nmap can be sped up considerably be reducing the
--version-intensityas described here. By way of illustration, the below is a UDP scan against 1000 ports of an iSMA-B-MIX18-IP, a device that implements BACnet/IP.You'll see the entire scan was completed in 22 seconds, far quicker than the ~1-2 minutes Testrun currently takes to carry out its default UDP scan of ~15-20 ports.
You will see that the port state isn't gleaned quite so cleanly in the above, and so even if you ramped the
--version-intensityback up to the default value of 7 (which is implied if not specified in the command), you'll see that the port state is now gleaned more thoroughly, and the scan still only took ~2 minutes (albeit only 1 port required service/version detection).Feel free to experiment yourselves, but with an eye on Testrun scanning the full ~65K port range for TCP, which presumably is done for a specific reason, it seems odd to constrain the port range for UDP, where optimisations can be leveraged to improve scan time.
If version detection isn't specifically required (is it?), then as you'll see in the above excerpts, the actual UDP scan for 1,000 ports can be completed within ~15-20 seconds, before the version detection step is carried out afterwards. Obviously this is very device dependent, but it could be worth investigating. Even the top 100 UDP ports could be seen as better than the ~15-20 currently specified in test configurations.
Additional context
Above correct as of Testrun v2.3.3.