Wow, this is getting to be a very useful tool.
thanks for all the work. I look forward to the port..
On 4/08/2016 5:53 AM, Dr. Rolf Jansen wrote:
Am 03.08.2016 um 11:13 schrieb Julian Elischer <[email protected]>:
On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote:
Am 02.08.2016 um 05:08 schrieb Julian Elischer <[email protected]>:
looking for thoughts from people who know the new IPFW features well..
A recent addition to our armory is the geoip program that, given an address can
tell you what country it is in and given a country code, can give an ipfw table
that describes all the ip addresses in that country.
SO I was thinking how to use this, and the obvious way would be to have a set of rules
for each country, and use the "skipto tablearg" facility to skip to the right
rules for each country. But the trouble is that a tablearg skipto is very inefficient.
It's also a hard thing to set up with a set of rules for each country (how many countries
are there in the internet allocation system?).
As of today a total of 236 country codes are in use for IPv4 delegations. If
this helps for anything, a command line switch to the geoip tool could be added
for letting it output the country code (as the hex encoded CC taken as a plain
decimal integer) as the value for the given table entry. In the moment you can
give one value for all entries generated by geoip, with this switch set, the
output of geoip could look like:
$ geoip -t "DE:BR:US" -x
...
table 0 add 93.157.48.0/21 4445
table 0 add 93.158.236.0/22 4252
table 0 add 93.159.96.0/19 4445
table 0 add 93.159.248.0/21 4445
table 0 add 93.180.72.0/21 4445
table 0 add 93.180.152.0/21 4445
table 0 add 93.181.0.0/18 4445
table 0 add 93.183.0.0/18 5553
...
Given that ...
0x4445 = 'DE'
0x4252 = 'BR'
0x5553 = 'US'
well it would have to be the decimal value so DE would be 6869, as while 4445
works 444F is a problem :-)
Yes, you're right, I was taken away by the wave of enthusiasm, before thinking
about the subject up to the end.
0x444F would work but we waste even more address space. You'd have to multiply
the numbers by some scaler, because adjacent numbers would not be enough for
one rule to do something and another rule to skip on to somewhere else. (well,
you could have multiple rules at the same number but that has its limitations.
The idea would certainly work. it would mean setting aside all the rules
between 6565 and 9090 however.
A more compact encoding could be something like ((name[0]-'A') *
32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and offset
by a given offset.
so AF (Afghanistan) would be the first 0*32+5 * 10 would give an offset of
50.. plus a user supplied offset turns it into say, 15050..
I understand the reasons, however, any complicated encoding will defeat the
idea of the value can be sort of numeric mnemonic for the country code – well,
so it is. I elaborated on your idea and came-up with the following formula:
val = (C1-60)*1000 + C2*10 + offset. The offset can be given as the parameter
to the -x flag.
$ geoip -t "DE:BR:US" -4 -x 30000
...
table 0 add 93.157.48.0/21 38690
table 0 add 93.158.236.0/22 36820
table 0 add 93.159.96.0/19 38690
table 0 add 93.159.248.0/21 38690
table 0 add 93.180.72.0/21 38690
table 0 add 93.180.152.0/21 38690
table 0 add 93.181.0.0/18 38690
table 0 add 93.183.0.0/18 55830
...
The limits (without offset) are:
AA = 5650 -- actually AD = 5680
ZZ = 30900
With this formula, the offset must be less than 34735. Although, this wastes a
considerable amount of rule number space, the advantage is that the numbers are
still accessible by mental arithmetic, and the other constraint of having a step
> 1 is fulfilled as well. Anyway, this one is not graved in stone, we can agree
on another one.
or there could be a translation into iso3166 numeric codes where Afghanistan is
004, but then you have the worry of keeping the data up to date as they add new
country codes, which in my opinion makes it a bad solution.
Agreed, too much dependencies, let's forget the numeric iso codes.
BTW: The ipdb tools are now IPv6 aware.
$ geoip 2001:1900:2254:206a::50:5
2001:1900:2254:206a::50:5 in 2001:1900:0:0:0:0:0:0 -
2001:1900:ffff:ffff:ffff:ffff:ffff:ffff in US
$ geoip -t "DE:BR:US" -p
...
...
217.194.64.0/20
217.194.224.0/20
217.195.0.0/20
217.195.32.0/20
217.197.80.0/20
217.198.128.0/20
217.198.240.0/20
217.199.64.0/20
217.199.192.0/20
217.224.0.0/11
2001:400:0:0:0:0:0:0/32
2001:408:0:0:0:0:0:0/32
2001:418:0:0:0:0:0:0/32
2001:420:0:0:0:0:0:0/32
2001:428:0:0:0:0:0:0/32
2001:430:0:0:0:0:0:0/32
2001:438:0:0:0:0:0:0/32
...
...
$ geoip -t "" -p | wc -l
137097
For processing only IPv4 addresses, add the -4 switch (this reproduces the old
behaviour)
$ geoip -4 -t "" -p | wc -l
106637
For processing only IPv6 addresses, add the -6 switch
$ geoip -6 -t "" -p | wc -l
30460
106637+30460 = 137097
After running 'make install' of the new version, the IP database needs to be
updated using the ipdb-update.sh script. This will now generate two binary
database files (*.v4 and *.v6).
Best regards
Rolf
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
