Network issue after waking from sleep state - Githubissues

sebanc / brunch

Boot ChromeOS on x86_64 PC - Supports Intel CPU/GPU from 8th gen or AMD Ryzen

GNU General Public License v3.0

3.67k stars 390 forks source link

Network issue after waking from sleep state #953

Open wuchenkang opened 3 years ago

wuchenkang commented 3 years ago

Device: Surface Pro 2017 CPU: intel m3-7y30 Recovery Image: rammus 89 Brunch Framework: r88 stable 20210223 Problem: After waking my computer from sleep state, the internet connection does not work, even though it can be connected to the router. And the system shows the message "The wifi network you are using (XXX) may require you to visit its login page". Ping to urls shows "Temporary failure in name resolution". Ping to IP addresses only receive the first packet, following shows "ping : sendmsg: Operation not permitted"

Bantryred commented 3 years ago

I have the same problem, Surface Pro 4 i5 same recovery image and same brunch framework.

brey549 commented 3 years ago

Same issue, Surface Pro 3 i5. Rammus Version 89.0.4389.82 (Official Build) (64-bit) Brunch r88 20210131 Shutdown/restart seems the only fix.

wuchenkang commented 3 years ago

Wonder if this problem is solved after updating to brunch r89 20210403? @sebanc @Bantryred @brey549 Thank you!

martino012 commented 3 years ago

@wuchenkang I'm assuming that updating to brunch r89 20210403 fixed the problem for you? Did you do anything besides that? Because I'm experiencing the same problem that you had/have.

My device is a surface pro 3, with brunch r89 20210403 , chrome os 89 and rammus 89

wuchenkang commented 3 years ago

Updating to the most recent version of chrome os, still the same issue.

brey549 commented 3 years ago

I still have the issue on my Surface Pro 3. Update says I am current: 89.0.4389.116 (Official Build) (64-bit)

martino012 commented 3 years ago

Strangely enough I found kind of a solution; you should lock your device, instead of just pushing the power on/off button. You can set the power on/off switch to automatically lock your device. My surface pro 3 didn't lose connection after that.

midozalouk commented 3 years ago

Surface pro 6 Chrome OS 89 still with the same problem

ecaron commented 3 years ago

Is anyone on this thread savvy enough to see if the fix in https://github.com/linux-surface/kernel/pull/70 addresses this one? I'm still reading up on @sebanc's great build page, but it seems likely other people here know how to apply a different kernel faster than I can figure out. (Before that, I'm also going to spend one more loop reading #42 and https://github.com/linux-surface/kernel/issues/20 to make sure we're all hunting down the same bug.)

ecaron commented 3 years ago

On my Surface Pro 3, with Chrome OS 89, here's what I've tried (none of which have fixed it):

Kernel 5.4 & 5.10
Setting the l1_aspm to 0 (mentioned in #42)
The aspm-disable-L1-wifi-S3 script (also mentioned in #42)
Setting the suspend_s3 boot option
Setting mlan0 power_save to "off" with iw (with a one-liner at boot)
Setting the pcie_aspm=off kernel option

The problem shows up as the OS thinking its in Captive Portal mode. dmesg makes me think that we're able to scan for networks & send data, but since no data is received it thinks we're on a restricted network (we aren't)```

[ 3015.223166] arc_mlan0: port 1(vethmlan0) entered disabled state
[ 3015.226586] device vethmlan0 left promiscuous mode
[ 3015.226596] arc_mlan0: port 1(vethmlan0) entered disabled state
[ 3015.720730] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[ 3015.723072] arc_mlan0: port 1(vethmlan0) entered blocking state
[ 3015.723089] arc_mlan0: port 1(vethmlan0) entered disabled state
[ 3015.723199] device vethmlan0 entered promiscuous mode
[ 3015.723267] arc_mlan0: port 1(vethmlan0) entered blocking state
[ 3015.723270] arc_mlan0: port 1(vethmlan0) entered forwarding state
[ 3019.229463] mwifiex_pcie 0000:01:00.0: info: trying to associate to 'BaseHome' bssid f8:bc:0e:1f:7f:08
[ 3019.331343] mwifiex_pcie 0000:01:00.0: info: associated to bssid f8:bc:0e:1f:7f:08 successfully

My next step, for anyone following this journey, is building the newest branch of linux-surface & seeing if I can boot to it.

ecaron commented 3 years ago

Tried swapping out with both kernel's from this release - https://github.com/kitakar5525/chromeos-kernel-linux-surface/releases/tag/2020-10-19 - same issue. I could use another pair of eyes to figure out if https://github.com/kitakar5525/chromeos-kernel-linux-surface/issues/17 is related to this.

wuchenkang commented 3 years ago

I think this issue maybe somehow related to the chrome os itself. I have triggered this problem once on my pixelbook 2017, but not anymore since then. In contrast, my surface pro 5 suffers from this problem for 100% time.

brey549 commented 3 years ago

May not be sleep, I had to reboot my WiFi AP and it triggered the same response on my SP3 (captive portal mode). I tried connecting to my “Guest” WiFi and it didn’t help.

ecaron commented 3 years ago

@wuchenkang, I agree with your assessment. Status report on older versions:

brunch_r80_k4.19_stable_20200407 - too far back. Won't boot
brunch_r83_k4.19_stable_20200708 - wireless don't return on return from sleep (rather than acting as if in Captive Portal mode, it acts like wireless isn't turned on. interesting dmesg of "WLAN FW already running. Skip FW dnld")
Brunch r81 k4.19 stable 20200510 - works perfect! I'll be testing this as my daily driver for a while, but I think this narrows down the timing of when the breaking change happened.

ecaron commented 3 years ago

[edit - removed previous idea] Back to the drawing board. Next steps include testing the ideas on https://github.com/jakeday/linux-surface/issues/420 - I'd love to get back to r89.

ecaron commented 3 years ago

Running with r87-stable-20201227 and recovery image 87 works really great (e.g, auto rotation is perfect, wifi resumes from sleep). For the sake of science I'm going to see which r88 branch breaks, but for anyone needing a stable Brunch on Surface Pro 3, then use this release.

ecaron commented 3 years ago

Had a huge breakthrough on this. Running r89-stable with Recovery Image 90 fixes it. (As a reminder, R89 with recovery image 89 or 88 causes the aforementioned issue. R87 with image 87 works great.)

Can somebody else give the R89 + Recovery Image 90 combo a try to see if it works for them, too?

wuchenkang commented 3 years ago

Awesome! I will give it a try this weekend.

astravexton commented 3 years ago

Was having similar issues on a Surface 3 (not Pro), installed r89-stable and Recovery Image 90 and it seems to have fixed my issue with the network not working after sleep. Now I just need to get the mic to work and both cameras if possible

EDIT: It seems any Android app I install from the play store loses internet connection after goes to sleep for a long period of time, I can still browser the internet and ping stuff fine if not using Android apps from the store however

johnson5005 commented 3 years ago

Device: Google Pixelbook CPU: i5-7Y57 Recovery Image: Version 91.13904.0 (autoupdated) Brunch Framework: Brunch r91 20210613

Seeing the same network issue after waking from sleep. Also occurred on Version 87 recovery image for EVE prior to autoupdate to Version 91. As reported above, locking before sleeping appears to work around the issue. Installed following these instructions: https://github.com/olm3ca/Pixelbook-Campfire