Repository navigation
device has static IP support only #1450
Description
I'm bringing two issues to your attention regarding the current test run.
First, the DUT does not support dynamic IP assignment and only allows for static IP assignment. Due to this limitation, the test run cannot obtain the DUT's IP address.
Additionally, I am experiencing a connectivity issue on the Linux PC. After running the Docker container, the machine is no longer able to connect to the internet.
Activity
hitnik commentedon Feb 26, 2026
@FurqanChaudhary "Additionally, I am experiencing a connectivity issue on the Linux PC. After running the Docker container, the machine is no longer able to connect to the internet." This is expected behavior, as Testrun creates a virtual network and temporarily modifies routes on the host device to conduct tests.
What do you mean by a dynamic IP address? The DUT must have the DHCP client enabled and no static IP addresses assigned.
duncangreene commentedon Feb 26, 2026
Just voicing that I would also like to see Testrun not implicitly rely on DHCP for its core functionality.
Many devices don't support DHCP, and many network installations don't mandate it, especially for critical environments. To this end, DHCP functionality ought to be regarded by Testrun as just another feature to 'test' support for, as opposed to mandating that it be implemented in order for a device to progress to the Monitoring phase.
FurqanChaudhary commentedon Feb 27, 2026
The DUT device is for the elevator, which does not support DHCP, as it communicates directly with the elevator's main controller without connecting to external environments.
Given this specific configuration, could you please clarify if a TestRun is still mandatory for this scenario?
IMINABO1 commentedon Jul 3, 2026
I've opened PR #1566 to add optional static IP support for this case.
My approach is that if a device's
device_config.jsonincludes an"ip_addr"field, Testrun uses that address directly and skips the DHCP wait. Devices withoutip_addrkeep the existing DHCP behavior.Current status: the PR conflict has been resolved and CLA is passing. The remaining required checks appear to be waiting for maintainer approval to run from the fork.
Happy to adjust the approach if maintainers prefer a different config shape or flow.
@jboddey
KrystsinaT commentedon Aug 6, 2026
The issue was discussed. You can adjust the approach and run from the fork. @hitnik approve please
hitnik commentedon Aug 6, 2026
Approved
duncangreene commentedon Aug 6, 2026
I've just gotten round to opening a PR containing my implementation for support for non-DHCP capable devices, see #1618 for further details.