Bug#505736: updated webgeo2ipct.pl

2008-11-16 Thread gregor herrmann
On Sat, 15 Nov 2008 22:31:31 +0100, Claus Herwig wrote:

 | Now I'm not sure what to do:
 umh, this is certainly non-trivial on second thoughts.

:)
 
 What I've found when trying to figure it out:

Thanks alot for taking the time to do this analysis, much
appreciated.
 
 Does it work with awstats anyway? Yes, it does.

That's good to know.

 Does it break handling of local IPs?
 I wouldn't say so, because handling of local IPs is more or less
 incorrect with the old version anyway. 

Agreed.

 What to do?
 I would support your first solution. Patch the test, document the
 changes, forget about the obscure special cases mentioned in these
 iana/ietf documents.

Good, if noone else objects I will take this route.
 
Cheers,
gregor
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Paul Mc Cartney: Talk More Talk


signature.asc
Description: Digital signature


Bug#505736: updated webgeo2ipct.pl

2008-11-15 Thread Claus Herwig
As per request I just updated webgeo2ipct.pl to include a license 
comment. New file is attached.


webgeo2ipct-new.tar.gz
Description: Binary data


Bug#505736: updated webgeo2ipct.pl

2008-11-15 Thread gregor herrmann
On Sat, 15 Nov 2008 15:53:10 +0100, Claus Herwig wrote:

 As per request I just updated webgeo2ipct.pl to include a license  
 comment. New file is attached.

Thanks alot, committed to our subversion repository.


There's one other issue where you maybe could help:

With the new database the test script fails because some IP ranges
change. No surprise so far. The failures can be seen in a patch I
prepared:

#v+

--- a/test.pl
+++ b/test.pl
@@ -9,12 +9,12 @@
 # localhost
 
 my ($country,$country_name,$ip) = Geo::IPfree::LookUp(127.0.0.1) ;
-ok($country,'L0');
+ok($country,'ZZ');
 
 # intranet
 
 my ($country,$country_name,$ip) = Geo::IPfree::LookUp(10.0.0.1) ;
-ok($country,'I0');
+ok($country,'ZZ');
 
 # www.nic.br
 
@@ -29,7 +29,7 @@
 # www.nic.fr
 
 my ($country,$country_name,$ip) = Geo::IPfree::LookUp(192.134.4.20) ;
-ok($country,'FR');
+ok($country,'EU');
 
 #
 

#v-

The interesting failures are the first 2 ones:
AFAICS the new database returns ZZ for all IANA reserved addresses
(42 entries).

The old database seems to have different values for some private/RFC 1918
addresses; I've converted the old database with ipct2txt.pl into text
format and found the following lines (without guarantee of
completeness):

#v+

I0: 10.0.0.0 10.255.255.255
L0: 127.0.0.0 127.255.255.255
I0: 192.168.0.0 192.168.255.255

#v-

(172.16/12 is wrongly attributed ...)

Now I'm not sure what to do:
* leave IpToCountry.csv as it is, patch the test, and document the
  changed return value in NEWS.Debian maybe;
  might be problematic if applications rely on I0/L0 for local
  address space (and that's the real concern with this change);
  in the Debian archive awstats is the only reverse dependency for
  libgeo-ipfree-perl (as a Suggests, and I can't find L0 or I0 in the
  code), but still ...
* patch the three relevant lines in IpToCountry.csv to return the
  old values; no big deal, helps old applications but leads to
  inconsistent return values for IANA reserved addresses


Since I don't find any traces of the old return values in code in
Debian at the first glance I tend to take the first option.


Any suggestions appreciated.


Cheers,
gregor
  
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Don McLean: Fool's Paradise


signature.asc
Description: Digital signature


Bug#505736: updated webgeo2ipct.pl

2008-11-15 Thread Claus Herwig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

gregor herrmann wrote:

| There's one other issue where you maybe could help:
|
| With the new database the test script fails because some IP ranges
| change. No surprise so far. The failure

| Now I'm not sure what to do:

umh, this is certainly non-trivial on second thoughts.

What I've found when trying to figure it out:

Does it break general backward compatibility? Yes, it does.
- - Unassigned IPs: old --, new database treats them (mostly) as
belonging to the last preceding assigned IP range.
- - IANA reserved IPs: old --, US or I0, L0 (as you mentioned),
new ZZ
- - some new ccTLDs: RS (serbia), ME (montenegro) for example

Does it work with awstats anyway? Yes, it does.
- - ZZ gets reported properly on its own line as unknown
- - RS and ME get listed as unknown, each on their own line
- - awstats could list I0 (not L0) as local network host (this is in
/usr/share/awstats/lib/domains.pm).

Does it break handling of local IPs?
I wouldn't say so, because handling of local IPs is more or less
incorrect with the old version anyway. 172.16.0.0/12 and a lot of other
special blocks are wrong/missing in the old database. See
http://tools.ietf.org/html/rfc3330#section-3
http://www.iana.org/assignments/ipv4-address-space
for details.

What to do?
I would support your first solution. Patch the test, document the
changes, forget about the obscure special cases mentioned in these
iana/ietf documents.

Of course, a more satisfying solution could be to patch the
webgeo2ipct.pl to distinguish between the different types of reserved IP
ranges (private use, loopback, link local, multicast...) correctly and
to recognize unallocated space properly. But this still wouldn't be
backward compatible or improve compatibility with awstats. And honestly,
I doubt that it would be real useful to anybody ;-)

Greets,
~  Claus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkfP7MACgkQ6ycKQKeqYcGHEwCg1H4MKj/IaPFAUIaVem5daBmn
QP4AoPIhx+uzREc58M1ktDXt6NhnXB8l
=JMCO
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]