Date: Fri, 29 Jul 2016 10:23:35 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: freebsd-ipfw@freebsd.org Cc: Julian Elischer <julian@freebsd.org> Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> In-Reply-To: <c62fa048-63c8-aef6-5bad-b0a6719f6acb@freebsd.org> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <CAHu1Y739PvFqqEKE74BjzgLa7NNG6Kh55NPnU5MaA-8HsrjkFw@mail.gmail.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <c2cd797d-66db-8673-af4e-552dfa916a76@freebsd.org> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <C0CC7001-16FE-40BF-A96A-1FA51A0AFBA7@obsigna.com> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <CAFPNf59w6BHgDjLNHW=rQckZAFG4gqPHL49vLXiDmMAxVPOcKg@mail.gmail.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <c62fa048-63c8-aef6-5bad-b0a6719f6acb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 29.07.2016 um 06:50 schrieb Julian Elischer <julian@freebsd.org>: > On 29/07/2016 5:22 PM, Julian Elischer wrote: >> On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: >>>> Am 28.07.2016 um 23:48 schrieb Lee Brown <leeb@ratnaling.org>: >>>>=20 >>>> That makes sense to me. Your /20 range encompasses 201.222.16.0 - >>>> 201.222.31.255. >>>> If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges: >>>>=20 >>>> 201.222.20.0/22 (201.222.20.0-201.222.23.255) >>>> 201.222.24.0/22 (201.222.24.0-201.222.27.255) >>>> 201.222.28.0/22 (201.222.28.0-201.222.31.255) >>>=20 >>> Ian, Julian and Lee, >>>=20 >>> Thank you vary much for your responses. In order not bloat the = thread, I answer only to one message. >>>=20 >>> I found the problem. As a matter of fact, the respective IP ranges = in the LACNIC delegation statistics file are 3 adjacent blocks with 1024 = addresses, i.e. those that you listed in your message above: >>>=20 >>> $grep 201.222.2 /usr/local/etc/ipdb/IPRanges/lacnic.dat >>> lacnic|BR|ipv4|201.222.20.0|1024|20140710|allocated|164725 >>> lacnic|BR|ipv4|201.222.24.0|1024|20140630|allocated|138376 >>> lacnic|BR|ipv4|201.222.28.0|1024|20140701|allocated|129095 >>>=20 >>> However, my database compilation combines adjacent blocks with the = same country code, and the ranges above turn into one block of 3072 = addresses, which obviously doesn't have a valid netmask - log(3072) =3D = 11,5849625. >>> ... >>> ..., it is not sufficient to forget about optimization but I need to = check also whether, the delegation files contain already some non-CIDR = ranges, which need to be broken down. >>=20 >> there is code to take ranges and produce cidr sets. >>=20 >> We used to have exactly that code in the appletalk code before we = took it out. Appletalk uses ranges. >> = https://svnweb.freebsd.org/base/release/3.2.0/sys/netatalk/at_control.c?vi= ew=3Dannotate#l703=20 >=20 > though htat uassumes input in the form af an appletak sockaddr.. > there is also this python module > = https://pythonhosted.org/netaddr/tutorial_01.html#support-for-non-standard= -address-ranges >=20 >> maybe you can find other versions on the net. >> however if you fully populate the table, you will get the correct = result because more specific entries will >> override less specific entries. To do that you would have to have a = way to describe to your program what >> value each table entry should output. >> If you did what you do now, then you would specify the value for the = required countries, and give a default falue for "all others". >> aggregation of adjacent ranges with same value would be an = optimisation. Don't worry, breaking down an arbitrary IP-range into a CIDR conforming = set of ranges, doesn't seem too difficult. I quickly hacked into the = for() loop for table generation in geoip.c a nested do while() for if = necessary breaking down the given range: for (i =3D 0; i < n; i++) { if (!*ccList || findCC(CCTable, sortedIPSets[i][2])) { ipv4_lo =3D sortedIPSets[i][0]; do { m =3D intlb(sortedIPSets[i][1] - ipv4_lo + 1); while (ipv4_lo % (k =3D (int)lround(exp2(m)))) m--; printRange(ipv4_lo, 32 - m, table_number, table_value); = =20 } while ((ipv4_lo +=3D k) < sortedIPSets[i][1]); } } This seems to work as expected, however, I need to check this more = carefully (in the course of the weekend) until pushing it to GitHub. At = the first glance, the tables become quite large. For example, the table = for Brazil of 824 joined entries is bloated to 6621 CIDR records. Once I came to a conclusion, I will post it to this mailing list. Best regards Rolf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9222BB10-C700-4DE7-83A3-BE7A38A11713>