On Sat, Dec 08, 2007 at 10:09:37AM +0100, Peter Palfrader wrote:
> > [0] http://lists.debian.org/debian-ctte/2007/09/msg00049.html
> I'm a bit confused by this code or rather its result, mainly because it
> seems that on all the etch hosts I tried it the results are distributed
> (even if not evenly) over the set of IP addresses, yet this discussion
> suggests that etch is affected by the Rule 9 issue.
> | weasel@albeniz:~$ python
> | >>> print dict([ (l, k.count(l)) for l in k ])
> | {'144.144.144.144': 66, '64.64.64.64': 67, '160.160.160.160': 66,
> | '224.224.224.224': 134, '208.208.208.208': 67, '96.96.96.96': 67,
> | '112.112.112.112': 66, '128.128.128.128': 67, '176.176.176.176': 67,
> | '80.80.80.80': 66, '48.48.48.48': 67, '192.192.192.192': 66,
> | '16.16.16.16': 67, '32.32.32.32': 67}
That looks like you're getting the 224 address showing up twice, which seems
odd too. On an etch system with a 192.168 address, I get:
python <<EOF
import socket
k = [ socket.getaddrinfo("rule9.erisian.com.au", "http")[0][4][0] for blah in range(1000) ]
print dict([ (l, k.count(l)) for l in k ])
EOF
{'192.192.192.192': 1000}
It's 64 bit, with:
ii libc6 2.3.6.ds1-13etch4
ii python 2.4.4-2
ii python2.4 2.4.4-3
and afaik no special configuration otherwise.
(If rule9 weren't affecting a majority of etch systems, it certainly
wouldn't have been affecting Debian system's choice of OFTC servers in
early 2006 afaics...)
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature