Hi everyone,
I’m still struggling with some connectivity issues, but have never been able to really put a finger on them, yet.
The weird thing: Those issues only occur while I’m in my wifi. When connected through 4G, etc. it works.
Now you’d think “ok, then it must be my home firewall.” But my other phone with a stock ROM and some of the same apps don’t have those problems. And when switching off iode filtering, it also worked at home via wifi.
Let’s focus on the stocks problem. Since the yahoo address must be on some generic blacklist, I had whitelisted the address for that stocks app. Connection failed as indicated (in German) in the upper right corner of the first two screenshots:
Here’s the “log” from iode which says it was supposedly allowed (but the app couldn’t download):
Now I unauthorized it again for that single app in order to generally authorize it for all apps:
Don’t have the success screenshot at hand right now. But it worked only if allowed for all apps.
I haven’t written a widget app myself, yet. Maybe the connection attempts leave with some different source package name. Just a theory.
But I was able to reproduce this: When authorizing the Yahoo address for the stocks app only, it wouldn’t work. I had to generally allow it. That’s not how it’s supposed to work, isn’t it?
BTW: There’s a typo in German. Should be “weniger als eine Minute zuvor”.
I see there is a key symbol in your status bar
Means, you have a vpn running?
Maybe this blocks the URL
Or do you use another DNS with filtering, except the iode app?
Maybe on your home router. Because it works in mobile, but not in WLAN
Seams there is a DNS blocking in your home network.
What’s your DNS IP?
1 Like
I cannot reproduce. I tried the Stocks app on three different phones. It worked on all, by authorizing the yahoo domain for the app only…
that’s what i mean. @oRKywork say, it only happens in his wlan. but not outside or in mobile data.
so, for me it smells like DNS blocking…
Yes, but I don’t understand why whitelisting works for all apps works, and not for the Stocks app only ? Both should be blocked if there is an external blocker…
No, not if the domain is only blocked by a blocking dns (e.g. Quad9, cleanbbrowsing, etc…) on a external router which act as DHCP server or standalone nameserver in the home network. and NOT by the phone for itself (iode app)
Ok, but the external router should block the yahoo domain also when it is whitelisted for all apps ?..
Or: on the phone itself, there’s an app which ensures all DNS requests !! So the domain should be unblocked for that app too. But it should appear in the live stream…
That’s while I asked above
The key symbol
Normally it stands for a vpn?
The iode app does not bring this symbol. Or?
But all other AntiTracker or Firewall Apps with DNS filter…
Yes it’s a VPN connexion, and no iodé does not use it. That’s an advantage of our approach wrt some other blockers which entirely run in user space but require the VPN.
So probably, the app that uses the VPN also captures the DNS traffic, but is itself filtered by iodé. Probably, unblocking the yahoo domain for the Stocks app and the app that manages the VPN would work.
Sorry for the delay. After writing the original question I was constantly on the go yesterday.
The additional filter VPN (Netguard) was not the issue, but I should have disabled it before reporting here nevertheless.
It looks like I may have misunderstood something about the configuration of the 3 different categories
Standard | Enhanced | Adapted (I assume those are the English translations).
Unfortunately I hadn’t taken a screenshot of it to see what its setting was yesterday. I see now that in order for “allow for app xyz” to work, it requires the “adapted” checkbox to be active for that app as well.
I apologize for the trouble I’ve caused.
Currently it’s working. However it doesn’t explain why it worked when I was out of my wifi.
As I said a couple of other phones without iode had no issues to make those connections.
=========
As for the push notifications: I understand an app needs to
But what happens firewall-wise when messages are delivered? Is microG the recipient network wise or is a push message “delivered” to the app itself?
So in other words, after an app has received its device key and reported it to its app server, could I lock the app down entirely and push messages should still come in as long as microG can breathe?
=========
I’m quite familiar with doing network analysis myself via a command line, but doing anything of that sort on a smartphone is a pain in the butt :-).
So I could probably find the answer to the following questions myself, but I’d prefer to just ask you guys:
- I understand iode’s foundation is a hosts-blacklist. Any further functionality is built on top of that.
- I believe among others this one is used: GitHub - EnergizedProtection/EnergizedBlu: Lightweight Energized Protection.
- So when I’m a program and I try to access a resource that’s forbidden, how is that handled?
- Do I get 0.0.0.0 when I make a DNS lookup?
- What if I know the IP already and try to connect to it directly?
Yes. Reformulated for my own understanding 
About GCM, nothing has to be done in iodé blocker, it should work out-of-the-box. However, apps register to GCM at their first start ; and if in microg google registration/GCM is turned off, it may happen that all apps need to register again. Only solution : clear app storage or reinstall them.
Other points:
- yes, blacklists are at the basis of everything. Behind the hood, we filter DNS traffic and sniff network packets.
- we actually only use energized lists, but have in project to extend the ‘Extreme’ protection with other lists.
- if an app tries to access a forbidden host with DNS, it gets the answer that the host does not exist (no ip like 0.0.0.0 is given: the “no exists” is an answer by itself which is interpreted by the system in a special way (particularly, the system does not try to access it several times until it succeeds)
- if you know the IP, you can access to the host, unless you’re in a special case. When we access to authorized hosts by DNS requests, we also keep their IP. If a host is then forbidden in the iodé blocker, as we know its IP, we block it for one hour. This has for effect that blocking a host has an immediate effect, even if its IP is already known by some apps that are running. After less than an hour generally, a DNS request is required to access this host again, so it is blocked by the DNS blocking mechanism.
1 Like
Hi everyone,
it seems I was able to fix my issue after all.
It looks like my home firewall really did block GCM. I had to open TCP 5228-5230.
Except for a couple of ports, outgoing connections are by default blocked.
Now the weird thing is that this FW configuration has generally been in place for several years. All my old phones with stock ROMs have never had any issue receiving push messages. So I can only assume that microG behaves differently than Google’s own implementation does.
Thanks a lot for your help and explanations!
1 Like
my speech…