Sporadic results in Services tests
- Dominant language
- Python
- Stars
- 56
- Forks
- 20
- Avg merge
- 15h 54m
- Merged PRs (30d)
- 12
Description
**Describe the bug**
In 2.2 I'm still seeing some sporadic results in Services tests. This issue was initially uncovered in #885 and seems to occur on more resource constrained devices, which are prevalent (and constrained _by design_) in the IoT/smart building world.

**Test A**

**Test B**

**Test C**

**Test D**

**Expected behavior**
The same device under the same conditions should yield the same results every time.
**Error logs**
[testA.zip](https://github.com/user-attachments/files/20087767/testA.zip)
[testB.zip](https://github.com/user-attachments/files/20087768/testB.zip) (Ignore the TLS server test errors, I suspect the device lost power during the TLS module tests)
[testC.zip](https://github.com/user-attachments/files/20087770/testC.zip) (Ignore the TLS module timeout, this is due to #[1178](https://github.com/google/testrun/issues/1178#issuecomment-2719142275))
[testD.zip](https://github.com/user-attachments/files/20087776/testD.zip)
**Environment (please provide the following information about your setup):**
- Version 2.2
**Additional context**
There was discussion on #885 previously about utilising nmap's inbuilt rate limiting features to mitigate the false negatives/false positives that can/will occur against devices currently.
The comment [here ](https://github.com/google/testrun/issues/885#issuecomment-2587628036)states that a second HTTP specific scan is carried out in 2.2 that may well resolve false negatives/false positives with the HTTP related tests, but this naturally doesn't cover all the other possible (good/bad?) service/port permutations out there (TCP 502 in the case of the device above, but that's just one device/service in this example).
Contributor guide
Assessment
This issue has not been assessed yet.