Wifi does not connect to the router/phone hotspot with AOSP prebuilt image

Hi,
I am facing some issues with the Wifi on my Hikey960 board. I flashed the latest factory images from - https://snapshots.linaro.org/96boards/hikey960/linaro/aosp-master/573/ . The factory image file name that I have flashed is - hikey960-linaro-2018.07.18-factory-75fd8631.zip. In my setup, the Wifi scan result does not show my phone’s hotspot network (tried with few Redmi phones and an iPhone as well). Also I have seen that the Wifi does not connect to my 2.4GHz router with WPA2 security. I tried syncing and compiling the latest AOSP source for hikey960 but still facing the same issue with Wifi. Am I missing something obvious?

Thanks,

No, I’m going to check this on build 576.
In the same time, via console or ADB could you please try to initiate a scan:

iw wlan0 scan | grep SSID

If you correctly get results that could mean problem comes from upper-layer/Android.

Hi @Loic: Thanks for your reply.
The shell command you suggested is listing the networks!

However, the Wifi scan result is not showing it up in the UI.
Also during each Wifi scan animation in the Settings, the logcat prints -
07-23 10:22:33.124 2501 2670 I WifiService: startScan uid=1000
07-23 10:22:37.195 2501 2670 D WificondControl: Scan result ready event
07-23 10:22:37.203 2501 2578 D WificondScannerImpl: Filtering out 3 scan results.
07-23 10:22:37.218 2501 2670 I WifiService: getConfiguredNetworks uid=1000
07-23 10:22:37.222 2501 2670 I WifiService: getConfiguredNetworks uid=1000
07-23 10:22:37.225 2753 2753 D WifiSettings: onAccessPointChanged (singular) callback initiated
07-23 10:22:37.225 2753 2753 I chatty : uid=1000(system) com.android.settings identical 5 lines
07-23 10:22:37.225 2753 2753 D WifiSettings: onAccessPointChanged (singular) callback initiated
07-23 10:22:37.225 2753 2753 D WifiSettings: onAccessPointsChanged (WifiTracker) callback initiated
07-23 10:22:37.225 2501 2670 I WifiService: getWifiEnabledState uid=1000
07-23 10:22:37.527 2501 2670 I WifiService: getWifiEnabledState uid=1000
07-23 10:22:37.528 2501 2670 I WifiService: getConfiguredNetworks uid=1000
07-23 10:22:37.530 2501 2670 I WifiService: getPasspointConfigurations uid=1000

Does this mean Android is filtering out some SSID from the native scan results? Just a guess…
Any other inputs?

Thanks

you can use dumpsys wifi for more info about filtered SSID.
I feel it can be an issue with scan timestamp management in Android. If you’re able to rebuild could you try to remove filtering by age in wifi service, something like that (not tested):

--- a/service/java/com/android/server/wifi/scanner/WifiScanningServiceImpl.java
+++ b/service/java/com/android/server/wifi/scanner/WifiScanningServiceImpl.java
@@ -563,11 +563,7 @@ public class WifiScanningServiceImpl extends IWifiScanner.Stub {
                 // Using ScanResult.timestamp here to ensure that we use the same fields as
                 // WificondScannerImpl for filtering stale results.
                 long currentTimeInMillis = mClock.getElapsedSinceBootMillis();
-                return mCachedScanResults.stream()
-                        .filter(scanResult
-                                -> ((currentTimeInMillis - (scanResult.timestamp / 1000))
-                                        < CACHED_SCAN_RESULTS_MAX_AGE_IN_MILLIS))
-                        .toArray(ScanResult[]::new);
+                return mCachedScanResults.stream().toArray(ScanResult[]::new);
             }
         }

@Loic: No luck with the above change. Still I see the same logs and the missing networks in the UI scan list.
Did you get a chance to validate the same? Any other suggestions?

Thanks

I reproduce same issue on my side as well, My portable phone hotspot is not visible except if enabled it some time before booting the Hikey 960, do you confirm you observe the same. I think we should dig inside these filters to find which one is responsible.

I’m starting to wonder if I may have seen this as well, but for me it only seems to happen occasionally. I have a receiver running on my phone (pixel 2 xl) that activates the wifi hotspot when Bluetooth connects to the hikey (which is the brains behind my car radio). This happens about 20 seconds after powering the hikey on, which is <10 seconds before boot is completed.

I was thinking that it was related to the fact that I am running the hotspot on 5 GHz, since other networks remain visible. Nothing you do on the hikey short of a reboot makes it able to see the network.

@Loic: Yes, I am seeing my phone’s hotspot if I turn it ON before Hikey960 boots. It could be one of the filters then.

I put some prints in the WificonfScannerImpl.java and found that the issue is related to incorrect timestamps of the newly found networks -
07-26 10:16:05.581 2536 2984 D WificondControl: Scan result ready event
07-26 10:16:05.585 2536 2756 E WificondScannerImpl: network[0] result_timestamp_us=1046371352 ; Last scan start time_ms=230001
07-26 10:16:05.585 2536 2756 E WificondScannerImpl: network[1] result_timestamp_us=4083726088 ; Last scan start time_ms=230001
07-26 10:16:05.585 2536 2756 E WificondScannerImpl: network[2] result_timestamp_us=55398789 ; Last scan start time_ms=230001
07-26 10:16:05.585 2536 2756 E WificondScannerImpl: Skipping network[2] result_timestamp_us=55398789 ; Last scan start time_ms=230001
07-26 10:16:05.585 2536 2756 E WificondScannerImpl: network[3] result_timestamp_us=1312913366 ; Last scan start time_ms=230001
07-26 10:16:05.585 2536 2756 D WificondScannerImpl: Filtering out 1 scan results.

Probably there is a type conversion overflow somewhere?? Need to dig further to find out the root cause…

Thanks.

Thanks, this confirm time issue suspicion.

I bet Android uses the timestamp of the 802.11 frame (scan response/beacon) and compare it with its own timestamp, which is obviously wrong. I will dig a bit to confirm this and propose a patch.

Thank you @Loic. Will wait for your patch.

Though it’s a Android userspace issue, problem can be also fixed with a kernel patch in the wilink driver, I’ve proposed this one on LKML: https://patchwork.kernel.org/patch/10547433/. Feel free to try.