microg / microg/GmsCore

Cloud Messaging can continue to use wrong network preference when a VPN is involved

Open
#1,917 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Java
Stars
14.6k
Forks
3.2k
Avg merge
12d 11h
Merged PRs (30d)
4

Description

Describe the bug
When microG first connects to Cloud Messaging, it determines which preference represents its active network, and that determination does not change until the connection is re-established. The problem is, with a VPN, the connection may not need to be re-established when switching between Wi-Fi and mobile data. This can lead to learned misattribution and the use of the wrong preference when determining which heartbeat period / reconnection interval to use.

To Reproduce
Steps to reproduce the behavior:

  1. Use an Android device with mobile data and Wi-Fi available.
  2. Connect to a VPN capable of staying connected during network switches (Wi-Fi to mobile and vice versa), e.g. Riseup VPN with "Use UDP if available" chosen in Advanced Settings, or Wireguard.
  3. In microG settings, go to Cloud Messaging.
  4. Tap the 3-dot menu and choose Advanced.
  5. Temporarily set each of the network types to 60 seconds.
  6. Connect the device to a computer via USB for debugging.
  7. Connect the device to Wi-Fi.
  8. Run adb logcat > output.txt
  9. Wait 3+ minutes, but don't cancel the output.
  10. Disconnect from Wi-Fi.
  11. Wait 3+ minutes.
  12. Stop the adb output (Ctrl-C) and find lines containing "learnReached"
  13. (Cleanup) Undo the temporary changes made in step 5.

Expected behavior
The learnReached lines should differ depending on whether you were connected to Wi-Fi or not. For Wi-Fi, they should include gcm_network_wifi, and for cellular data, they should include gcm_network_mobile.

For example, if you connected to Wi-Fi at 16:50:53, the lines would continue showing gcm_network_mobile going forward:

04-19 16:47:01.539 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60038
04-19 16:48:01.604 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60066
04-19 16:49:01.690 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60086
04-19 16:50:01.705 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60014
04-19 16:50:53.404 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 51699
04-19 16:51:53.462 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60058
04-19 16:52:53.557 10099 23714  5294 D GmsGcmPrefs: learnReached: gcm_network_mobile / 60094

System
Android Version: 13
Custom ROM: CalyxOS 4.8.0

Additional context
Noticed while trying to debug issues with delayed notification delivery.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with play-services-core/src/main/java/org/microg/gms/gcm/McsService.java at the active-network determination referenced in the issue, then trace the GmsGcmPrefs learnReached logging. Reproduce the Wi-Fi/mobile switch with a persistent VPN and compare the logged network preferences; done means the learnReached output reflects the currently used network.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.