Fixed
Status Update
No update yet.
Comments
kh...@google.com
Thank you for opening this issue. It seems to me that a change (maybe an update) happened and you are no longer part of the “Google-sudoers” group, and as explained in this document about the guest environment [1]. As such, and in order to investigate this issue, please provide further information (output) about the OS distribution you are using and the guest environment [3][4]:
$uname -a
$systemctl list-unit-files \
| grep google | grep enabled
$yum list installed | grep google-compute
In case another community member is facing the same issue with a different distribution, please check these document links [3] [4] for alternatives to the last two commands.
Meanwhile, and as a workaround, you may try the following:
1.Use a different username:
- if in the browser click on the setting icon (top right), and click change Linux name in the drop down. [5]
- Using the SDK
$ gcloud compute ssh newusername@instance
2. Enable OS Login on the instance (set "enable-oslogin=True" in metadata) and per this document [6]
I will be awaiting for your reply.
[1]https://github.com/GoogleCloudPlatform/compute-image-packages#accounts
[2]https://cloud.google.com/compute/docs/images#os-details
[3]https://cloud.google.com/compute/docs/instances/linux-guest-environment#wgei_services
[4]https://cloud.google.com/compute/docs/instances/linux-guest-environment#wgei_packages
[5]https://cloud.google.com/compute/docs/ssh-in-browser#login_username
[6]https://cloud.google.com/compute/docs/instances/managing-instance-access
$uname -a
$systemctl list-unit-files \
| grep google | grep enabled
$yum list installed | grep google-compute
In case another community member is facing the same issue with a different distribution, please check these document links [3] [4] for alternatives to the last two commands.
Meanwhile, and as a workaround, you may try the following:
1.Use a different username:
- if in the browser click on the setting icon (top right), and click change Linux name in the drop down. [5]
- Using the SDK
$ gcloud compute ssh newusername@instance
2. Enable OS Login on the instance (set "enable-oslogin=True" in metadata) and per this document [6]
I will be awaiting for your reply.
[1]
[2]
[3]
[4]
[5]
[6]
be...@chromium.org
fyi,
$ uname -a*Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul
16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux*
$ systemctl list-unit-files \
> | grep google | grep enabled*google-accounts-daemon.service enabled
google-clock-skew-daemon.service enabled
google-instance-setup.service enabled
google-network-daemon.service enabled *
$ yum list installed | grep
google-compute*google-compute-engine.noarch 2.8.6-1.el7
@google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch*
On Tue, Oct 16, 2018 at 6:21 AM <buganizer-system@google.com> wrote:
$ uname -a*Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul
16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux*
$ systemctl list-unit-files \
> | grep google | grep enabled*google-accounts-daemon.service enabled
google-clock-skew-daemon.service enabled
google-instance-setup.service enabled
google-network-daemon.service enabled *
$ yum list installed | grep
google-compute*google-compute-engine.noarch 2.8.6-1.el7
@google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch*
On Tue, Oct 16, 2018 at 6:21 AM <buganizer-system@google.com> wrote:
an...@gmail.com
fyi,
$ uname -a
Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ systemctl list-unit-files \
> | grep google | grep enabled
google-accounts-daemon.service enabled
google-clock-skew-daemon.service enabled
google-instance-setup.service enabled
google-network-daemon.service enabled
$ yum list installed | grep google-compute
google-compute-engine.noarch 2.8.6-1.el7 @google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch
$ uname -a
Linux instance-1 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ systemctl list-unit-files \
> | grep google | grep enabled
google-accounts-daemon.service enabled
google-clock-skew-daemon.service enabled
google-instance-setup.service enabled
google-network-daemon.service enabled
$ yum list installed | grep google-compute
google-compute-engine.noarch 2.8.6-1.el7 @google-cloud-compute
google-compute-engine-oslogin.x86_64
python-google-compute-engine.noarch
ki...@google.com
Hi,
I have tried the work aground you have mentioned
1. (OS Login),it not working. I cannot find any of my files , no permission
to change folder also
Last login: Tue Oct 16 11:07:34 2018 from 74.125.41.167
/usr/bin/id: cannot find name for group ID 578680806
[platformcloudtest_gmail_com@instance-1 ~]$ ls
[platformcloudtest_gmail_com@instance-1 ~]$
2.I have Changed username also
I don't have permission to acesss other folders
On Tue, Oct 16, 2018 at 10:38 AM Aneesh MP <platformcloudtest@gmail.com>
wrote:
I have tried the work aground you have mentioned
1. (OS Login),it not working. I cannot find any of my files , no permission
to change folder also
Last login: Tue Oct 16 11:07:34 2018 from 74.125.41.167
/usr/bin/id: cannot find name for group ID 578680806
[platformcloudtest_gmail_com@instance-1 ~]$ ls
[platformcloudtest_gmail_com@instance-1 ~]$
2.I have Changed username also
I don't have permission to acesss other folders
On Tue, Oct 16, 2018 at 10:38 AM Aneesh MP <platformcloudtest@gmail.com>
wrote:
an...@gmail.com
Same thing happened to my machines:
uname -a output: 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
as a workaround I followed this documenthttps://cloud.google.com/compute/docs/instances/managing-instance-access#enable_oslogin and enabled oslogin with metadata on VM. When I logged in next time it created new user account which is part of Google-sudoers. From this account sudo works fine.
Account that is no longer part of sudoers generates those logs:
Oct 12 00:40:38 m2-us-central1-c google-accounts: INFO Removing user arek.
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: Removing user arek from group google-sudoers
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: gpasswd: user 'arek' is not a member of 'google-sudoers'
Oct 12 00:40:38 m2-us-central1-c google-accounts: WARNING Could not update user arek. Command '['gpasswd', '-d', 'arek', 'google-sudoers']' returned non-zero exit status 3.
Hope that helps.
Arek
uname -a output: 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
as a workaround I followed this document
Account that is no longer part of sudoers generates those logs:
Oct 12 00:40:38 m2-us-central1-c google-accounts: INFO Removing user arek.
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: Removing user arek from group google-sudoers
Oct 12 00:40:38 m2-us-central1-c google_accounts_daemon: gpasswd: user 'arek' is not a member of 'google-sudoers'
Oct 12 00:40:38 m2-us-central1-c google-accounts: WARNING Could not update user arek. Command '['gpasswd', '-d', 'arek', 'google-sudoers']' returned non-zero exit status 3.
Hope that helps.
Arek
an...@gmail.com
As you have mentioned ,the workaround worked for me also ,Also tried
without the OS login just added new user IAM & admin with Role Compute
Admin , Owner Once logged in just changed the the username from
the Terminal Options->Change Linux Username and eneterd the command sudo -i
after this i could run sudo commands with no issues.
Regards
On Tue, Oct 16, 2018 at 6:27 PM <buganizer-system@google.com> wrote:
without the OS login just added new user IAM & admin with Role Compute
Admin , Owner Once logged in just changed the the username from
the Terminal Options->Change Linux Username and eneterd the command sudo -i
after this i could run sudo commands with no issues.
Regards
On Tue, Oct 16, 2018 at 6:27 PM <buganizer-system@google.com> wrote:
ki...@google.com
Thank you everyone.
Investigating the issue, it seems only instances created with images “centos-7-v20181009“ between October 9th and 11th are affected. (equivalent releases for other distributions may also be affected). This was already mitigated with the new images from October 11th “centos-7-v20181011”.
Thus, in your case, it is recommended to recreate the instance with the new image for a permanent resolution unless if the workarounds above are sufficient for your use-cases.
As this issue has been already fixed (with new image releases), I am closing it now. Thank you again for reporting it.
Investigating the issue, it seems only instances created with images “centos-7-v20181009“ between October 9th and 11th are affected. (equivalent releases for other distributions may also be affected). This was already mitigated with the new images from October 11th “centos-7-v20181011”.
Thus, in your case, it is recommended to recreate the instance with the new image for a permanent resolution unless if the workarounds above are sufficient for your use-cases.
As this issue has been already fixed (with new image releases), I am closing it now. Thank you again for reporting it.
ki...@google.com
Hi,
I don't think it's related to instances created with those images. My VMs were created Feb 18, 2017, 10:53:07 AM.
I lost sudo access on my VMs on October 11th right after this outage:https://status.cloud.google.com/incident/cloud-networking/18016
Same day before outage everything was OK.
Arek
I don't think it's related to instances created with those images. My VMs were created Feb 18, 2017, 10:53:07 AM.
I lost sudo access on my VMs on October 11th right after this outage:
Same day before outage everything was OK.
Arek
an...@gmail.com
Hello,
My case is similar to Arek . Creation time of Instance is Feb 9, 2018,
9:49:13 PM.I lost sudo access on my VMs on October 15th 2018 . Everything
was ok before this.
Sanil
On Wed, Oct 17, 2018 at 5:35 PM <buganizer-system@google.com> wrote:
My case is similar to Arek . Creation time of Instance is Feb 9, 2018,
9:49:13 PM.I lost sudo access on my VMs on October 15th 2018 . Everything
was ok before this.
Sanil
On Wed, Oct 17, 2018 at 5:35 PM <buganizer-system@google.com> wrote:
an...@gmail.com
Thank you Arek and Sanil for the clarification.
Investigating further, and as for the network incident reported in
Explaining further about the google-sudoer issue, a minor release of the guest environment package was pushed (to the repository) on October 9th. Thus, new images included the update. But also and since the packages were updated in the repository, few instances that perform updates (e.g yum update) or automatic updates (e.g yum-cron) got affected.
On October 11th, the packages were fixed, and new images that include the packages fix (v20181011) were released, while the images from October 9th were deprecated.
However, the package fix did not resolve the issue with existing affected instances, but rather for new images, and those existing images that did not perform any update within the time frame. Thus, for all affected instances the workarounds above.
As such, and for a permanent resolution for affected instances, I forwarded this issue to the Compute Engine team who are already aware of the issue. They mentioned that they are working on a permanent fix for the next release. At the moment we cannot provide an ETA. But you can track this thread for any updates, or post additional comments.
I hope this clarifies the confusion, and thank you again for the clarification.
Investigating further, and as for the network incident reported in
Explaining further about the google-sudoer issue, a minor release of the guest environment package was pushed (to the repository) on October 9th. Thus, new images included the update. But also and since the packages were updated in the repository, few instances that perform updates (e.g yum update) or automatic updates (e.g yum-cron) got affected.
On October 11th, the packages were fixed, and new images that include the packages fix (v20181011) were released, while the images from October 9th were deprecated.
However, the package fix did not resolve the issue with existing affected instances, but rather for new images, and those existing images that did not perform any update within the time frame. Thus, for all affected instances the workarounds above.
As such, and for a permanent resolution for affected instances, I forwarded this issue to the Compute Engine team who are already aware of the issue. They mentioned that they are working on a permanent fix for the next release. At the moment we cannot provide an ETA. But you can track this thread for any updates, or post additional comments.
I hope this clarifies the confusion, and thank you again for the clarification.
an...@gmail.com
Thank you for your patience.
Our Compute Engine team has resolved the issue internally. Any effected users can fix the issue by updating to the latest version of the guest environment (running a standard update and upgrade).
sudo apt update
sudo apt upgrade google-compute-engine
Affected users can disable OS Login at any time. That said, we do consider OS Login the preferred way to manage access to instances since it provides manages access with IAM (during time of log in), allows for easy deprovisioning of users, and creates a consistent identity (same username, uid, etc) across your organization.
Our Compute Engine team has resolved the issue internally. Any effected users can fix the issue by updating to the latest version of the guest environment (running a standard update and upgrade).
sudo apt update
sudo apt upgrade google-compute-engine
Affected users can disable OS Login at any time. That said, we do consider OS Login the preferred way to manage access to instances since it provides manages access with IAM (during time of log in), allows for easy deprovisioning of users, and creates a consistent identity (same username, uid, etc) across your organization.
an...@gmail.com
Can you give detailed steps to fix this ?
gm...@gmail.com
Because
gm...@gmail.com
delete
ri...@gmail.com
delete
br...@google.com
These all seem to be from the reporter in #14/#15, on lars:
https://listnr.corp.google.com/product/208/report/86121906708
https://listnr.corp.google.com/product/208/report/86120704167
https://listnr.corp.google.com/product/208/report/86112149166
https://listnr.corp.google.com/product/208/report/86084688296
Checking the last report, I see the "beacon heard ..." log that was noted already:
[18049.316936] wlan0: authenticate with 00:23:69:00:00:01
[18049.326103] wlan0: send auth to 00:23:69:00:00:01 (try 1/3)
[18049.330456] wlan0: authenticated
[18049.331594] iwlwifi 0000:01:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[18049.331645] iwlwifi 0000:01:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[18049.333600] wlan0: associate with 00:23:69:00:00:01 (try 1/3)
[18049.336295] wlan0: RX AssocResp from 00:23:69:00:00:01 (capab=0x411 status=0 aid=1)
[18049.344552] wlan0: associated
[18049.939252] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
I can't find any feedback logs for the OPs from
Marking 73 as the likely regression point.
So far, all reports are on 2.4GHz, but on various channels (so far, channels 8 and 11).
Checking the last report, I see the "beacon heard ..." log that was noted already:
[18049.316936] wlan0: authenticate with 00:23:69:00:00:01
[18049.326103] wlan0: send auth to 00:23:69:00:00:01 (try 1/3)
[18049.330456] wlan0: authenticated
[18049.331594] iwlwifi 0000:01:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[18049.331645] iwlwifi 0000:01:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[18049.333600] wlan0: associate with 00:23:69:00:00:01 (try 1/3)
[18049.336295] wlan0: RX AssocResp from 00:23:69:00:00:01 (capab=0x411 status=0 aid=1)
[18049.344552] wlan0: associated
[18049.939252] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
I can't find any feedback logs for the OPs from
Marking 73 as the likely regression point.
So far, all reports are on 2.4GHz, but on various channels (so far, channels 8 and 11).
gm...@gmail.com
Thanks for the update in
br...@google.com
Browsing "Connectivity > WiFi" issues on Listnr sounds like there are a lot of similar reports, though it's hard to confirm if they're exactly the same. Here's one example that looks awfully similar:
https://listnr.corp.google.com/product/208/report/86117129420
Running R73 stable on snappy, they have a series of consecutive disconnections, and several (not all shown here) "No beacon heard" messages:
[147674.903121] wlan0: authenticate with 00:26:75:00:00:0a
[147674.906314] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147674.910414] wlan0: authenticated
[147674.914802] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147674.923850] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147674.933444] wlan0: associated
[147675.519462] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
[147675.519509] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147675.594303] audit: type=1400 audit(1555045608.942:660): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147735.923864] wlan0: authenticate with 00:26:75:00:00:0a
[147735.927318] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147735.932227] wlan0: authenticated
[147735.933858] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147735.938052] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147735.943219] wlan0: associated
[147770.144603] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147770.220558] audit: type=1400 audit(1555045703.719:661): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147796.937636] wlan0: authenticate with 00:26:75:00:00:0a
[147796.941395] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147796.945118] wlan0: authenticated
[147796.948509] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147796.952195] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147796.961416] wlan0: associated
[147830.975066] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147831.049194] audit: type=1400 audit(1555045764.644:662): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147860.157994] wlan0: authenticate with 00:26:75:00:00:0a
[147860.162531] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147860.166033] wlan0: authenticated
[147860.167013] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147860.170690] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147860.173544] wlan0: associated
[147915.728645] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147915.822059] audit: type=1400 audit(1555045849.552:663): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147981.974575] wlan0: authenticate with 00:26:75:00:00:0a
[147981.978089] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147981.981617] wlan0: authenticated
[147981.982177] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147981.985854] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147981.987997] wlan0: associated
[148031.052423] wlan0: Connection to AP 00:26:75:00:00:0a lost
[148031.135167] audit: type=1400 audit(1555045965.049:664): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[148042.904867] wlan0: authenticate with 00:26:75:00:00:0a
[148042.913068] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[148042.916541] wlan0: authenticated
[148042.917284] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[148042.920950] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[148042.922897] wlan0: associated
[148082.172090] wlan0: Connection to AP 00:26:75:00:00:0a lost
[148082.241276] audit: type=1400 audit(1555046016.236:665): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
Sample from net.log:
2019-04-12T13:14:44.090933+08:00 INFO shill[1467]: [INFO:wifi.cc(873)] WiFi wlan0 supplicant updated DisconnectReason to -4
They're also on 2.4GHz
signal: -69 [-69, -74] dBm
signal avg: -69 [-69, -78] dBm
beacon signal avg: -73 dBm
tx bitrate: 86.7 MBit/s MCS 12 short GI
rx bitrate: 26.0 MBit/s MCS 3
...
freq: 2447
Running R73 stable on snappy, they have a series of consecutive disconnections, and several (not all shown here) "No beacon heard" messages:
[147674.903121] wlan0: authenticate with 00:26:75:00:00:0a
[147674.906314] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147674.910414] wlan0: authenticated
[147674.914802] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147674.923850] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147674.933444] wlan0: associated
[147675.519462] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
[147675.519509] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147675.594303] audit: type=1400 audit(1555045608.942:660): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147735.923864] wlan0: authenticate with 00:26:75:00:00:0a
[147735.927318] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147735.932227] wlan0: authenticated
[147735.933858] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147735.938052] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147735.943219] wlan0: associated
[147770.144603] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147770.220558] audit: type=1400 audit(1555045703.719:661): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147796.937636] wlan0: authenticate with 00:26:75:00:00:0a
[147796.941395] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147796.945118] wlan0: authenticated
[147796.948509] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147796.952195] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147796.961416] wlan0: associated
[147830.975066] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147831.049194] audit: type=1400 audit(1555045764.644:662): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147860.157994] wlan0: authenticate with 00:26:75:00:00:0a
[147860.162531] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147860.166033] wlan0: authenticated
[147860.167013] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147860.170690] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147860.173544] wlan0: associated
[147915.728645] wlan0: Connection to AP 00:26:75:00:00:0a lost
[147915.822059] audit: type=1400 audit(1555045849.552:663): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[147981.974575] wlan0: authenticate with 00:26:75:00:00:0a
[147981.978089] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[147981.981617] wlan0: authenticated
[147981.982177] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[147981.985854] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[147981.987997] wlan0: associated
[148031.052423] wlan0: Connection to AP 00:26:75:00:00:0a lost
[148031.135167] audit: type=1400 audit(1555045965.049:664): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
[148042.904867] wlan0: authenticate with 00:26:75:00:00:0a
[148042.913068] wlan0: send auth to 00:26:75:00:00:0a (try 1/3)
[148042.916541] wlan0: authenticated
[148042.917284] wlan0: associate with 00:26:75:00:00:0a (try 1/3)
[148042.920950] wlan0: RX AssocResp from 00:26:75:00:00:0a (capab=0x411 status=0 aid=6)
[148042.922897] wlan0: associated
[148082.172090] wlan0: Connection to AP 00:26:75:00:00:0a lost
[148082.241276] audit: type=1400 audit(1555046016.236:665): avc: denied { sigchld } for pid=1467 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
Sample from net.log:
2019-04-12T13:14:44.090933+08:00 INFO shill[1467]: [INFO:wifi.cc(873)] WiFi wlan0 supplicant updated DisconnectReason to -4
They're also on 2.4GHz
signal: -69 [-69, -74] dBm
signal avg: -69 [-69, -78] dBm
beacon signal avg: -73 dBm
tx bitrate: 86.7 MBit/s MCS 12 short GI
rx bitrate: 26.0 MBit/s MCS 3
...
freq: 2447
ki...@google.com
Reply #19, yes this is a known issue but Intel isn't going to debug that unless you have a firmware dump, otherwise they have no way to tell why the firmware isn't says "no beacon heard" - is it off in the weeds due to a state-machine issue? is it environment/platform noise?
I filed a bug with one instance on Nocturne where I did have the devcoredump:
https://b.corp.google.com/issues/130034903
I am yet to hear back.
I filed a bug with one instance on Nocturne where I did have the devcoredump:
I am yet to hear back.
ki...@google.com
Echo-ing #17: "I can't find any feedback logs for the OPs from
Reply #14 and #15: Please do not conflate other issues that don't have any logs whatsoever with this bug. A large chunk of wifi issues are described as "wifi disconnects/drop offs/is flaky" i.e. a single symptom, but that doesn't imply the issues are related.
Reply #16: Ditto as above. Please file feedback via alt-shift-i or file a separate bug and supply logs there.
anywhim@:
1. You are on channel 8 (not 1/6/11 - the "advisable" ones for minimizing interference), 2.4 GHz is known for interference from bluetooth and microwave, and your logs show disconnect with reason code 4 which correlates with noise.
Not sure how you got the SNR numbers because the Intel wifi chip you have doesn't report it and SNR from the AP or a third-party device isn't useful here.
Ideally, we need a firmware dump from your device and we'll work on adding a mechanism (tracked in internal buganizer) for you to do it yourself and attach here.
Reply #14 and #15: Please do not conflate other issues that don't have any logs whatsoever with this bug. A large chunk of wifi issues are described as "wifi disconnects/drop offs/is flaky" i.e. a single symptom, but that doesn't imply the issues are related.
Reply #16: Ditto as above. Please file feedback via alt-shift-i or file a separate bug and supply logs there.
anywhim@:
1. You are on channel 8 (not 1/6/11 - the "advisable" ones for minimizing interference), 2.4 GHz is known for interference from bluetooth and microwave, and your logs show disconnect with reason code 4 which correlates with noise.
Not sure how you got the SNR numbers because the Intel wifi chip you have doesn't report it and SNR from the AP or a third-party device isn't useful here.
Ideally, we need a firmware dump from your device and we'll work on adding a mechanism (tracked in internal buganizer) for you to do it yourself and attach here.
ki...@google.com
Reply #17: I am not certain this is a regression:
https://crosland.corp.google.com/log/11316.0.0..11647.0.0
There are no wifi driver updates. There is a wifi firmware update which was also applied to R72. Do you see anything jump out there?
There are no wifi driver updates. There is a wifi firmware update which was also applied to R72. Do you see anything jump out there?
ki...@google.com
anywhim@: Looking at your comment while filing this bug:
"Did this work before? Yes I'm not sure, but I believe it's 72"
Does this mean it worked for you in R72?
Are you by any chance running your Pixelbook in developer mode?
If so, and if you are comfortable running shell commands, you can collect a firmware dump which would make it easier for us to push on Intel to debug:
$ cd /sys
$ find . -name "fw_dbg_collect"
# Check that the path looks something like
./kernel/debug/iwlwifi/<$pci_id>/iwlmvm/fw_dbg_collect
$ echo 1 > `find . -name "fw_dbg_collect"`
# this will dump something in /var/log/last_iwlwifi_{dump, dumptime}
$ generate_logs # this picks up /var/log/last_iwlwifi_{dump, dumptime}
This should say something like
localhost /var/log # generate_logs
[0415/194128.789154:INFO:generate_logs.cc(98)] Gathering logs, please wait
[0415/194215.948747:INFO:generate_logs.cc(103)] Logs saved to /tmp/debug-logs_20190415-194128.tgz
Move the tarball to /home/user/$USER_ID/Downloads
$ mv /tmp/debug-logs* /home/user/<tab-complete>/Downloads/
Attach the tarballs here.
Note that this isn't ordinarily required - the process of dumping firmware debug info and collecting it is automated.
Also, I take the comment in #22 back - the diff from 11647.0.0 to 11647.91.0
includes the Core40 driver update.
I am bisecting through it now, if I can find a repro case.
"Did this work before? Yes I'm not sure, but I believe it's 72"
Does this mean it worked for you in R72?
Are you by any chance running your Pixelbook in developer mode?
If so, and if you are comfortable running shell commands, you can collect a firmware dump which would make it easier for us to push on Intel to debug:
$ cd /sys
$ find . -name "fw_dbg_collect"
# Check that the path looks something like
./kernel/debug/iwlwifi/<$pci_id>/iwlmvm/fw_dbg_collect
$ echo 1 > `find . -name "fw_dbg_collect"`
# this will dump something in /var/log/last_iwlwifi_{dump, dumptime}
$ generate_logs # this picks up /var/log/last_iwlwifi_{dump, dumptime}
This should say something like
localhost /var/log # generate_logs
[0415/194128.789154:INFO:generate_logs.cc(98)] Gathering logs, please wait
[0415/194215.948747:INFO:generate_logs.cc(103)] Logs saved to /tmp/debug-logs_20190415-194128.tgz
Move the tarball to /home/user/$USER_ID/Downloads
$ mv /tmp/debug-logs* /home/user/<tab-complete>/Downloads/
Attach the tarballs here.
Note that this isn't ordinarily required - the process of dumping firmware debug info and collecting it is automated.
Also, I take the comment in #22 back - the diff from 11647.0.0 to 11647.91.0
includes the Core40 driver update.
I am bisecting through it now, if I can find a repro case.
gm...@gmail.com
kirtika@, re #21 - I apologize if I latched onto 3 unrelated issues. I would have created a new one, but hesitated to do that since it sounded like one or all of the existing ones could have been the same problem. It sounds from #17 like my logs are showing that it matches this issue, so I'll stick with alt-shift-i and just reference this one.
an...@gmail.com
kirtika@: "1. You are on channel 8 (not 1/6/11 - the "advisable" ones for minimizing interference), 2.4 GHz is known for interference from bluetooth and microwave, and your logs show disconnect with reason code 4 which correlates with noise. "
I wrote that I chose channel 8 based on measurements from my AP, but since then I've tried all non overlapping channels as you recommend and had even more disconnections so I returned back to channel 8. Users report that they have even more disconnections using 5 Ghzhttps://www.reddit.com/r/PixelBook/comments/bcs1br/wifi_connection_issues/
"Not sure how you got the SNR numbers"
Got them from AP.
"Does this mean it worked for you in R72?"
I'm sure it worked in v71, and believe in v72 too, but I've filed a feedback about the problem in February or even in January after a week or two as I started experience the issue. It's hard to me to say what version it was because I went to beta channel about that time in hope to get another bug fixed.
"Are you by any chance running your Pixelbook in developer mode?"
No, I'm not. But I'll consider that, I need to test Crostini backup/restore because I set up a project there. Enabling dev mode will wipe my state partition, right? If I decide to go to dev mode I'll test v72/v71. iirc, I can dd v72/v71's rootfs/kernel partition pair from recovery images to my alternative rootfs/kernel partitions and change priority and success flags using cgpt to boot from it. The problem is that I don't have a usb-c flash drive in case if it doesn't boot. ChromeOS doesn't support any net boot technology, right?
I wrote that I chose channel 8 based on measurements from my AP, but since then I've tried all non overlapping channels as you recommend and had even more disconnections so I returned back to channel 8. Users report that they have even more disconnections using 5 Ghz
"Not sure how you got the SNR numbers"
Got them from AP.
"Does this mean it worked for you in R72?"
I'm sure it worked in v71, and believe in v72 too, but I've filed a feedback about the problem in February or even in January after a week or two as I started experience the issue. It's hard to me to say what version it was because I went to beta channel about that time in hope to get another bug fixed.
"Are you by any chance running your Pixelbook in developer mode?"
No, I'm not. But I'll consider that, I need to test Crostini backup/restore because I set up a project there. Enabling dev mode will wipe my state partition, right? If I decide to go to dev mode I'll test v72/v71. iirc, I can dd v72/v71's rootfs/kernel partition pair from recovery images to my alternative rootfs/kernel partitions and change priority and success flags using cgpt to boot from it. The problem is that I don't have a usb-c flash drive in case if it doesn't boot. ChromeOS doesn't support any net boot technology, right?
gm...@gmail.com
If this is indeed an Intel firmware issue, can the next version of Chrome OS go back to a previous firmware version? This problem has become quite bothersome. I just sent in an incident report where the problem occurred 4 times within 1 minute.
gm...@gmail.com
Still occurs after updating to Version 75.0.3770.129 (Official Build) (64-bit). Sent in an incident report a few minutes ago.
ki...@google.com
Can you file feedback via alt-shift-i and give me the email address it was filed from?
Or use a "kirtika_crbug_943157" in the feedback test?
I dont have access to "incident reports" if thats a thing, and searching on our feedback site (https://listnr.corp.google.com/product/208/reports ) for user:gpmorr@gmail.com doesn't give me anything.
Or use a "kirtika_crbug_943157" in the feedback test?
I dont have access to "incident reports" if thats a thing, and searching on our feedback site (
gm...@gmail.com
That's odd. I did use alt-shift-i from gmporr@gmail.com. Included this issue number in the description when I filed it. Previous reports by me seem to have shown up as indicated in
ki...@google.com
Reply #30: my bad, my query in #29 had a typo (gpmorr instead of gmporr).
Your report was indeed received:https://listnr.corp.google.com/product/208/report/86372503678
I am looking through changelogs b/w R72 and R73 now, please stay tuned.
Your report was indeed received:
I am looking through changelogs b/w R72 and R73 now, please stay tuned.
ki...@google.com
Dumping some information here for future reference.
R72 stable: 11316.xx.yy
R73 stable: 11647.zz.aa
Intel wireless driver update history:
Core43: 11931.0.0 (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1497816 )
Core40: 11675.0.0 (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1439520 )
Core38: 11017.0.0 (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1183859 )
(found with this query:
https://chromium-review.googlesource.com/q/project:chromiumos/third_party/kernel+branch:chromeos-4.4+owner:kirtika+status:merged )
Looking through go/crosland b/w 11316.0.0 and 11647.0.0:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/40c5dfe24177722e6453a9b4d6b7300957ea9cbc..80b921861fdfebef21c2841ecc71d40b9d6b5550?n=10000
There are 5 commits to kernel v4.4 (what the Pixelbook uses) iwlwifi, and none look related to this issue:
1. b6a09eb CHROMIUM: iwl7000: add new cards for 22560, 9260 and killer series by Ihab Zhaika
2. de23373 CHROMIUM: iwl7000: correct one of the PCI struct names by Ihab Zhaika
3. b0aedd5 CHROMIUM: iwl7000: add PCI IDs for the 22260 device series by Luca Coelho
4. 26350f8 iwlwifi: mvm: fix regulatory domain update when the firmware starts by Emmanuel Grumbach
5. 79faf40 iwlwifi: mvm: support sta_statistics() even on older firmware by Emmanuel Grumbach
1-3 are definitely "cosmetic" for the scope of this bug.
Checked 4-5 and they shouldn't affect 2.4 GHz operation either.
That leaves us with firmware changes...
And indeed there is :
f31818ad emmanuel.grumbach@intel.com iwlwifi: update firmwares for iwl7000 devices 7265D, 8000C and 8265
https://chromium-review.googlesource.com/c/chromiumos/third_party/linux-firmware/+/1392903/
This landed in 11545.0.0.
CC-ing some Intel folks as FYI. I will fork this into the internal 'buganizer' so we can track with Intel there.
On my side, I will try some channel 8 connect-disconnect loops with/without this firmware change:
https://chromium-review.googlesource.com/c/chromiumos/third_party/linux-firmware/+/1392903/
In the meanwhile, thanks for reporting and are you able to try to newer versions than R73? We've gone up two generations
of driver (if not driver+firmware) drops since then.
R72 stable: 11316.xx.yy
R73 stable: 11647.zz.aa
Intel wireless driver update history:
Core43: 11931.0.0 (
Core40: 11675.0.0 (
Core38: 11017.0.0 (
(found with this query:
Looking through go/crosland b/w 11316.0.0 and 11647.0.0:
There are 5 commits to kernel v4.4 (what the Pixelbook uses) iwlwifi, and none look related to this issue:
1. b6a09eb CHROMIUM: iwl7000: add new cards for 22560, 9260 and killer series by Ihab Zhaika
2. de23373 CHROMIUM: iwl7000: correct one of the PCI struct names by Ihab Zhaika
3. b0aedd5 CHROMIUM: iwl7000: add PCI IDs for the 22260 device series by Luca Coelho
4. 26350f8 iwlwifi: mvm: fix regulatory domain update when the firmware starts by Emmanuel Grumbach
5. 79faf40 iwlwifi: mvm: support sta_statistics() even on older firmware by Emmanuel Grumbach
1-3 are definitely "cosmetic" for the scope of this bug.
Checked 4-5 and they shouldn't affect 2.4 GHz operation either.
That leaves us with firmware changes...
And indeed there is :
f31818ad emmanuel.grumbach@intel.com iwlwifi: update firmwares for iwl7000 devices 7265D, 8000C and 8265
This landed in 11545.0.0.
CC-ing some Intel folks as FYI. I will fork this into the internal 'buganizer' so we can track with Intel there.
On my side, I will try some channel 8 connect-disconnect loops with/without this firmware change:
In the meanwhile, thanks for reporting and are you able to try to newer versions than R73? We've gone up two generations
of driver (if not driver+firmware) drops since then.
ki...@google.com
Since this is 2.4 GHz, probably we should not rule out the BT update that went in this timerange (R72->R73) as well:
99b679c3 amit.k.bag@intel.com Intel BT 7265: Optimize event and data handling when WoBT disable
Folks reporting here: Are you by any chance able to turn off bluetooth and see if it gets better?
99b679c3 amit.k.bag@intel.com Intel BT 7265: Optimize event and data handling when WoBT disable
Folks reporting here: Are you by any chance able to turn off bluetooth and see if it gets better?
ki...@google.com
gm...@gmail.com
@kirtika - Thanks for all the info. I originally started seeing the problem with R73, but today's alt-shit-i report was from R75 which I updated to a couple days ago. Re bluetooth: It's always been disabled on my system.
an...@gmail.com
I've noticed improvements since updating to v76. I still see the issue in router logs, but in real life use I've encountered the problem just a couple of times for the last 3 weeks.
gm...@gmail.com
Any updates from Intel? Still a problem in Version 77.0.3865.105 (Official Build) (64-bit).
an...@gmail.com
What's interesting, I recently bought a Google Pixel 3XL and now I see a record in router logs with the same problem for my phone. There is no such problem for 2 iPhones, an iPad and an iMac in the same network.
an...@gmail.com
@kirtika I can make a firmware dump now. Is it still actual?
ci...@google.com
Howdy, I'm encountering this problem consistently on my Pixelbook. Please let me know if it would be helpful to provide logs, etc. Anecdotally, it appears to happen far more frequently when pushing more data upstream (eg. videoconferencing), which is obviously especially annoying. Not sure if it's helpful, but I'm also using Google WiFi.
de...@google.com
logs in https://crbug.com/948179#c6 and https://crbug.com/948179#c21 has the same symptom:
1. In net.log: wpa_supplicant[643]: wlan0: CTRL-EVENT-DISCONNECTED bssid=d4:ca:6d:00:00:01 reason=4 locally_generated=1
2. In messages: iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
3. In feedback/wifi_status: connected station shows high beacon loss number.
I'll mark
1. In net.log: wpa_supplicant[643]: wlan0: CTRL-EVENT-DISCONNECTED bssid=d4:ca:6d:00:00:01 reason=4 locally_generated=1
2. In messages: iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
3. In feedback/wifi_status: connected station shows high beacon loss number.
I'll mark
de...@google.com
de...@google.com
Reproducible on overnight testing on hatch/kohaku. See:
dr...@gmail.com
I think I'm running into this same issue. I've got a collection of ChromeOS devices that have all had really weird wireless issues off and on, and I haven't been able to definitively pin down the root cause, but one thing that has been common to a few places I've run into issues is "enterprise wireless", either Ubiquiti UniFi or Cisco Meraki or others.
I've run into these issues with a Dell Chromebook 13 (7310), a Pixelbook, and a Dell Latitude 5300 Chrome where they will report poor signal and won't connect to an SSID even though a Macbook Pro and several Android phones and tablets all work with it just fine. The weird thing is I've got 3-4 SSIDs broadcasting off my APs and when things go off the rails, I'm still able to connect to one of the SSIDs (the one with the shortest/simplest passphrase). When it really won't connect I can usually turn off the Wifi on the Chromebook for a minute or two and enable it again and this seems to trigger a firmware reload or something that allows associating again.
I've run into these issues with a Dell Chromebook 13 (7310), a Pixelbook, and a Dell Latitude 5300 Chrome where they will report poor signal and won't connect to an SSID even though a Macbook Pro and several Android phones and tablets all work with it just fine. The weird thing is I've got 3-4 SSIDs broadcasting off my APs and when things go off the rails, I'm still able to connect to one of the SSIDs (the one with the shortest/simplest passphrase). When it really won't connect I can usually turn off the Wifi on the Chromebook for a minute or two and enable it again and this seems to trigger a firmware reload or something that allows associating again.
dr...@gmail.com
I think I finally narrowed down the issue, though it curiously only started happening to me in the last 5 releases or so.
The consistent cause of failure was attempting to connect to an SSID that was dual band, that is a single SSID string was being presented for both 2.4 GHz and 5 GHz frequencies. I disabled the 2.4 GHz or 5 GHz on a couple different SSIDs and was immediately able to connect to those from my Chromebooks again.
The consistent cause of failure was attempting to connect to an SSID that was dual band, that is a single SSID string was being presented for both 2.4 GHz and 5 GHz frequencies. I disabled the 2.4 GHz or 5 GHz on a couple different SSIDs and was immediately able to connect to those from my Chromebooks again.
re...@gmail.com
Same situation as Comment 48. Chromebook drops wifi connection every 30 seconds or so. Updated home router to a Gryphon, which uses a single SSID string for 2.4 GHz and 5 GHz bands and "Auto Band Steering" to optimize connections.
HP Chromebook 14
OS 81.0.4044.127
HP Chromebook 14
OS 81.0.4044.127
de...@google.com
Re comment 48, dragon788@ thank you for identifying a reproducible case. What router do you use right now? Is it home router or enterprise router? Which WiFi protocol do you use? WPA2 or 802.11x?
Re comment 49, revision31@, so you use the same SSID for both 2.4 and 5G bands and enable "auto band steering" to improve connectivity, right? Then that's contract with what comment 48 described.
Re comment 49, revision31@, so you use the same SSID for both 2.4 and 5G bands and enable "auto band steering" to improve connectivity, right? Then that's contract with what comment 48 described.
ci...@google.com
My network is also dual band on one SSID (Google WiFi). I've noticed that the Pixelbook that has issues always uses 2.4ghz, even though almost all other devices connected to the same network use 5ghz.
na...@gmail.com
Same situation as others. 2.4Ghz & 5Ghz bands with the same SSID and auto band steering enabled. Issue happens when running just my main router but issue has increased 10 fold since adding a mesh router (same brand as main router) into my home. I have several Chromebooks between myself and the kids in my house. All Chromebooks exhibit this issue.
dr...@gmail.com
@deanliao I've observed this on both SMB and enterprise equipment, but I think home routers will also exhibit the same issues as more people upgrade to newer ones that use a single SSID for both bands. I've noticed that most ISP equipment seems to default to two separate SSIDs but that may change eventually too.
The specific systems I have tested with are multiple installations of the Ubiquiti UniFi wireless system. My home network is multiple SSIDs to separate out media devices (no access to my local network, just the internet), one for security devices (wireless IP cameras), and one for legacy devices (2.4Ghz only) separate from one for modern devices because having both connected to the same radio limits faster devices to the slowest speeds.
Specifically my understanding of WiFi is if I have a device that can only do wireless B or wireless N at 2.4GHz and I also connect a wireless AC device to the same SSID/radio, the access point will only be able to communicate at the lowest common denominator.
To that end, it is far more convenient to have a single SSID for both bands so that if I walk outside and my device switches from 5GHz to 2.4GHz it automatically switches bands and doesn't need a separate network saved on my device which it won't switch to unless it loses contact with the 5GHz completely.
The specific systems I have tested with are multiple installations of the Ubiquiti UniFi wireless system. My home network is multiple SSIDs to separate out media devices (no access to my local network, just the internet), one for security devices (wireless IP cameras), and one for legacy devices (2.4Ghz only) separate from one for modern devices because having both connected to the same radio limits faster devices to the slowest speeds.
Specifically my understanding of WiFi is if I have a device that can only do wireless B or wireless N at 2.4GHz and I also connect a wireless AC device to the same SSID/radio, the access point will only be able to communicate at the lowest common denominator.
To that end, it is far more convenient to have a single SSID for both bands so that if I walk outside and my device switches from 5GHz to 2.4GHz it automatically switches bands and doesn't need a separate network saved on my device which it won't switch to unless it loses contact with the 5GHz completely.
na...@gmail.com
@kirtika@google.com per your comment (comment 33) looking for people to test turning off bluetooth. I did this now the last two days. I've seen a dramatic decrease in disconnect/reconnecting of my wifi. During a normal day with bluetooth on, I'd see 80-90 (or more) disconnect/reconnects during an 8-9 hour work day. With bluetooth off, over the last 12-14 working hours I've had maybe 4-6 disconnects/reconnects (maybe). I use a bluetooth mouse with my Chromebook and luckily it had the option of using the usb adapter as well.
gm...@gmail.com
I've always had bluetooth disabled on my system (Acer C771T, lars platform), and have been experiencing the problem fairly regularly for at least a year. Your comment is interesting that you say you'll see 80-90 disconnects per day with bluetooth enabled. With it disabled, I'll see between 0 and 4 disconnects/reconnects per day. I'll try enabling bluetooth for a while to see if the frequency increases.
Are the Chrome OS developers still going on the assumption that it's an Intel firmware bug? Have there been any updates from Intel since July of last year? (See comments #20 and #34). Seems it would be easy to confirm whether or not it's Intel's problem, if a newer version of Chrome OS could revert back to an Intel firmware version from before anyone started experiencing the problem.
Are the Chrome OS developers still going on the assumption that it's an Intel firmware bug? Have there been any updates from Intel since July of last year? (See comments #20 and #34). Seems it would be easy to confirm whether or not it's Intel's problem, if a newer version of Chrome OS could revert back to an Intel firmware version from before anyone started experiencing the problem.
dr...@gmail.com
Certainly interesting to hear of an additional possible correlation with Bluetooth as I typically don't use Bluetooth on my Chromebook but recently I paired my Pixel Buds and while I haven't had WiFi issues I have been having more cases where the audio will get choppy on the buds until I disable Bluetooth for a little bit and re-enable it and then it is fine for quite a while.
My Wi-Fi has been connected to a 5 GHz network so Bluetooth would be the only thing using 2.4 GHz on the chip when I'm having issues.
My Wi-Fi has been connected to a 5 GHz network so Bluetooth would be the only thing using 2.4 GHz on the chip when I'm having issues.
gm...@gmail.com
I did not see any significant increase in the number of disconnects when I had bluetooth enabled for a few days.
de...@google.com
dragon788@, per comment 48, did you know when the regression take place? The issue can be reproduce in the same SSID on both 2.4G and 5G channel, right? Which device had Bluetooth audio issue?
ciaranh@, that's weird. The ChromeOS code logic should prefer 5G band. Can you upload feedback report with the issue number attached?
ciaranh@, that's weird. The ChromeOS code logic should prefer 5G band. Can you upload feedback report with the issue number attached?
dr...@gmail.com
I think it was maybe around r77 or r78. I found a note I'd sent to some folks in one of our channels on February 5th noting I'd had some issues connecting that which which briefly went away after a factory reset but then came back after a little while. In hindsight this was probably when the device tried switching between wireless frequencies.
ci...@google.com
@deanliao: done!
dr...@gmail.com
deanliao, re: the device with the Bluetooth issues, my Dell Latitude 5300 Chrome was occasionally stuttering/crackling with my new Pixel Buds.
Oddly enough my Pixelbook (i7/512GB) that is in Developer Mode and on the Beta (and now Dev) channel doesn't allow me to enable Bluetooth now at all, so I may have to powerwash and/or factory reset via USB to see if I can get it working again, because not having phone unlock available is REALLY frustrating.
Oddly enough my Pixelbook (i7/512GB) that is in Developer Mode and on the Beta (and now Dev) channel doesn't allow me to enable Bluetooth now at all, so I may have to powerwash and/or factory reset via USB to see if I can get it working again, because not having phone unlock available is REALLY frustrating.
de...@google.com
gm...@gmail.com
npoojary@ - Thank you for taking ownership of this issue. I've been wondering why the Intel firmware change ("f31818ad emmanuel.grumbach@intel.com iwlwifi: update firmwares for iwl7000 devices 7265D, 8000C and 8265") pointed out by kirtika@ in comment 32 has not been investigated further.
The disconnect problems for me and many other users definitely only started with Version 73, and kirtika@ seemed confident that the Intel firmware change was the most likely culprit.
Thanks very much for your assistance.
The disconnect problems for me and many other users definitely only started with Version 73, and kirtika@ seemed confident that the Intel firmware change was the most likely culprit.
Thanks very much for your assistance.
is...@google.com
ma...@gmail.com
Is there an update on this issue? My wifi consistently drops and then reconnects connection (dozen or more times in a single hour). I have a Lenovo Chromebook Duet running ChromeOS on the latest beta build 89.0.4389.16 and a Google Wifi router running 2.4/5Ghz bands on the same SSID. It is very frustrating that although the issue appears to be specific to certain wifi cards commonly used on ChromeOS devices and routers sharing SSID for both bands, Google's ChromeOS is not functioning as intended with an also-Google AP. This makes work very difficult for anything requiring a solid connection (e.g., SSH, live web displays/updates).
no...@google.com
<triage>
"No beacon heard and the time event is over already" is currently under investigation at
no...@google.com
Assigning to bugjuggler, pending on the blocking issues
bu...@google.com
Hi. I've received your bug and will wait for
Bugjuggler:
Bugjuggler:
bu...@google.com
no...@google.com
Fixes for the "No beacon heard and the time event is over already" should land in R96.
Description
UserAgent: Mozilla/5.0 (X11; CrOS x86_64 11647.91.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.79 Safari/537.36
Platform: 11647.91.0 (Official Build) beta-channel eve
Example URL:
Steps to reproduce the problem:
No specific steps, but most often it happens after waking up from sleep.
What is the expected behavior?
What went wrong?
Wifi disconnects/connects several times at random times, often after waking up from sleep. It takes couple of minutes to get stable connection. I've attached logs from my MikroTik RB751U-2HnD router, so you can match timings in logs. No other devices have such issue on the same network.
Did this work before? Yes I'm not sure, but I believe it's 72
Chrome version: 73.0.3683.79 Channel: beta
OS Version: 11647.91.0
Flash Version:
Repeating pattern from dmesg:
[62245.178075] wlan0: authenticate with d4:ca:6d:6a:38:99
[62245.185249] wlan0: send auth to d4:ca:6d:6a:38:99 (try 1/3)
[62245.189472] wlan0: authenticated
[62245.190241] wlan0: associate with d4:ca:6d:6a:38:99 (try 1/3)
[62245.193564] wlan0: RX AssocResp from d4:ca:6d:6a:38:99 (capab=0x431 status=0 aid=1)
[62245.194566] wlan0: associated
[62245.799234] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
[62245.799249] wlan0: Connection to AP d4:ca:6d:6a:38:99 lost
[62245.869879] audit: type=1400 audit(1552899361.857:139): avc: denied { sigchld } for pid=1675 comm="shill" scontext=u:r:cros_init_shill:s0 tcontext=u:r:cros_shill:s0 tclass=process permissive=0
Repeating pattern from netlog:
2019-03-18T10:54:07.642662+02:00 NOTICE wpa_supplicant[643]: wlan0: CTRL-EVENT-DISCONNECTED bssid=d4:ca:6d:6a:38:99 reason=4 locally_generated=1
2019-03-18T10:54:07.644146+02:00 ERR wpa_supplicant[643]: nl80211: Failed to open /proc/sys/net/ipv4/conf/wlan0/drop_unicast_in_l2_multicast: No such file or directory
2019-03-18T10:54:07.644176+02:00 ERR wpa_supplicant[643]: nl80211: Failed to set IPv4 unicast in multicast filter
2019-03-18T10:54:07.646034+02:00 INFO shill[1675]: [INFO:wifi.cc(873)] WiFi wlan0 supplicant updated DisconnectReason to -4
2019-03-18T10:54:07.649905+02:00 WARNING shill[1675]: [WARNING:wifi_service.cc(796)] Service 0 will disconnect due to no remaining endpoints.
2019-03-18T10:54:07.657151+02:00 ERR shill[1675]: [ERROR:object_proxy.cc(581)] Failed to call method: fi.w1.wpa_supplicant1.Interface.Disconnect: object_path= /fi/w1/wpa_supplicant1/Interfaces/1: fi.w1.wpa_supplicant1.NotConnected: This interface is not connected
2019-03-18T10:54:07.661589+02:00 ERR shill[1675]: [ERROR:dbus_method_invoker.h(113)] CallMethodAndBlockWithTimeout(...): Domain=dbus, Code=fi.w1.wpa_supplicant1.NotConnected, Message=This interface is not connected
2019-03-18T10:54:07.661618+02:00 ERR shill[1675]: [ERROR:chromeos_supplicant_interface_proxy.cc(184)] Failed to disconnect: fi.w1.wpa_supplicant1.NotConnected This interface is not connected
2019-03-18T10:54:07.664230+02:00 INFO shill[1675]: [INFO:dhcp_config.cc(194)] Stopping 25484 (ReleaseIP)
2019-03-18T10:54:07.675143+02:00 INFO dhcpcd[25484]: received SIGTERM, stopping
2019-03-18T10:54:07.675159+02:00 INFO dhcpcd[25484]: wlan0: removing interface
2019-03-18T10:54:07.680751+02:00 INFO dhcpcd[25484]: status changed to Release
2019-03-18T10:54:07.680878+02:00 INFO dhcpcd[25484]: dhcpcd exited
2019-03-18T10:54:07.700536+02:00 INFO shill[1675]: [INFO:service.cc(379)] Service 0: state Online -> Idle
2019-03-18T10:54:07.700566+02:00 INFO shill[1675]: [INFO:manager.cc(1488)] Service 0 updated; state: Idle failure Unknown
2019-03-18T10:54:07.703142+02:00 INFO shill[1675]: [INFO:manager.cc(1488)] Service 0 updated; state: Idle failure Unknown
2019-03-18T10:54:07.709887+02:00 INFO shill[1675]: [INFO:manager.cc(1633)] Default physical service: 49 (not connected)
2019-03-18T10:54:07.711042+02:00 INFO shill[1675]: [INFO:service.cc(293)] Suppressed autoconnect to service 49 (no endpoints)
2019-03-18T10:54:07.711050+02:00 INFO shill[1675]: [INFO:service.cc(293)] Suppressed autoconnect to service 0 (no endpoints)
2019-03-18T10:54:07.713500+02:00 INFO shill[1675]: [INFO:wifi.cc(1681)] WiFi wlan0 StateChanged completed -> disconnected
2019-03-18T10:54:07.749472+02:00 INFO shill[1675]: [INFO:wifi.cc(1681)] WiFi wlan0 StateChanged disconnected -> inactive
2019-03-18T10:54:16.207846+02:00 INFO shill[1675]: [INFO:wifi.cc(315)] Scan on wlan0 from ScanTimerHandler
2019-03-18T10:54:17.074566+02:00 WARNING shill[1675]: [WARNING:nl80211_message.cc(485)] Unknown/unhandled netlink nl80211 message 0x71
2019-03-18T10:54:17.079385+02:00 INFO shill[1675]: [INFO:service.cc(271)] wifi service 462 constructed.
2019-03-18T10:54:17.079814+02:00 NOTICE wpa_supplicant[643]: Removed BSSID d4:ca:6d:6a:38:99 from blacklist (clear)