Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wi-Fi calling in UK EE network does not function if Adguard is active #582

Closed
vozersky opened this issue May 24, 2016 · 12 comments
Closed
Assignees
Milestone

Comments

@vozersky
Copy link
Member

"When adguard is active, WiFi calling (native in android on the UK EE network) does not function. I have reproduced the issue with logging level set to 'record everything'. I tried a call out at first and although the other phone did ring and connect, this phone never did, just continued to display "dialing". when attempting to call in to this phone, it would not use Wi-Fi and reverted to cellular."

http://ee.co.uk/why-ee/network/wifi-calling

please refer to HEC-621-59634 for logs and more details.

@vozersky
Copy link
Member Author

This network operator doesn't use any specific app for wi-fi calls.
Tried adding "com.google.android.dialer" to pref.net.exclusions, didn't help.

@ameshkov please assist

@ameshkov ameshkov added this to the 2.6 milestone May 26, 2016
@ameshkov ameshkov self-assigned this May 26, 2016
@ameshkov
Copy link
Member

ameshkov commented May 26, 2016

Log analysis results below.

Issue 1 Two UDP connections created instead of one:

08:28:46.803 [Thread-1302] DEBUG com.adguard.android.filtering.vpn.h - UDP connect to /109.249.186.72:4500. Process info: root /0.0.0.0:32628 /0.0.0.0:0 0
08:28:46.804 [Thread-1302] DEBUG c.a.android.filtering.commons.d - UDP id=2210 Creating new connection for UDP 192.168.1.195:32628 > 109.249.186.72:4500 len=1316
08:28:46.805 [Thread-1302] DEBUG c.a.android.filtering.commons.d - UDP id=2210 Connection has been created.
08:28:46.806 [pool-2-thread-923] DEBUG c.a.android.filtering.commons.d - UDP id=2210 [OUT] UDP 192.168.1.195:32628 > 109.249.186.72:4500 len=1316
08:28:46.807 [pool-2-thread-923] DEBUG c.a.android.filtering.commons.d - UDP id=2210 Open UDP connection to /109.249.186.72:4500
08:28:46.811 [Thread-1302] DEBUG com.adguard.android.filtering.vpn.h - UDP connect to /109.249.186.72:4500. Process info: root /0.0.0.0:32628 /0.0.0.0:0 0
08:28:46.817 [Thread-1302] DEBUG c.a.android.filtering.commons.d - UDP id=2211 Creating new connection for UDP 192.168.1.195:32628 > 109.249.186.72:4500 len=836
08:28:46.818 [Thread-1302] DEBUG c.a.android.filtering.commons.d - UDP id=2211 Connection has been created.
08:28:46.824 [pool-2-thread-924] DEBUG c.a.android.filtering.commons.d - UDP id=2211 [OUT] UDP 192.168.1.195:32628 > 109.249.186.72:4500 len=836
08:28:46.825 [pool-2-thread-924] DEBUG c.a.android.filtering.commons.d - UDP id=2211 Open UDP connection to /109.249.186.72:4500

Wi-fi calling feature seems to be using UDP on port 4500 (IPSec i guess). Although I am not sure what's wrong with it.

I will prepare a new build soon to check if the problem is caused by this two-udp-connections issue.

@ameshkov
Copy link
Member

ameshkov commented May 27, 2016

@vozersky here is a test build:
adguard-android.apk.zip

Please ask user to check this new build. I'll need debug log in case if the issue persist.

@robdennehy
Copy link

robdennehy commented May 27, 2016

Hi @ameshkov and @vozersky,

I'm the user who's brought up this issue. I've tried it again and unfortunately the problem persists.

I've copied the current log file from the phone (Android/Data/Com.Adguard.Android/Cache/Log). I hope that is the correct file, seems easier than creating a new ticket by sending feedback in-app.

I conducted the test at 15:36 after setting logging level to "record everything". Same as before, call out and call in. Calling out resulted in the other phone ringing but mine continuing to say "Dialing" until told to cancel. Inbound call was eventually routed through cellular connection.
After deactivating adguard I tried the test again and connected a call before returning logging level to normal. With adguard disabled I'm not sure if it would have recorded anything but thought it worth doing in case it did.

Figured replying directly here would be easier than going through emails.

Thanks.

@ameshkov
Copy link
Member

Hi @robdennehy, welcome to github!

Checking out your log now.

@ameshkov
Copy link
Member

This may be the very same issue we had with T-Mobile wi-fi calling #233 The only way to fix that issue was to exclude T-Mobile subnet from the VPN.

@ameshkov
Copy link
Member

@robdennehy removed log from your comment as it contains your license key. We shouldn't write this to the log.

@robdennehy
Copy link

I did Google the problem before reporting the bug and found the thing about T-Mobile.
When you say excluding the subnet, will that impact the functionality of the app - i.e. will it stop ad filtering while using cellular data?

Thanks for being on the ball and removing the log file. If any more logs are needed I'll email them.

@ameshkov
Copy link
Member

Nope, should be good. We'll make this exclusions list configurable so next time there will be no need in a new build for such issue.

@ameshkov
Copy link
Member

@robdennehy could you please try this new build?
adguard.apk.zip

@robdennehy
Copy link

@ameshkov

That new build works perfectly. I see the new new low level setting too. Thanks for your help.

When the new version is officially released I'll mention it on the XDA EE Wifi-Calling thread as well, you may get a few new customers.

@ameshkov
Copy link
Member

ameshkov commented Jun 1, 2016

@robdennehy great, thank you for checking it!

@ameshkov ameshkov closed this as completed Jun 1, 2016
@ameshkov ameshkov changed the title Wi-Fi calling (native in android on the UK EE network) does not function if Adguard is active Wi-Fi calling in UK EE network does not function if Adguard is active Jun 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants