Testing hangs at Waiting for Device after interface swap

[duncangreene]

Describe the bug
After changing the interface to use for the device under test, future tests hang at "Waiting for Device", and error is thrown in logs.

To Reproduce
Steps to reproduce the behavior:

1. Have Testrun running perfectly okay with a given (USB Ethernet) network adapter for the device under test.
2. With no testing running, unplug the (USB Ethernet) network adapter, and plug in a different/spare one.
3. Testrun detects that the network adapter configured for the device under test is no longer available and the user is prompted to choose another network adapter.
4. Choose the new network adapter as the connection for the device under test.
5. Attempt to run a test.
6. Observe error as in above screenshot and testing hang at "Waiting for Device".

Expected behavior
Error should not be thrown, and testing should work as expected.

Workaround
Stop, restart and reconfigure Testrun to use the new network adapter.

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

• Ubuntu 24.4.01
• Testrun 2.0.1
• Additional hardware (network adapters): USB Ethernet adapter

[jhughesoti]

Can you verify the device was properly configured after it is connected? It maybe detected by the system but not configured properly for Testrun's usage.

[duncangreene]

Can you verify the device was properly configured after it is connected? It maybe detected by the system but not configured properly for Testrun's usage.

I can confirm the 'new' interface was configured in the Settings panel prior to running the test above.

Out of interest I just tried to replicate without configuring the 'new' interface in Settings. Testrun rightly won't allow you to start a test in this case.

[duncangreene]

This video shows the issue, swapping from an interface ending :40 to an interface ending :8f. You'll see the exception thrown at 03:02 in the video.

92696025-4842-4bee-b865-411986e239b2.1.mp4

As an aside, the appearance of the dialogue at 00:37 is strange, as those adapters were already configured as you can see at that point in the video, potentially rendering the dialogue a bit unnecessary?

[jhughesoti]

My question regarding configuration was about the OS level. While I did see you looking at a portion of the configuration in the OS, it was not the full configuration, i.e. dhcp options, etc. Could you do two things to confirm this issue with an adapter switch vs the adapter configuration itself?

1. Verify both interfaces are configured in an identical manner
2. Connect the errant interface before starting testrun and use it without switching.

If the issue persists without switching we know it is not the switching mechanism but the interface configuration and/or the adapter itself.

[duncangreene]

Both items shown in the video below, which is essentially the vice versa of the video above (swapping from the interface ending :8f to the interface ending :40).

cd102aa4-4359-4f3e-8766-1434e7b4a0f3.1.mp4

P.S. On a completely separate note you'll see in the above video (00:44 - 01:57) the browser caching issue explained in #986.

[KrystsinaT]

@jboddey The issue was tested in scope of ticket 380232279. Fixed.