Some public WiFis require sign-in.
Since you will not be able to connect to the Internet until you sign in, you will receive a "Failed to check for updates" notification.
Is anyone experiencing the same thing?
Updater seems to try to check updates before signing in to a public WiFi.
Did you check System | System update | Permitted networks? It should be "Unmetered". The default is "Any".
OK, here is what I think - you set it to Unmettered, so it will not use the cellular data for the updates. As you described, you got the message when you basically have no internet connectivity to WiFi and disabled the updater to use cellular data. Then for me, the message looks correct. The updater is scheduled to check for updates every 4 hours or so.
- Edited
I think it would be nice if the updater detects if the device has full access to the Internet, i.e., if the user is not confined to a captive portal.
If the connection is not restricted, check for updates.
If the connection is restricted, wait until the Internet is fully accessible.
2 months later
I think there is the same problem if you use a VPN and activate airplane mode. GOS 'thinks' he has still access to internet.
In fact, since I use a VPN I wake up every morning with these "Failed to check for updates : Unable to resolve host" and "Remote verification failure : unable to resolve host" on my "airplane mode" device.
(I did not have these errors before using a VPN)
Is it a bug ? I thought the goal of GOS's "connectivity check" was exactly to avoid this.
[deleted]
I'm using VPN over Airplane Mode. No issues in more than a year.
- Edited
You mean that :
- you have VPN activated at all time,
- when you activate airplane mode, you don't have ~ 10 hours later any connection errors from "Apps", "Auditor" or "System update" ?
Interesting point : do you use an european or american timezone ? (Or other ?) Do you use default grapheneOS connectivity check or google one ? (Or none at all ?)
I understand that AOSP / GOS connectivity check is designed to bypass the VPN. But in my situation, it's like it also bypass the airplane mode. OR, as if the 3 'GOS' apps I quoted don't get information from the connectivity check.
Because one pic is better to explain (sorry I don't how to embed pic properly, it's not classic BBcode here) :
https://i.ibb.co/7YWLZCL/IMG-20230807-000009.jpg
[deleted]
- Edited
GOS2023 Yes to both.
European timezone
Google connectivity check (but I used GrapheneOS before without issues)
Because one pic is better to explain
I understand what you're referring to. This only happens to me when I grab my phone on my way out and half way through to my destination I realize I'm on Airplane Mode and not connected to my usual access point. Never happens on Wi-Fi (across several access points) or working mobile data and shouldn't happen to you.
[deleted]
- Edited
If it happens only over VPN your VPN setup is obviously the culprit here. I'd try fiddling with it to see if the issue persists. I used to have issues like yours all the time (missed checks, notifications etc) over Wireguard client using Mullvad until I hoped over to their client.
- Edited
[deleted] it happens on 2 different pixel phones. I also tried with 2 different setup (3rd party app controlling the VPN or pure wireguard setup)
In fact, I don't know how I can blame the VPN because the connectivity check doesn't do its job correctly.
(Reminder : the connectivity check is supposed to bypass the VPN, by design.)
Besides, the VPN is working perfectly fine, no random dc or timeouts.
I'll switch to google connectivity check for testing.
pappee pappee Our System Updater uses a scheduled job with internet access set as required. It only runs once the OS detects internet access is already working. This is already a feature it provides, not something it needs to implement.
pappee It's an issue with the VPN app that you're using, not with GrapheneOS or our update client. It's not properly using the VPN API to let the OS know when it's connected.
GOS2023 GOS2023 The connectivity checks are working fine according to what you've reported. It's the VPN that's not working correctly. Connectivity checks do not bypass airplane mode. Airplane mode means cellular disabled and doesn't block enabling Wi-Fi. If your VPN switches to Wi-Fi and presents the network as up when it isn't yet, that's a VPN app issue.
- Edited
GrapheneOS pappee It's an issue with the VPN app that you're using, not with GrapheneOS or our update client. It's not properly using the VPN API to let the OS know when it's connected.
GrapheneOS
I am using a Mullvad VPN and you are saying that the VPN is causing the errors?
- Edited
Sorry but it seems I (we ?) don't understand your logic.
You wrote here : https://discuss.grapheneos.org/d/1839-disabling-connectivity-checks-on-grapheneos/29
If the OS isn't performing connectivity checks, it doesn't know which networks are working and doesn't know when internet access is available. [...] If the OS doesn't know when it's available, the jobs will run when any network is available even if there's no internet access through it at the moment. You will get errors from multiple app background jobs instead of a single notice that no network access is available.
According to this post, I was assuming that :
"OS connectivity check" has the job to
1/ verify if internet is available (internet is not available when airplane mode is trigerred and wifi is not re-activated after (*)),
2/ if it's not available, postpone jobs like "System Updates""OS connectivity check" is not disturbed by the presence of a VPN because it bypass the VPN
(*) Mullvad VPN app and Wireguard app don't re-activate wifi after airplane mode is triggered. I think that many users can confirm this.
So, why blame the VPN whereas "OS connectivity check" is not supposed to interfere with it ?
- Edited
pappee Thanks, I had indeed the same errors this morning with google connectivity check.
It would be interesting to see if a Pixel phone with stock OS (without GrapheneOS) has the same errors (with an app like Auditor, which can be installed without GrapheneOS) when a VPN + airplane mode are used.
I also tried to tweak different OS settings like "Alwyas-On VPN", "Block connections without VPN", and allow "Unrestricted" battery usage for the VPN app, but it does not seem to change anything regarding the errors in airplane mode.
[deleted]
I use Proton VPN and have not encountered this issue when airplane mode is enabled.
- Edited
[deleted] Thank you for your input .
I guess you use default VPN settings set by Proton : "Always-on VPN" and "Block connections without VPN" are both "on" ?
I just installed Proton VPN app on a new profile, activated airplane mode, and I'm waiting for GOS app "Apps" next update. (*) So far apps like Vanadium act exactly like with Mullvad VPN app : they have no clue that connection is down and try to connect until reaching timeout.
(*) Edit : and it's done : problem reproduced with Proton VPN app. "Apps" app triggered the usual error while trying to update while airplane mode was activated and Proton VPN used.
The more I dig this subject, the more I think it's an upstream problem, and that "OS connectivity check" is almost useless when using a VPN... because even if it checks connectivity, the information is not handed down to apps, or maybe overruled by apps' own network detection process (which can be shortened as "If VPN present : internet is UP")
[deleted]
GOS2023 Yeah. I have both "Always-on VPN" and "Block connections without VPN" enabled.