bad websocket behavior on Windows

[touretzkyds]

The attached program HasBarrelTest.py (same as in issue #19) runs fine on Linux, but not on Windows, due to websocket issues.

On Linux, it runs without issue for as long as desired; I've gone out to 100,000 ms without errors. When I type control-\ to kill Python, the program stops and the robot immediately beeps, drops the smiley face, and shows the normal control panel. If I run the program again, it reconnects to the robot with no problem.

On Windows the story is very different. I can run the program for around 25,000 ms, but some time after that, I get the following:

   lost a status packet, counter: 1
   ws_status reconnecting
   ws_status reconnecting
   ws_status reconnecting
   ws_status reconnecting

This goes on forever; it never reconnects successfully. Moreover, if I type control-C to quit Python, I get Received signal SIGINT (2) and Python exits, but the robot never beeps and disconnects. It still shows the smiley face. If I press the power button then the smiley face goes away and I see the control panel. But if I run the program again, it has trouble reconnecting. I have to do something like disconnect the WiFi and then reconnect to the robot in order to be able to talk to it again.

I did these experiments on a Dell Pro 14 Plus Windows 11 laptop using the built-in WiFi. The Linux experiments were done using Ubuntu 24.04 with a USB WiFi dongle. Both machines were running Python 3.12.

Adding a print statement to WSStatusThread.run() shows that the reconnection attempts are failing with a TimeoutError.

HasBarrelTest.py

[jpearman]

We will try and find some hardware to reproduce this. I know Charlie runs windows and has not reported any issues, I just spun up a VM to test, not issues, ran for several minutes (moving the barrel around) before I killed it.

Welcome to the AIM Websocket Python Client. Running version 1.0.1.0 and connecting to 192.168.1.22
has_any_barrel() is now True  at   104
has_any_barrel() is now False at 44669
has_any_barrel() is now True  at 45584
has_any_barrel() is now False at 46639
has_any_barrel() is now True  at 47484
has_any_barrel() is now False at 144425
has_any_barrel() is now True  at 145206
has_any_barrel() is now False at 145926
has_any_barrel() is now True  at 146641
has_any_barrel() is now False at 275563
has_any_barrel() is now True  at 276431
has_any_barrel() is now False at 373216
has_any_barrel() is now True  at 373670

[Sansveni]

I tested the HasBarrelTest.py program on a Dell Pro Max 16 with built-in MT7925 WiFi 7 card on Windows 11. I was able to run it for 150 seconds without issues. I also ran it in Debian WSL without issues. I tried a CanaKit WiFi USB dongle (which has Ralink 5370 and is 802.11n) and it did not have issues.

From within the Python environment where you run HasBarrelTest.py, can you share the output of pip list from both your working Linux setup and your failing Windows setup?

[touretzkyds]

Here you go; see below. And here's another observation: I brought my Windows laptop into the office and tried connecting to the robot in station mode via the university's WiFi network. HasBarrelTest worked perfectly: no dropped packets, just like on Linux. But when I connected to the robot in access point mode the problem came back. So the problem is specific to Windows and access point mode.

package-list-linux.txt

package-list-windows.txt

[Sansveni]

Thanks for the lists. I've still not been able to reproduce this. Today I tested on another Windows 11 machine, using a couple of different WiFi USB dongles (the Canakit one and the RTL8811AU, which seems to be very similar to the RTL88x2bu that you mentioned in another thread). I have tested in both AP and station mode.

Any chance that you are accidentally connecting to the same AIM unit from multiple PCs at the same time? Just trying to think of possible causes.

From the lists, it looks like you are not running under a venv, and your Linux machine uses websocket-client 1.8.0, whereas your Windows machine uses websocket-client 1.9.0. I've tested both versions here without issues so this may or may not be relevant. I do notice a lot of differences in packages installed in Windows and Linux as well as the versions used, but since the bug you're seeing shows up in HasBarrelTest.py that you posted, which doesn't use those packages, they should be irrelevant.

If you could retest using a venv as shown here:
https://api.vex.com/aim/home/websocket/websocket_library_setup/setting_up.html
that would help rule out issues from the Python environment.

[touretzkyds]

I created an empty venv and installed just the websocket-client package and nothing else. See the attached listing. Connecting to the robot in access point mode using my laptop's internal WiFi produced the same failure behavior as before.

pip-list-windows-venv.txt

I thought maybe my laptop was cursed, so I ran the same experiment on an old Windows 10 workstation, same Python 3.12.3, same venv with just the websocket-client package, and a USB WiFi dongle. Everything worked perfectly. The connection stayed live for over 5 minutes with no packet loss.

So I went back to the laptop, plugged in the same USB WiFi dongle, and used that to connect to the robot. No packet loss for 5 minutes. Hmmm.... So I removed the dongle and connected to the robot using the internal WiFi. The failure showed up as expected. Back to the dongle... worked great. Back to internal WiFi... packet loss and could not reconnect.

So apparently the entire laptop isn't cursed, but the Intel WiFi adapter is cursed. Here are the specs I was able to pull from the device settings page:

Protocol: Wi-Fi 5 (802.11ac)
Security type: WPA2-Enterprise
Manufacturer: Intel Corporation
Description: Intel(R) Wi-Fi 7 BE201 320MHz
Driver version: 23.160.0.4

[touretzkyds]

The Intel WiFi adapter was indeed cursed. This page showed how to address the problem by disabling WiFi 7 mode, forcing it to revert to the more stable WiFi 6:
https://community.intel.com/t5/Wireless/Intel-BE201-Constant-wi-fi-disconnecting/td-p/1723257

It ran for just shy of 5 minutes (291 seconds) before dropping a packet, whereas before it only lasted 20-30 seconds. But the next run it only lasted 59 seconds. Once that packet loss happened, it was never able to reconnect.

I guess the solution is to just not use the Intel WiFi adapter with the robot. I'll stick with the dongle.

[jpearman]

Looks like perhaps an updated driver, 2 days old. Perhaps have windows check for a driver update.
https://www.intel.com/content/www/us/en/download/19351/intel-wireless-wi-fi-drivers-for-windows-10-and-windows-11.html

[touretzkyds]

Thanks, James. Windows Update didn't find the driver, but I downloaded it manually and the new driver may have solved the problem. I installed it, rebooted the machine, and ran my test for a full 8 minutes with no packet loss before I stopped testing.