Location March 2022

location@lists.ipfire.org

4 participants
6 discussions

[0.9.12] export --format xt_geoip: (25, 'Inappropriate ioctl for device')
by Valters Jansons 31 Mar '22

31 Mar '22

On v0.9.12, I am observing an issue with XTGeoIP exports: the *.iv4 files do not get written. The sample command I use to reproduce this on Ubuntu 20.04 is very basic: location export --format xt_geoip --directory /usr/share/xt_geoip All IPv6 outputs are written successfully, but upon reaching IPv4 it errors with: (25, 'Inappropriate ioctl for device') A quicker test case is to add argument `--family ipv4` so that IPv6 is hopped over and it tries IPv4 right away. With strace, it seems to be: openat(AT_FDCWD, "/usr/share/xt_geoip/A1.iv4", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 4 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 ioctl(4, TCGETS, 0x7ffd234c3260) = -1 ENOTTY (Inappropriate ioctl for device) Please let me know if I can provide any further information. Best regards, Valters Jansons

2 9

libloc 0.9.12 released
by Michael Tremer 24 Mar '22

24 Mar '22

Hello, This is the release announcement for libloc 0.9.12. It comes with the following changes: * The importer is now able to process any aggregated networks from Bird. This was not implemented before and is now allowing us to parse the global routing table in its entirety. * Various functions to parse and manipulate IP addresses have been moved into their own files (address.h and address.c). This allows us easier re-using the code in various places. * The list of bogons (subnets without a known country) is not generated correctly over the entire IP address ranges. For that, the internal algorithms that summarise and gaps between multiple networks has been refactored to be faster and not use any trial-and-error approach any more. * Various internal data structures have been optimised for performance on the expense of slightly more memory usage when writing the database file. Please refer to the Git change log for more details on this. * The dump of the database now contains all networks again. Thank you to everyone who has contributed to this release. You can find the source here: https://git.ipfire.org/?p=location/libloc.git;a=shortlog;h=refs/tags/0.9.12 https://source.ipfire.org/releases/libloc/libloc-0.9.12.tar.gz Best, -Michael

1 0

Auto-generated plaintext updates; re: regression
by Jordan Savoca 10 Mar '22

10 Mar '22

Hello o/ Would it be possible to deploy the patch to the 0.9.11 regression on the system which generates the database.txt file committed to the location-database repository[1]? The database is currently devoid of IP announcement information. Thank so much! [1] https://git.ipfire.org/?p=location/location-database.git;a=summary -- Jordan Savoca

2 4

Plain text libloc database dumps are currently missing any IP network information
by Peter Müller 04 Mar '22

04 Mar '22

Hello libloc users, apparently, libloc 0.9.11 (https://lists.ipfire.org/pipermail/location/2022-March/000536.html) introduced a regression in the "dump" command, which dumps any given location database into one big, plain text file. After upgrading to 0.9.11, this file does not contain any IP network information, only information related to Autonomous Systems. Anybody using the _actual_ binary location database (for example, via "location lookup") is not affected. This issue only affects users relying on plain text database dumps. While this bug is currently under investigation (https://bugzilla.ipfire.org/show_bug.cgi?id=12790), affected users can temporarily go back to libloc 0.9.10, where "location dump" works fine, including dumping databases generated by libloc 0.9.11. Apologies for any inconvenience caused. Thanks, and best regards, Peter Müller

1 0

libloc 0.9.11 released
by Michael Tremer 03 Mar '22

03 Mar '22

Hello, This is the release announcement for libloc 0.9.11. It comes with the following changes: Most changes are around the exporter, which is now able to write any output to the console. This is useful when you want to load a custom list of countries or ASes directly into ipset or nftables like so: root@michael:/build/libloc# location -d /var/lib/location/database.db export --format=nftables --family=ipv6 AS204867 VA define VAv6 = { 2a01:b8::/32, 2a01:84a0:2000::/40, 2a04:640::/29, 2a06:9f80::/29, 2a06:a005:4::/48, 2a07:8100::/29, 2a09:4c0:f100::/40, 2a0e:b101:f100::/40, 2a0e:b107:aef::/48, 2a0e:b107:1000::/44, 2a0f:b9c1:100::/46, 2a0f:b9c1:10e::/48, } define AS204867v6 = { 2001:678:b28::/48, } This command lists all sets that belong to AS204867 or VA in the desired format. In order to increase performance, we will now no longer “flatten” the tree for ipset and nftables, because those formats can handle overlapping networks. xt_geoip on the other hand needed a list of non-overlapping, sorted IP networks, which causes a lot of extra work to convert the data from the database into this format. The names of the sets have been already for ipset and nftables. For a country XX, the sets are now called XXv6 and XXv4 for IPv6 and IPv4 respectively. The same schema applies to autonomous systems, e.g.: AS204867v6 AS204867v4. This change was required because sets cannot mix IPv6 and IPv4 addresses and it is desirable to use both. For ipset, the parameters that create a set have been changed: * The maximum size of each set is set to 1 million. We used to hard-code 64k, which was exceeded by a couple of countries, and setting it to the actual size of a set didn’t allow to reload a set in ipset without destroying the format set first. For that reason, we set this to a maximum that nobody should ever reach. * The hashsize used to be set to 1024 which is the default for ipset. However, this creates a performance problem for large sets when the system spends a lot of time searching through linked lists. To avoid that, we increase the size of the hash table aiming for a fill-factor of 0.75 which should make any lookup fast. This comes at the cost of slightly increased memory usage. See the commit messages for more details. Misc. * The LACNIC parser introduced in the previous release has been fixed and should not be able to parse all IP addresses correctly Thank you to everyone who has contributed to this release. You can find the source here: https://git.ipfire.org/?p=location/libloc.git;a=shortlog;h=refs/tags/0.9.11 https://source.ipfire.org/releases/libloc/libloc-0.9.11.tar.gz Best, -Michael

1 0

[PATCH] location-importer: Fix parsing LACNIC-flavoured inetnums
by Peter Müller 02 Mar '22

02 Mar '22

My fault, again. :-/ Reported-by: Michael Tremer <michael.tremer(a)ipfire.org> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- src/python/location-importer.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/python/location-importer.in b/src/python/location-importer.in index 83fb5c7..fe13482 100644 --- a/src/python/location-importer.in +++ b/src/python/location-importer.in @@ -3,7 +3,7 @@ # # # libloc - A library to determine the location of someone on the Internet # # # -# Copyright (C) 2020-2021 IPFire Development Team <info(a)ipfire.org> # +# Copyright (C) 2020-2022 IPFire Development Team <info(a)ipfire.org> # # # # This library is free software; you can redistribute it and/or # # modify it under the terms of the GNU Lesser General Public # @@ -691,9 +691,9 @@ class CLI(object): # How many octets do we need to add? # (LACNIC does not seem to have a /8 or greater assigned, so the following should suffice.) - if ldigits == 2: + if ldigits == 1: start_address = start_address[0] + ".0.0/" + start_address[1] - elif ldigits == 3: + elif ldigits == 2: start_address = start_address[0] + ".0/" + start_address[1] else: log.warning("Could not recover IPv4 address from line in LACNIC DB format: %s" % line) -- 2.34.1

2 3

2024

2023

2022

2021

2020

2019

2018

2017

Location March 2022