/e/OS sending requests to iran
Hi, I was messing with rethink dns to see what was its possibilities. then I saw this "surprise". Is this a normal behaviour ? Do we know what it does ? Does anyone has observed this on its phone ?
Edit : got an answer on eOS forum, it confirms what you guys told me :
rethink uses ipinfo lite (db-ip.com before) - their info atm says germany. it’s a hetzner ip anyway. If you trace the network path you’ll see it’s their fsn1 datacenter.
incorrect display of GeoIP data · Issue #2499 · celzero/rethink-app · GitHub
It looks like there could be a bug in how Rethink “searches” IP ranges to geo location… Rethink doesn’t use the mmdb format, but pre-processes the csv (code) to make it “searchable”.
Thank you all for your help :)
13 replies
A trace route seems to indicate that the IP address is in Germany and currently belongs to Hetzner.
As others have said, most probably an incorrect geoip entry.
or one that hasn't updated yet.... ip blocks change owners from time to time
Thanks for the answer, it's definitively reassuring that all the answers point to this kind of situation.
One thing to keep in mind is geo IP mapping are best effort.
Look at anything to do with Azure. It always shows the IP as US no matter where you deployed your stuff.
Yes, it could be going to Iran, it could also be someone has purchased address space and haven't updated the geo IP databased yet.
Could also be someone fat fingered their own IP block and the databases are wrong.
We has that happen to us in Australia, someone fat fingered their adjacent address block and suddenly our Australian block was showing up as Chinese.
I'll try to post on murena forum and if i have an answer, I'll post it here.
Ok, so there are "simple" explanations about that. That's a bit reassuring. I've blocked the "ntfy" app with rethink until I had news. It doesn't seem to block anything vital for the system.
Thanks for the answer :).
ntfy is a client for the UnifiedPush protocol, an OSS alternative to Google's firebase cloud messaging. It provides push notifications for compatible apps, this way instead of having each app wake up periodically to check for updates over the network, only one app (ntfy) keeps running the background and wakes the appropriate app when it gets a new push.
I've never used /e/OS but given the URL in your screenshot I guess murena uses UnifiedPush to send push notifications to its system apps. Blocking it may prevent you from getting system update notifications and such.
Thanks for the details ! I'll check manually until I got an answer from /e/os. But it really seems to be a non problem that happens quite often.
Your question is "why ntfy chose that server" or "what is ntfy and push"?
Mostly why this server. As ntfy sounds like notify, I believed it is for pushed notification, which has been confirmed by someone.
Yes, this is for push notifications to work. When running a degoogled OS I'd expect to not ping google about my notifications. I haven't heard of a proof that google used it to track us but I wouldn't be surprised. Also, from time to time apps without gapps have problems with google's push for unknown reasons. In order to work any push service needs an external server to ping
As for the IP, this shows something else. But as others mentioned those lookups are mostly guesswork and country ranges
Just checked on Rethink and I can confirm... Don't know what to think about it yet. I also see that MicroG is making a lot of calls.
I'm still a bit lost about that. Slazer has bring a potential answer to what could be the reason. I'll see to post that on /e/os forum this evening if I can, to have an answer from murena.
Yes microG is talking a lot. That's not really a surprise, as it mimics google play services. I suppose it talks even more if you have a lot of app that use cloud messaging.