Wi-Fi calling doesn't work on devices with Qualcomm's software when protection is enabled

[ESurina]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

4.12.2

Environment

• OS version: Android 15, 16
• Device: Xiaomi 15 / 15 Ultra, OnePlus 13

HTTPS filtering

• yes, I do

Root access

• yes, I have it

Integration with AdGuard VPN

• yes, I do

Routing mode

Local VPN

Ad Blocking

No response

Privacy

No response

Social

No response

Annoyances

No response

Security

No response

Language-specific

No response

Other

No response

Which DNS server do you use?

DNS protection disabled

DNS protocol

None

Custom DNS

No response

What Stealth Mode options do you have enabled?

No response

Issue Details

Steps to reproduce:

1. Enable Wi-Fi - Wi-Fi calling works after 2 seconds
2. Enable AdGuard protection
3. Disable Wi-Fi
4. Enable Wi-Fi

Expected Behavior

Wi-Fi calling works

Actual Behavior

Wi-Fi calling doesn't work

Screenshots

Screenshot 1

Additional Information

This is a bug in Qualcomm's iWLAN/ePDG implementation that causes the Wi-Fi calling tunnel to be disabled even when the VPN is only used for a limited set of applications or routing prefixes.

[zamanh]

What would be the fix for this, will an issue need be raised against the Android project?

[Enigmauk]

Confirming this issue on Poco F7 Ultra (HyperOS 3 / Android 15)

Environment:

• Device: Poco F7 Ultra
• OS: HyperOS 3 (Android 15)
• AdGuard: v4.12.2 (Local VPN mode, no root)
• Carrier: Talkmobile/Lebara (Vodafone UK MVNOs)
• Network: IPv4-only home network, 5GHz Wi-Fi

Symptoms:

VoWiFi cannot initialize when AdGuard is active. However, once established, VoWiFi remains stable with AdGuard running.

Testing Results (10+ hour stability test):

✅ Works perfectly:

• VoWiFi connection stable for 10+ hours with AdGuard enabled (no drops or re-keying failures)
• Incoming calls on VoWiFi work correctly with AdGuard active
• VoWiFi → Cellular handoff during active call works flawlessly (walked outside mid-call, HD icon remained, no drop)
• Connection resilient to WiFi signal strength changes
• Once VoWiFi is established BEFORE AdGuard starts, everything works indefinitely

❌ Fails:

• VoWiFi will not initialize in Airplane Mode when AdGuard is already running
• Cellular → VoWiFi handoff during active call fails (call drops immediately when WiFi connects)
  • Note: "Calling preference" is set to "Wi-Fi preferred" - same setting works perfectly on Poco F3
• After call drop, VoWiFi icon won't appear until AdGuard is disabled
• VoWiFi initialization takes 1+ minute after disabling AdGuard (often requires network reset)

Reliable Workaround:

1. Disable AdGuard protection
2. Enable Airplane Mode (turns off WiFi automatically)
3. Re-enable WiFi and wait for VoWiFi to connect (~5 seconds)
4. Re-enable AdGuard protection

Result: VoWiFi remains fully functional for 10+ hours with no drops. All handoffs from VoWiFi→Cellular work perfectly. The connection only fails when trying to hand off Cellular→VoWiFi during an active call.

Attempted Fixes (No Success):

• Added Vodafone ePDG IPs (148.252.188.96, 88.82.11.208, 88.82.11.221) to pref.vpn.ipv4.routes.excluded
• Added local network ranges (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) to excluded routes
• Excluded all IMS packages from AdGuard filtering:
  • vendor.qti.iwlan
  • com.qualcomm.qti.ims
  • org.codeaurora.ims
  • vendor.qti.imsdatachannel
  • com.qualcomm.qti.cne (UID 10141 - Connectivity Network Engine)
  • com.qualcomm.qti.telephonyservice

Logcat Analysis:

Key Finding: The IMS PDN (Packet Data Network) establishment fails with error code 219 when AdGuard's VPN is already active before attempting VoWiFi initialization.

Critical log sequence during failed initialization (airplane mode enabled with AdGuard running):

01-29 193247.066 5131 5671 D IWlanJni deactivateDataCall start
01-29 193247.073 3308 4299 D ConnectivityService | 100 | CELLULAR | EVENT_NETWORK_INFO_CHANGED, going from CONNECTED to DISCONNECTED
01-29 193247.084 2625 2712 E imsd | ImsPdnInfo.cpp | 264 | ImsPdnInfo | PDN brought down from Android framework, mtu size 0, Net handle 0
01-29 193247.084 2625 2712 E imsd | ImsPdnInfo.cpp | 253 | ImsPdnInfo | Current CNE State 2, Previous state 4
01-29 193247.590 2625 2712 E imsd | PdnInfoImpl.cpp | 689 | PdnInfoImpl | handleDsiEvents | PDN Disconnected Couldn't be retried, reason code 219
01-29 193247.608 5029 5029 I QImsService | ImsServiceSub[1]: type: 25 status: 2 isValid: true

Error 219 indicates the PDN connection was administratively blocked and marked as non-retryable.

Root Cause Analysis:

The issue is NOT with VoWiFi stability or IPSec re-keying—once established, VoWiFi works perfectly for extended periods. The problem occurs specifically during IMS PDN establishment phase.

Qualcomm CNE (Connectivity Network Engine) service (com.qualcomm.qti.cne, UID 10141) performs network interface enumeration before establishing the IMS PDN tunnel. When AdGuard's VPN interface is active:

1. CNE queries the default network and receives tun0 (AdGuard) instead of wlan0 (WiFi)
2. CNE interprets this as an invalid network path for ePDG tunnel establishment
3. The IMS daemon (imsd) aborts initialization with error 219
4. The system marks the PDN as non-retryable, blocking VoWiFi until AdGuard is removed

This is purely an initialization/registration failure—not a routing or packet filtering issue. No IMS packets are ever sent because CNE aborts before creating sockets.

Why This Is an Android 15 Regression:

Android 14 (HyperOS 1) behavior:

• Per-app VPN exclusions worked correctly for system services
• CNE queries returned the underlying physical interface (wlan0)
• VoWiFi could initialize successfully regardless of VPN state

Android 15 (HyperOS 3) behavior:

• System service UID-based exclusions are not honored
• CNE always sees the VPN interface as default, even when excluded
• VoWiFi initialization fails if VPN is active before registration attempt
• However: Once VoWiFi is established first, the existing tunnel works perfectly with AdGuard

The Specific Problem:

This is a bootstrap order issue. The CNE service needs to see the actual WiFi interface (wlan0) during the initial IMS registration handshake with carrier ePDG servers. Once the IPSec tunnel is established and IMS is registered, the connection can route through AdGuard's VPN without any issues.

The failure scenarios are:

1. Cold start: Turn on airplane mode with AdGuard already running → CNE sees tun0 → registration fails
2. Active call handoff: On cellular call, connect to WiFi with AdGuard running → CNE attempts to establish VoWiFi PDN but sees tun0 → call drops instead of handing off

Proposed Solution:

AdGuard needs to implement temporary VPN bypass during IMS registration events:

1. Detect when CNE (UID 10141) initiates IMS registration queries (detectable via ConnectivityManager.getActiveNetwork() calls from this UID)
2. Temporarily return the underlying physical interface for these specific queries (only during initial handshake)
3. Once the ePDG tunnel is established, normal VPN routing can resume

Alternatively, implement a "System Network Queries Bypass" mode where system service UIDs (particularly UID 10141) always receive the physical network interface, not the VPN interface, when calling network enumeration APIs—but still route their actual traffic through the VPN after sockets are created.

Why Current App Exclusions Don't Work:

App exclusions in AdGuard only affect traffic routing after sockets are created. The CNE failure happens before socket creation, during the ConnectivityManager query phase where Android returns the "best" available network. Since Android 15 considers the VPN the best network for all UIDs (even excluded ones), CNE aborts before attempting any connection.

Cross-Device Comparison (Confirms Android 15 Regression):

Poco F3 (HyperOS 1 / Android 14) - ✅ WORKS PERFECTLY:

• Same carrier (Talkmobile/Vodafone MVNO)
• Same SIM card
• Same AdGuard version (v4.12.2)
• Same AdGuard configuration (Local VPN mode)
• VoWiFi initializes successfully in Airplane Mode with AdGuard running
• Cellular ↔ VoWiFi handoffs work in both directions during active calls
• No need for ePDG IP exclusions or any workarounds

Poco F7 Ultra (HyperOS 3 / Android 15) - ❌ FAILS:

• Identical configuration to Poco F3
• VoWiFi will not initialize with AdGuard active
• Cellular → VoWiFi handoff drops calls
• Once established (workaround), remains stable for 10+ hours

This proves:

1. The issue is NOT carrier-specific (same network config works on Android 14)
2. ePDG IP exclusions are NOT the solution (F3 doesn't need them)
3. This is definitively an Android 15 VPN framework regression affecting how system service UIDs query default networks
4. The Qualcomm IMS stack code is identical (same vendor), but Android 15's ConnectivityManager behavior changed

---

Question for AdGuard team: Is there any possibility of implementing special handling for IMS-related system service UIDs during network interface queries, to allow VoWiFi registration to complete while maintaining VPN protection for actual data traffic?

Note: Full logcat analysis available if needed for debugging.

[zamanh]

I have now upgraded to the Xiaomi 17 and I am not seeing this issue on there.

[Enigmauk]

Interesting and helpful. I won't be upgrading my phone any time soon, as nice as the Xiaomi 17 would be, so I'm hoping for a fix either from AdGuard or via updated HyperOS firmware.

Despite me previously stating Android 15, my Poco F7 ultra is running Android 16 in HyperOS version 3.0.5.0. with the Dec 2025 security update. The Xiaomi 17 is presumably on a later HyperOS build, which gives me some hope as AdGuard works there on the same Android 16 & HyperOS foundation. Hopefully fix may arrive for the F7 Ultra when it receives its next HyperOS update.