oreo-x86 WiFi broken?

[Robert Coldbird]

Before I go wondering about what's going on I wanted to know: Is this a known issue?
I just did an over-night build of oreo-x86 and didn't have the chance to debug this yet.

[Mauro Rossi]

Hi,

Il giorno venerdì 26 gennaio 2018 11:15:04 UTC+1, Robert Coldbird ha scritto:

Before I go wondering about what's going on I wanted to know: Is this a known issue?
I just did an over-night build of oreo-x86 and didn't have the chance to debug this yet.

Not affecting all devices, but the stock oreo-x86 build may be affected by a problem in entering in Settings,

have you already tried using the top bar and drop down the wifi configuration w/o entering Settings?

If the problem you're having is Settings crashing then you could try the last  two workaround patches in:

https://github.com/maurossi/packages_apps_Settings/commits/oreo-x86_810_hacks_v2 

Mauro

[Robert Coldbird]

Nothing's crashing, however it simply refuses to show me the local WiFi networks.

It enables, it disables, but with no WiFi networks showing up I have no means of actually connecting to them.

[Mauro Rossi]

There was no recent change in wifi related code in oreo-x86

Could you provide more information about your hw and dmesg, logcat traces?

Thanks

Mauro

[Robert Coldbird]

Hardware is a GPD Win, the system is running on a slightly-patched version of your 4.15-rc9 kernel from github as a lot of the system's hardware components throw a fit on older kernels.
The exact same kernel configuration works on the nougat-x86 branch, making me wonder just what might have changed here.

I've attached a dmesg and logcat text file.

[Robert Coldbird]

To me it looks like somehow the scan results get filtered out... but the only way this could happen is if the scan timestamps were somehow older than the scan start time...
But this shouldn't be possible.

[Mauro Rossi]

Hi,

If you're using kerne-4.14 or later, there is a permission patch [1] needed in system/connectivity/wificond

By cherrypicking that, wifi will work again.

Mauro

[1] https://android.googlesource.com/platform/system/connectivity/wificond/+/e823b5b106df057990cbc84255ae52919032221d

[Robert Coldbird]

Thank you. Worked great!

[Robert Coldbird]

Nevermind me... it's still broken, even with that commit...
Had the wrong build booted up.

Any other ideas?

[Mauro Rossi]

Hi,
wificond patch is necessary with kernel 4.14 and later

Check about driver problem e.g. [1]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=185661

Please, examine dmesg and logcat to find the root cause of the issue
and provide them both

M.

[Mauro Rossi]

What build was working?

I checked former dmesg and loading the .clm_blob should be optional,
but there was a correction 12 days ago in kernel 4.15 RC cycle,
could try rebasing to linux master branch?

M.

[Robert Coldbird]

I was out of it and booted one of my old nougat builds...

Either way, there are no WiFi issues in nougat running the same kernel, it's only oreo that refuses to show scan-results...

The odd thing though is that running a manual scan via terminal works fine.

[Robert Coldbird]

The wificond patch has been applied, and the driver configuration file exists.
Changes nothing though.

[Robert Coldbird]

I've attached the newest dmesg and logcat.
I've also attached a iw command output to show that the wireless adapter itself works fine.

To debug this further I crawled further up the layers all the way into WificondScannerImpl.java and found that the scan results get filtered out in the pollLatestScanData function because result.timestamp is 0 and thus always smaller than the start-time of the scan operation.
Simply disabling this check inside that function didn't yield any success either though, as it then threw a warning telling me that the network with the id -1 couldn't get dereferenced... (whatever that means).

Am Sonntag, 28. Januar 2018 11:01:36 UTC+1 schrieb Mauro Rossi:

[Mauro Rossi]

Maybe it is a regression in kernel-4.15rc9/rc8, test case would be to build with kernel-4.15rc7

or blob file required for legacy parts after latest commit

I also had issues with wifip2p and I have avoided them with [1],

but I don't know if that change may be related or protect against your issue

https://github.com/maurossi/packages_apps_Settings/commit/663f0f21cb8302023b32ec1c15d41b993eca016f

[Robert Coldbird]

I've spent most of today debugging this issue and finally found the culprit...

The real issue is that Wificond takes the lower-level APIs timestamp and compares them to its own scan-process start time to filter out what it considers old scan results.
The only problem here is that, depending on what your lower-level API / hardware looks like, this field can be set in a variety of ways, or not at all, as is the case with the GPD Win.
When this is the case, every AP found by the scan will be considered old, and thus filtered out, giving you a never ending WiFi scanning screen / progress bar.

I don't really understand why this timestamp check is there in the first place, because...

1. The system can only run one scan process at a time anyway, so a chance of overlapping (outdated) results is impossible anyway.
2. Once a new scan process is started, the system removes outdated scan data anyway, regardless of timestamps, as it treats all previously gathered scan results invalid from that point forward.
   

I've attached a patch that solves this problem in case someone else runs identical hardware, or if one of the maintainers wishes to merge it upstream.

[Lambdadroid]

result.timestamp = 0 sounds familiar for brcmfmac... I had a similar
problem caused by those timestamps with brcmfmac even on Nougat -
although not on Android x86, so there might have been a different
patch that avoided it.

Normally, this timestamp is provided by the kernel driver, but
brcmfmac always sets it to 0. They used to set it to a value based on
the system boot time, but later reverted that saying it's not supposed
to be any form of host timestamp.
See brmc80211: dont use jiffies for BSS TSF
(https://github.com/torvalds/linux/commit/8e6cffb3b42f03a47a56ede928b006f117628646)

This might not cause issues for most GNU/Linux distributions, but it
does cause issues for Android because, as you already noticed,
discards WiFi scan results entirely if this timestamp is before the
scan was started. What I did to fix it is basically revert the commit
above, but with a small change: The original patch caused problems
after 5 minutes because the jiffies would overflow and also didn't
work properly after the system went into suspend. I changed it to use
the monotonic boot time (so basically a counter starting from when the
system was originally started), which seems to work fine.

It might make more sense to fix the problem in the kernel (where it's
actually coming from), rather than in the WiFi scanner implementation.
Can you try to apply the following patch to the kernel and see if that
fixes the issue without the WificondScannerImpl patch?:

ANDROID: brcmfmac: Use monotonic boot time for BSS TSF (v2)
(https://github.com/me176c-dev/android_kernel_asus_me176c/commit/0bff9b2eb67f0430c1a8dbe4a19f3296b090578a)

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[Robert Coldbird]

Doing a test-build right now (will take a good 2-3 hours) and I'll report back on whether this fixes the issue or not.
If it does then we have 2 patches already that we could utilize to avoid the problem at the very least, although I think your solution to the problem is the more appropriate one, as it "fixes" the issue right at the source.

[Robert Coldbird]

Sorry for the late response, things got busy yesterday.
But yes, your patch also works.

So for anyone that encounters this issue, just apply the kernel patch from lambdadroid to work around the issue.
I'd also be very happy to see this get merged into android-x86's repositories to avoid these issues in the future.
Given that the kernel patch is very specific in what hardware it targets it shouldn't pose any negative side-effects on the project as a whole.

Am Montag, 29. Januar 2018 19:21:58 UTC+1 schrieb lambdadroid:

[youli...@gmail.com]

timestamp problem cause wifi auto connect problem.

brcmfmac and rtl8723bs wifi, can fix this problem on kernel, https://github.com/youling257/EmbER-Amlogic-Realtek-Drivers/commit/7435aff0c069608b89d6a0b52e7c7c8b835fe843  https://github.com/youling257/android-4.9/commit/6940b1f7c3d62fd43654bfc75ae34119bbb8e186

intel wifi ax200 also has this problem, fix it on userspace, patch frameworks/opt/net/wifi.

this patch for android x86 7 and cm14.

[Huy Minh Bui]

Seems interesting, what should I compile instead of the full iso so I can port it to other nougat ?

So far I can see wifi-service

Vào lúc 10:21:54 UTC+7 ngày Thứ Ba, 5 tháng 1, 2021, youli...@gmail.com đã viết:

[youli...@gmail.com]

export LC_ALL=C

export USE_NINJA=false

export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g"

. build/envsetup.sh >/dev/null && lunch cm_android_x86-userdebug >/dev/null && make -j8 org.cyanogenmod.platform-res

. build/envsetup.sh >/dev/null && lunch cm_android_x86-userdebug >/dev/null && make -j8 wifi-service

[Huy Minh Bui]

> . build/envsetup.sh >/dev/null && lunch cm_android_x86-userdebug >/dev/null && make -j8 org.cyanogenmod.platform-res

What about AOSP source ?

Vào lúc 17:33:56 UTC+7 ngày Thứ Ba, 5 tháng 1, 2021, youli...@gmail.com đã viết:

[Muhammad Ayaan]

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/c47094ec-8996-4915-9e8f-1441d053150an%40googlegroups.com.