search

google / testrun

A tool to automate verification of network-based device behavior
Apache License 2.0
28 stars 9 forks source link

Testing hangs at Waiting for Device after interface swap #978

Open duncangreene opened 5 days ago

duncangreene commented 5 days ago

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.

Image

Image

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):

jhughesbiot commented 5 days ago

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 commented 4 days ago

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.

Image

duncangreene commented 4 days ago

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.

https://github.com/user-attachments/assets/bf151524-aa3c-4b04-aadb-aee75e4c165d

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?

jhughesbiot commented 4 days ago

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 commented 4 days ago

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).

https://github.com/user-attachments/assets/e4dc95b0-8694-4154-b59c-610fba9b80a0

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.