microsoft
WifiInfo - wrong and missing data (link speeds)
Steps to reproduce
dumpsys wifi | grep mWifiInfo
✔️ Expected Behavior
mWifiInfo SSID: "My Network", BSSID: fc:34:97:3b:46:94, MAC:
(from a Google Pixel device)
❌ Actual Behavior
mWifiInfo SSID: "My Network", BSSID: fc:34:97:3b:46:94, MAC:
Other Software
No response
Have you specified the version of Windows Subsystem for Android under Milestone?
- [X] I have set this issue's milestone
This is a known issue that we'll look into for a future release. If there are any specific bugs associated with this that affect app compatibility, please let us know to help prioritize.
Hi Nick,
Thanks for your quick response.
The issue impacts our app - "Speed Test WiFi Analyzer" (com.analiti.fastest.android) - the #1 app in Amazon Appstore's Utilities/Speed Testing category. We use WiFi link speeds (also called phy speeds or phy rates) extensively in analyzing wifi networks' performance. Right now we get an invalid 500K link speed (without any bearing to reality, naturally) - and we only get it for the TxLinkSpeed.
Please let us know what we can do further to expedite a resolution to this issue.
On Wed, Oct 19, 2022 at 1:57 PM Nick Eubanks @.***> wrote:
This is a known issue that we'll look into for a future release. If there are any specific bugs associated with this that affect app compatibility, please let us know to help prioritize.
— Reply to this email directly, view it on GitHub https://github.com/microsoft/WSA/issues/57#issuecomment-1284379154, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3WF7BBABKF27V3LD6WTMITWEAZA7ANCNFSM6AAAAAARI43SXI . You are receiving this because you authored the thread.Message ID: @.***>
It seems that the Windows API WlanQueryInterface can fetch a WLAN_CONNECTION_ATTRIBUTES structure that contains WLAN_ASSOCIATION_ATTRIBUTES structure with the most important factors: dot11PhyType, ulRxRate and ulTxRate.
Hi, could you please let us know the subsystem version number you're running?
Also note that if you use WLAN_ASSOCIATION_ATTRIBUTES for RSSI - you'll get quality value translatable to only -50dBm or lower (even if actual RSSI value is higher than -50dBm) For correct RSSI use wlan_intf_opcode_rssi with WlanQueryInterface (and use WLAN_ASSOCIATION_ATTRIBUTES for phy speeds)
It's been 5 months and this bug still persists even in the latest insider build 25314.1010 re_prerelease. ETA for resolution? Do you need any help fixing this bug?
It's been 7 months and this bug still persists even in the latest release. ETA for resolution?
This isn't on the immediate roadmap. Since our networking stack is virtualized and not a native solution supporting network utilities is not a target area at the moment, even if we could replicate network details and topology perfectly, the performance analysis achieved by an Android application would only apply to Android apps and not necessarily the end user's physical device.
That's not say we don't want to support high fidelity in emulation here. It's just not a priority at the moment.
Understanding Microsoft priorities - it would be beneficial for developers to have an API bridge for Android apps to invoke Windows APIs. Or, as a poor man's alternative, have some way to execute Windows shell (e.g., cmd.exe) commands from within Android apps (similar to the Java Runtime or ProcessBuilder APIs).
In closing issue #290 Nick say "if something about the data presented results in an issue in your app, we'd like to know specifics so we can plan to address those". Please have a look at the first message on this issue #57. It's not about doing any manipulation on hardware - it's about showing information to the user, which is critical to our app. WSA already provides this information (as an existing feature or behavior of WSA) - but some of it is incorrect. We are not asking to implement new features, just asking to fix a bug in the WSA implementation that shows the incorrect data (most of the rest of the data is correct).
I'm not questioning the value of the app you're referencing, it seems like a very valuable tool for Android users. That said, WSA is running in a virtualized environment rather than on native wifi hardware, in many cases we're running a simulated wifi stack on top of ethernet or a mobile radio so any information retrieved from hardware is going to have some degree of inaccuracy. For the scenario you mentioned above, any results the app provides to the user are going to be inaccurate regardless of how well we emulate real hardware.
If you're using "Advanced Networking", note that this feature is experimental and not enabled by default in retail environments. We're continuing to evaluate features support in that mode.
Indeed - the information in question (mostly correct, part incorrect) is presented when WSA is using Advanced Networking. So the bug scope can be narrowed to that feature.
The conversation about virtualized vs (something else) is something most app users we know could not care less about. It's either they get the what they need from the app or not.
We can tell them "switch Advanced Networking ON in WSA" (like we suggest to them to configure other settings in the Android environment) - it's their choice, not ours. And if they choose to use our app, with WSA's Advanced Networking feature - they are currently presented with mostly correct but partly incorrect information - due to a bug in the Advanced Networking feature implementation.
On the one hand "the value of the app is not questioned" yet on the other hand the value of the WSA's own "Advanced Networking" feature is discounted.
We are not asking to develop a feature to support our app. We hope the bug in the WSA feature feature already developed and delivered to users (even if as experimental) - is fixed. This issue has nothing to do with virtualization - just using a wrong WIN API method to get a specific information piece (the call is already made by WSA Advanced Networking - it's just not the right one for the intended information).