thanks for confirming this - I am glad things work as desired at once.
At least in case of a database update, the debug output seems to be more verbose (running Core Update 153 testing):
[root@maverick ~]# location --debug update
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
If-modified-since: Sat, 12 Dec 2020 09:39:06 GMT
User-agent: location/0.9.5
HTTP Response: 200
Headers:
date: Sat, 12 Dec 2020 17:28:44 GMT
last-modified: Sat, 12 Dec 2020 09:40:55 GMT
etag: "417af4-5b641349b8dab"
accept-ranges: bytes
content-length: 4291316
x-content-type-options: nosniff
x-frame-options: deny
referrer-policy: strict-origin
x-xss-protection: 1; mode=block
content-type: application/x-xz
strict-transport-security: max-age=31536000; includeSubDomains; preload
connection: close
Opening downloaded database at /var/lib/location/tmpy99wcyto
Downloaded new database from Sat, 12 Dec 2020 09:39:06 GMT
The location program detects the most recent database version by resolving a DNS record, which is why no HTTP(S) request is needed in that case. However, the output is a bit scanty indeed…
To check the results of libloc for improved accuracy (in case you have downloaded today’s database or a future one, which will take one week at most), try running these commands and compare their output:
[root@maverick ~]# location lookup 51.15.0.1
51.15.0.1:
Network : 51.15.0.0/17
Country : Netherlands
Autonomous System : AS12876 - ONLINE S.A.S.
[root@maverick ~]# location lookup 51.15.129.1
51.15.129.1:
Network : 51.15.0.0/16
Country : France
Autonomous System : AS12876 - ONLINE S.A.S.
[root@maverick ~]# location lookup 95.216.0.1
95.216.0.1:
Network : 95.216.0.0/17
Country : Finland
Autonomous System : AS24940 - Hetzner Online GmbH
Testing Core 153 all is good and can even reproduce the output from the commands in your post. Great job goes out to the Ipfire Team! Noticed in the Monthly Teleconference from December 7th under Clarifying, reworking or dropping the location filter some interesting comments. I guess I never really thought about it, but yes Location Block is really just another filter in the iptables, after all the iptables are really one big filter. Should have been obvious. If Location Block is not enabled the incoming packet will be filtered by POLICYIN chain of the INPUT chain. However, in my opinion, dropping Location the location filter would be a mistake. I collected some statistics in the Location filter. Currently the location filter is dropping on average 8250 packets/day without logging. (I am sure others results will differ depending upon ISP policies and location) If these were dropped by the POLICYIN chain and logged to the Firewall logs, the task of examining the logs would be impossible. Finding a real problem would be come like looking for a needle in a haystack. Keep up the good work.
Pete
this IP address belongs to 100.64.0.0/10, which is assigned for shared IPv4 address space according to RFC 6598. It is therefore not private as its RFC 1918 pendants are, but it cannot be routed globally either.
There is no point in trying to determine where 100.64.0.0/10 is used (actually worldwide, I would imagine), hence it is omitted from the location database. Please refer to the source code for a complete list of all networks not included by libloc.
Anything else should work fine. Please drop me a line if it does not.
My knowledge about code is more than 25 years old - I wrote less than 20K lines in Turbo Pascal 6.0, therefore I am safe to say I don’t understand the source code.
I am happy to repot that Alibaba servers located in China are constantly blocked which for me is a signal that Location is back alive - and I have to create pinholes for the software I use (like Aliexpress app on my phone)
