The Perl script that builds the GeoIP DBs uses inet_pton(3) to convert
the addresses to network byte order. This converts
"1234:5678::90ab:cdef"
to:
0x12 0x34 0x56 0x78 .. 0xcd 0xef, interpreted by an LE machine
accessing this in uint32_t-sized chunks as
8765:4321::fedc:ba09
The kernel module compares the addresses in packets with the ranges from
the DB in host byte order using binary search. It uses 32-bit swaps
when converting the addresses.
libxt_geoip, however, which the module uses to load the ranges from the
DB and convert them from NBO to HBO, uses 16-bit swaps to do so, and
this means that:
1234:5678::90ab:cdef
becomes:
4321:8765::ba09:fedc
Obviously, this is inconsistent with the kernel module and DB build
script and breaks the binary search.
Fixes: b91dbd03c7 ("geoip: store database in network byte order")
Reported-by: "Thomas B. Clark" <kernel@clark.bz>
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
This allows a single database to be built and distributed as a
package that is accepted by both big- and little-endian hosts.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Make both instances of the same message (about invalid country codes)
be consistent with each other. If you have scripts which capture and
collate error messages, then having consistent strings to match against
is a win.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Users still using a kernel with POM modules may have problems due to
differing binary structures. Bump the revision numbers of the
Xtables-addons modules, to make them distinct from POM.
The old database format was in unknown byteorder -- if you run the
converter program yourself, you got a host order file, but if you
downloaded the preprocessed DB file (geoipdb.bin), you got a
little-endian file.
Use a new database format. Instead of having an index and a DB file,
do away with the index and let the filesystem do the indexing, using
one file per country. Also access the database files with a known
endianess type. The converter script now produces two distinct
variants (especially needed for IA-64).
All of this reduces the touched code by half.
A 64-bit kernel will interpret the pointer with 64 bits width, while
a 32-bit userspace filled in only 32 of it, leaving the other 32
undefined. This must be avoided.
