Here's the output you requested: heroin:~ # netselect -I -vv -s 1 www.google.com Running netselect to choose 1 out of 6 addresses.
74.125.115.105 9999 ms 30 hops 0% ok 74.125.115.104 9999 ms 30 hops 0% ok 74.125.115.103 9999 ms 30 hops 0% ok 74.125.115.99 9999 ms 30 hops 0% ok 74.125.115.147 9999 ms 30 hops 0% ok 74.125.115.106 9999 ms 30 hops 0% ok heroin:~ # netselect -vv -s 1 www.google.com Running netselect to choose 1 out of 6 addresses. ........................................................................ 74.125.115.106 44 ms 13 hops 100% ok (10/10) [ 101] 74.125.115.105 43 ms 13 hops 100% ok (10/10) [ 98] 74.125.115.104 45 ms 13 hops 100% ok (10/10) [ 103] 74.125.115.103 45 ms 13 hops 100% ok (10/10) [ 103] 74.125.115.99 44 ms 13 hops 100% ok (10/10) [ 101] 74.125.115.147 44 ms 13 hops 100% ok (10/10) [ 101] 98 74.125.115.105 Looks like the ping method is broken from here. I saw that you made another release, it doesn't seem to have hit any of the mirrors I've tried so far. I will upgrade once it becomes available (in perhaps the standard ten days), and I will report back. On Tue, Jun 7, 2011 at 17:42, Javier Fern?ndez-Sanguino Pe?a <j...@computer.org> wrote: > On Wed, Jun 01, 2011 at 11:13:37AM -0500, Trey Blancher wrote: >> As far as I know, I'm not experiencing any general networking issues, >> both ping and traceroute to google com return as expected. Here's the >> raw netselect command I ran (hosts.test should be the contents of the >> $hosts shell variable): > (....) >> Note there is no actual selection of a mirror. I did a quick scan of >> the entire output, and it appears that all of the hosts tested have >> the same results (i.e. 9999ms 30 hops 0% ok), even after netselect >> seems to cycle through the list at least twice. It's as if netselect >> is not doing either ping or traceroute correctly (as if it's trying a >> hybrid approach?), and totally failing silently. As an added bonus, > (...) > > This is weird, since you are using -I you are telling netselect to just use > ICMP probes (not UDP) which should work with most Debian servers (some > actually do block traceroute probes). > > Please try to run (as root) this: 'netselect -I -vv -s 1 www.google.com'. > > Questions: > - Do you get the same results? (i.e. 9999ms) > - What happens if you drop the -I call? Any change? > - Do you see any logs in your kernel's message log when netselect is run? > (Check dmesg) > - Is there any filtering device between your system and the Internet? > > On the one hand, netselect-apt is not handling properly the case when > netselect does not find any suitable server (see bug #238888, #420252) and, on > the other hand, netselect does not seem to work in your environment. > > The first issue I can fix, the second one I cannot unless I get more > information from you. > > Regards > > Javier > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
