Launcher enumerating non-existent ports on Windows client

[zfi]

The latest version of the Launcher (0.11.0) is enumerating phantom ports when polled by the Solo browser client. This appears to happen only on the Windows platform. I observed this on @AndyLindsay Windows Surface last night while testing Solo updates.

I am not sure what the enumeration process is looking at but it's possible it is picking up ports from multiple FTDI driver installations or perhaps something in the Windows registry.

[PropGit]

@zfi - Strange, I haven't seen that happening on my system. Will likely have to check out @AndyLindsay system for some debugging. It's certainly possible to request from the system a list of all ports ever in existance, but we should be (and have been as far as I know) requesting only active ports.

[zfi]

I'll test this on my Surface, but I am fairly certain that I have only a single driver installed. What qualifies as an "active" port for the enumeration? Perhaps I can force a few things on the Surface to reproduce the error.

[AndyLindsay]

The trick is to let auto enumeration happen by connecting more than one Propeller in sequence. The one that was connected previously will persist in the com port list, even after it has been disconnected.

…

On Thu, Dec 26, 2019, 9:07 AM Jim Ewald ***@***.***> wrote: I'll test this on my Surface, but I am fairly certain that I have only a single driver installed. What qualifies as an "active" port for the enumeration? Perhaps I can force a few things on the Surface to reproduce the error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=ACYKA52GFVELWQWVVLAS6CDQ2TQDTA5CNFSM4J67SSH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHV2V5I#issuecomment-569092853>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYKA57L5RPXTITDDZFBQMLQ2TQDTANCNFSM4J67SSHQ> .

[zfi]

This is why I would like to understand is the Launcher "sees" active ports as whatever Windows reports or if it's doing anything to validate the veracity of the list Windows reports.

And I only have one device with me, so testing will happen next Monday.

[PropGit]

By "active" I mean, currently connected to the system, rather than disconnected but still in the OS's history of ports (which it will happily report if asked).

@AndyLindsay - I'll try testing this. Have you noticed if the port disappears after some time? The way it's working, the browser asks for a port list from the launcher periodically; it doesn't get a push-message from the launcher when there are system changes. This means that a disconnected port will remain in the list until the next port-list request from the browser (which may be 5 seconds or so from now).

In the same sense, when a board is connected, it may be a few seconds before it actually shows up in the port list.

For WiFi Modules, the Launcher keeps them in the list until the last three detection attempts were negative; this is a hacky-workaround for cases where the WiFi Modules don't respond to every single detection packet on the network. The real problem there may be congested network or inadequate detection protocol.

[PropGit]

I just tested. I can't get a port to "stick" on-screen in the dropdown list. I even selected it and after disconnecting from the computer, upon the next port-list request, the port (and my selection) disappeared. I that's not what is happening on your system, then there definitely is some difference we need to investigate further.

[zfi]

FWIW, I know that, on @AndyLindsay Surface, there were three ports enumerated over the 10 minutes that we were testing the compiler service. The names of the ports did not change over that 10 minutes.

[AndyLindsay]

The ports are remembered for more than a day. When Jim and I tested it on Monday afternoon, it seemed to remember three ports: 13, 17, and 18. Now, on Thursday midday, the ports dropdown shows 17 and 18. In the capture below, no Propeller modules were connected. I just tried rebooting, and the com ports reappeared as soon as I created a new project in Solo. [image: image.png]

…

On Thu, Dec 26, 2019 at 11:46 AM Parallax Git Administrator < ***@***.***> wrote: By "active" I mean, currently connected to the system, rather than disconnected but still in the OS's history of ports (which it will happily report if asked). @AndyLindsay <https://github.com/AndyLindsay> - I'll try testing this. Have you noticed if the port disappears after some time? The way it's working, the browser asks for a port list from the launcher periodically; it doesn't get a push-message from the launcher when there are system changes. This means that a disconnected port will remain in the list until the next port-list request from the browser (which may be 5 seconds or so from now). For WiFi Modules, the Launcher keeps them in the list until the last three detection attempts were negative; this is a hacky-workaround for cases where the WiFi Modules don't respond to every single detection packet on the network. The real problem there may be congested network or inadequate detection protocol. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=ACYKA52GWATKJ674EVPBWD3Q2UC2HA5CNFSM4J67SSH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWB7EI#issuecomment-569122705>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYKA55HMLRIYXQA26MAFLDQ2UC2HANCNFSM4J67SSHQ> .

[PropGit]

Thanks for the confirmations. Since I can't duplicate, on a hunch, I'd like you to run a test on your surface.

0. Extract the attached file into an empty folder of your choice - BPL_V0.11.1.zip
1. Close the BP Launcher v0.11.0
2. Check what version of Chrome you have on your system (and report here). Suggest v78 or v79
3. In your Chrome browser, navigate to chrome://extensions
4. Ensure Developer Mode is enabled (upper-right switch)
5. Click the Load Unpacked button
6. Navigate the file browser to select the folder where you've unzipped the attached package
7. Click the Select Folder button
8. Navigate the Chrome browser to chrome://apps
9. Click the BlocklyProp Launcher app
10. Ensure it is v0.11.1 (a new version for this experiment; only changed by version number)
11. Experiment with it to see if the same port behavior occurs with BlocklyProp Launcher v0.11.1 as it does with v0.11.0.

What's my hunch? There may have been a Windows API update that causes this new behavior and the latest Chrome browser may adjust for it; however, our new BP Launcher v0.11.0 uses a specific, older version, of the Chrome engine (independent of any Chrome browser installed on the system). Knowing whether or not this is the case helps me chase the right goose.

[AndyLindsay]

2. Chrome Version 79.0.3945.88 (Official Build) (64-bit)
3. v0.11.1 (check!)
4. The COM17 and COM18 are still there, but when I use a different board, the com port appears and disappears from the list as I plug/unplug it. I will post updates as I continue to work with it.

[PropGit]

Found the problem when checking Andy's system: These are Bluetooth ports showing up.

The Launcher is supposed to eliminate those from the list but unfortunately I didn't make it a case-insensitive pattern match. Will fix.

[PropGit]

Despite the title, this could actually occur on Macs (and Chromebooks) as well, provided certain Bluetooth hardware existed.