M
myMoon
Guest
This is a small hotfix for the recent AdGuard for Android release. Mostly squashing bugs related to the new features introduced in v3.2.
Last edited by a moderator:
Purple Tentacle
Member
Ok, something is seriously wrong with this release.
I'm on a Mate 10 Pro with EMUI 9.1/Android 9.0 and I'm using AdGuard in VPN Filtering Mode.
After upgrading all traffic grinds to a halt as long as AdGuard's DNS Filtering is enabled. DNS requests are simply completely broken.
The only DNS filter list enabled here is the "AdGuard Simplified Domain Filter" and everything is up to date. System DNS is chosen.
A reboot did not fix this either.
Only turning off the AdGuard or AdGuard's DNS Filtering makes the phone usable again.
I had no issues on any of the previous 3.2.x beta or release builds.
I'm on a Mate 10 Pro with EMUI 9.1/Android 9.0 and I'm using AdGuard in VPN Filtering Mode.
After upgrading all traffic grinds to a halt as long as AdGuard's DNS Filtering is enabled. DNS requests are simply completely broken.
The only DNS filter list enabled here is the "AdGuard Simplified Domain Filter" and everything is up to date. System DNS is chosen.
A reboot did not fix this either.
Only turning off the AdGuard or AdGuard's DNS Filtering makes the phone usable again.
I had no issues on any of the previous 3.2.x beta or release builds.
M
myMoon
Guest
Well, if you switch to another DNS server does the problem still exists?
Purple Tentacle
Member
Yes. System DNS, AdGuard DNS, any other custom DNS ... it doesn't matter. If the DNS Filter is enabled, all DNS lookups fail.
D
Deleted member 25072
Guest
Im on android 6 and i dont have any errors maby https filtering is the problum?
speedingcheetah
New Member
no apps will load connectivity....with this new version. I updated 2 family members phones today (free version) and they both came to me a an hour later saying nothing would load. Turing off dns filter does nothing. allowing the app to be excluded from adguard restores connectivy to each app...but over all, thing very slow and unstable. disable protection, everything works fine. My personal phone(Pixel 3 with 9.0) has Premium, same settings as the phones that are on free, and mine have not had issues yet. 2 other family members on Premium, they have yet to ask me to look at thier phones. HTTPS filtering is not enabled on the phones..since users refuse to have any sort of lock screen. I have reverted to ver 3.2.135 on the problem phones. works fine with no change in settings. They are a nexus 5x with 8.0 and a Moto E4 with 7.1.1. I have only been using adguard for 2 days, and just paid for 3 Premium licences....and now it makes my folks phones un-useable!!???.....bad experience right off the bat. Do u people actually test your updates???
Last edited:
D
Deleted member 25072
Guest
maby some of the phones have it which phone are you using?
Purple Tentacle
Member
I don't understand why this update hasn't been pulled asap and is still rolling out.
You guys have tons of credible reports that it breaks connectivity and you still keep rolling it out, leaving less tech savvy users with broken phones.
You guys have tons of credible reports that it breaks connectivity and you still keep rolling it out, leaving less tech savvy users with broken phones.
Purple Tentacle
Member
They have never tested these "hotfixes" beyond their own machines as far as I know.
They have been lucky and haven't messed things up quite this badly in one of them in the past.
What boggles my mind is why they don't take these reports seriously enough to pull the update.
Hi guys,
Sorry for the late reply.
Could you please do the following:
1. Collect the debug log as it's explained here: https://kb.adguard.com/en/android/solving-problems/log
2. Remember the exact time when the issue was reproduced, we will need it to find the corresponding records in the log file.
3. Send the logs to devteam@adguard.com
Sorry for the late reply.
Could you please do the following:
1. Collect the debug log as it's explained here: https://kb.adguard.com/en/android/solving-problems/log
2. Remember the exact time when the issue was reproduced, we will need it to find the corresponding records in the log file.
3. Send the logs to devteam@adguard.com
It was tested on the nightly channel for a few days.
Okay, I haven't seen the logs yet, but I bet that the reason is the Firewall logic change in this update.
Before that change, it was not possible to restrict network access for the DNS requests. They were always allowed even if you restrict network access globally. Now the situation is different and DNS requests are not excluded anymore. On one side, this is a fair and proper behavior.
However, there is another issue that makes it not so good. When AdGuard blocks network access for an app, it shows a notification about this and lets you temporarily allow network access for this app. But it does this only if the app is in the foreground, and does not do anything for background apps. The problem with DNS requests is that they are sent by Android OS is always in the background.
Shame on me that I've missed this consequence of the logic change. This is definitely worthy of another hotfix update.
Now we have two options:
1. Return the old logic
2. Consider "DNS" and "Android OS" "always foreground" so that when AG blocks network access for them, it showed a notification about that, and users could not miss that fact.
Before that change, it was not possible to restrict network access for the DNS requests. They were always allowed even if you restrict network access globally. Now the situation is different and DNS requests are not excluded anymore. On one side, this is a fair and proper behavior.
However, there is another issue that makes it not so good. When AdGuard blocks network access for an app, it shows a notification about this and lets you temporarily allow network access for this app. But it does this only if the app is in the foreground, and does not do anything for background apps. The problem with DNS requests is that they are sent by Android OS is always in the background.
Shame on me that I've missed this consequence of the logic change. This is definitely worthy of another hotfix update.
Now we have two options:
1. Return the old logic
2. Consider "DNS" and "Android OS" "always foreground" so that when AG blocks network access for them, it showed a notification about that, and users could not miss that fact.
Purple Tentacle
Member
No. Every Firewall setting is in its default state (everything is enabled/allowed by default). Almost every setting in AdGuard is pretty close to default, if anything I have chosen to disable AdGuard protection (bypass) entirely for many apps.
This is not related to AdGuard's firewall functionality. Switching the entire Firewall feature to "Off" and the DNS Filter to "On" still leaves all DNS requests broken.
This is very likely caused by the dnsproxy library update or the changes made in #3014
Last edited:
@Purple Tentacle well, I really need to see your logs then.
Also, please try this build - it has the same changes as .140, but with the previous dnsproxy version:
Also, please try this build - it has the same changes as .140, but with the previous dnsproxy version:
Purple Tentacle
Member
Well, at least we now know that wasn't it, still broken.
You have no idea how uncomfortable it is to give out that massive amount of private information each time something in AdGuard breaks.
But you should have your logs now.
Specific timestamps of the error happening: During the entire duration of enabling "log everything". I made some requests in Chrome, including to sites I haven't visited before. And I made a couple of requests inside Boost for Reddit. 100% broken.
@Purple Tentacle nothing in the devteam inbox, maybe anti-spam failure.
Could you please forward it to my personal email (am@adguard.com)?
Could you please forward it to my personal email (am@adguard.com)?
Purple Tentacle
Member
As I sent it directly from inside the app, there's nothing to easily forward here.
It was sent and received, your autoreply mailer assigned me a helpdesk ID. I'll PM that to you.
It was sent and received, your autoreply mailer assigned me a helpdesk ID. I'll PM that to you.