Services module detects resolved device IP during startup but then ignores it which causes services module timeout

[duncangreene]

Describe the bug
I may well have missed something, but it appears the services module correctly detects resolved DUT IP during startup but then ignores it which causes no services testing to take place and then ultimately a module timeout.

Manifested as below in report.

Below in logs. You can see Testrun has successfully detected DUT IP of 10.10.10.16.

Wireshark appears to show Testrun cyclically trying to resolve 10.10.10.14 instead.

Expected behavior
Testrun presumably should be running tests against the DUT IP of 10.10.10.16 instead.

Error logs
report (35).zip

Environment (please provide the following information about your setup):

• OS: Ubuntu 22.04.5
• Version: 2.1.1 (modifications from official 2.1.1 release are as below)
  • make/DEBIAN/control (Mod version number to append "-oss.1.0")
  • resources/test_packs/qualification/config.json (Set tests to excluded/recommended/informational as appropriate)
  • resources/devices/device_profile.json (Add custom questions)

Additional context
Interestingly the protocol.services.bacnet test is excluded from our test pack, but appears in the results table for some reason.

[MariusBaldovin]

@duncangreene The device IP has been successfully resolved. You can increase the Services Module timeout. The TCP scan hasn't been completed within 15 minutes for this device and the module was timed out.

[duncangreene]

@MariusBaldovin where are you deciphering that the TCP scan hasn't been completed? By the looks of the services.pcap file, there are no TCP packets at all, which seems to suggest the scan never even started?

[MariusBaldovin]

@duncangreene I was following the logs. Indeed, the services.pcap file contains no TCP packets and suggests that the TCP scan hasn't started.

[jboddey]

This has been resolved and will be released in v2.2