network unreachable error in http tests

[Jose A. Ortega Ruiz]

hi,

i'm on a debian sid box with a live connection to internet through DSL
that has no issue with any network program or operation i've tried.
however, when all.bash runs the http tests (for a release checkout of
the go source tree), i get the following error:

make[2]: Leaving directory `/home/jao/src/go/src/pkg/http'
--- FAIL: http.TestClient
Get http://www.google.com/robots.txt: dial tcp
www.google.com:http: dial udp 80.58.61.254:53: network is
unreachable
--- FAIL: http.TestRedirect
Get http://codesearch.google.com/: dial tcp
codesearch.google.com:http: dial udp 80.58.61.254:53: network is
unreachable
FAIL

in case that matters, my GOARCH is 386.

any ideas about what could be wrong with my setup?

tia,
jao

[Andrew Gerrand]

On 2 March 2010 04:35, Jose A. Ortega Ruiz <jaor...@gmail.com> wrote:
>  --- FAIL: http.TestClient
>          Get http://www.google.com/robots.txt: dial tcp
>          www.google.com:http: dial udp 80.58.61.254:53: network is
>          unreachable
>  --- FAIL: http.TestRedirect
>          Get http://codesearch.google.com/: dial tcp
>          codesearch.google.com:http: dial udp 80.58.61.254:53: network is
>          unreachable

These errors suggest an issue performing the DNS look-ups for
www.google.com and codesearch.google.com. (UDP port 53 is DNS) Is your
/etc/resolv.conf configured with a functioning nameserver? When you
ping www.google.com, does the name resolve to an IP address correctly?

Andrew

[Jose Antonio Ortega Ruiz]

Hi Andrew,

Andrew Gerrand <a...@google.com> writes:

This is what i get:

[/home/jao]$ ping www.google.com
PING www.l.google.com (209.85.229.106) 56(84) bytes of data.
64 bytes from ww-in-f106.1e100.net (209.85.229.106): icmp_seq=1 ttl=53
time=79.6 ms
64 bytes from ww-in-f106.1e100.net (209.85.229.106): icmp_seq=2 ttl=53
time=88.6 ms
64 bytes from ww-in-f106.1e100.net (209.85.229.106): icmp_seq=3 ttl=53
time=87.6 ms

Looks OK, no?

Thanks a lot!
jao

[Jan Hosang]

I'm having the same issue with debian sid on amd64. I also noticed
that I have no problems connecting to servers (via tcp) with C while
go fails with the same message. When I try on darwin from the same
network everything works fine.

I'm seeing a similar error with java which I can fix by passing "-
Djava.net.preferIPv4Stack=true". I don't know if those two might be
related.

Jan

On Mar 2, 12:25 am, Andrew Gerrand <a...@google.com> wrote:
> On 2 March 2010 04:35, Jose A. Ortega Ruiz <jaort...@gmail.com> wrote:
>
> >  --- FAIL: http.TestClient
> >          Gethttp://www.google.com/robots.txt:dial tcp

> >          www.google.com:http:dial udp 80.58.61.254:53: network is
> >          unreachable
> >  --- FAIL: http.TestRedirect

> >          Gethttp://codesearch.google.com/:dial tcp

> >          codesearch.google.com:http: dial udp 80.58.61.254:53: network is
> >          unreachable
>

> These errors suggest an issue performing the DNS look-ups forwww.google.comand codesearch.google.com. (UDP port 53 is DNS) Is your

> /etc/resolv.conf configured with a functioning nameserver? When you

> pingwww.google.com, does the name resolve to an IP address correctly?
>
> Andrew

[jamil]

try this:

To do this, search for NOTEST in $GOROOT/src/pkg/Makefile and add
entries “http\” and “net\” to the end, using tabs for the indentation.
The complete list should look like the following when complete:
NOTEST=\
debug/proc\
exp/draw\
go/ast\
go/doc\
go/token\
hash\
image\
image/jpeg\
malloc\
rand\
runtime\
syscall\
testing/iotest\
xgb\
http\
net\

Ref: http://jaysonlorenzen.wordpress.com/2010/01/31/install-the-go-programming-language-using-a-proxy/

On Mar 1, 10:35 pm, "Jose A. Ortega Ruiz" <jaort...@gmail.com> wrote:
> hi,
>
> i'm on a debian sid box with a live connection to internet through DSL
> that has no issue with any network program or operation i've tried.
> however, when all.bash runs the http tests (for a release checkout of
> the go source tree), i get the following error:
>
>   make[2]: Leaving directory `/home/jao/src/go/src/pkg/http'
>   --- FAIL: http.TestClient

>           Gethttp://www.google.com/robots.txt:dial tcp

>          www.google.com:http:dial udp 80.58.61.254:53: network is
>           unreachable
>   --- FAIL: http.TestRedirect

>           Gethttp://codesearch.google.com/:dial tcp

[Jose A. Ortega Ruiz]

jamil <jamil...@gmail.com> writes:

> try this:
>
> To do this, search for NOTEST in $GOROOT/src/pkg/Makefile and add
> entries “http\” and “net\” to the end, using tabs for the indentation.
> The complete list should look like the following when complete:
> NOTEST=\
> debug/proc\
> exp/draw\
> go/ast\
> go/doc\
> go/token\
> hash\
> image\
> image/jpeg\
> malloc\
> rand\
> runtime\
> syscall\
> testing/iotest\
> xgb\
> http\
> net\

Thanks, jamil, that definitely helps, in that it sidesteps the tests
that are failing in my system and allows the build to succeed. I'm still
curious about what's causing the DNS problems in my apparently dandy
network setup--i guess i'll have to write some networking code on my own
and test further.

Cheers,
jao

[Andrew Gerrand]

On 3 March 2010 14:44, Jose A. Ortega Ruiz <jaor...@gmail.com> wrote:
>
> Thanks, jamil, that definitely helps, in that it sidesteps the tests
> that are failing in my system and allows the build to succeed. I'm still
> curious about what's causing the DNS problems in my apparently dandy
> network setup--i guess i'll have to write some networking code on my own
> and test further.

Your help would be much appreciated, especially as the issue has been
corroborated by another Debian sid user. As I'm sure you can
understand, we have limited resources when it comes to testing a
variety of systems.

Andrew

[Scott Schwartz]

This is caused because debian supports ipv6, but doesn't
(at least in my out-of-the-box case) set up any useful routes beyond the link
local ones.

Go is assuming (see net/ipsock.go) that it can
pass ipv4 addresses to the ipv6 interface.
Apparently that's not true in this case, even
though debian does have ipv6 support in the kernel.

Setting preferIPv4 to true makes the tests pass for me.

It's possible that setting up the right ipv6 routes would
fix this too.

(Running the tests in net before the ones in http makes
the real location of the problem more obvious.)

> --- FAIL: http.TestClient
> Get http://www.google.com/robots.txt: dial tcp

> www.google.com:http: dial udp 80.58.61.254:53: network is
> unreachable
> --- FAIL: http.TestRedirect

> Get http://codesearch.google.com/: dial tcp

[Jose A. Ortega Ruiz]

Scott Schwartz <sco...@golang.org> writes:

> This is caused because debian supports ipv6, but doesn't
> (at least in my out-of-the-box case) set up any useful routes beyond the link
> local ones.
>
> Go is assuming (see net/ipsock.go) that it can
> pass ipv4 addresses to the ipv6 interface.
> Apparently that's not true in this case, even
> though debian does have ipv6 support in the kernel.
>
> Setting preferIPv4 to true makes the tests pass for me.

Sorry, i haven't had time to look at this closely, but setting
preferIPv4 to true here fixes the http tests but not the net ones (i'm
using the latest release): for those to pass i had to change all calls
to kernelSupportsIPv6() to !preferIPv4.

I'll try to find out how to configure debian so that the ipv6 i/f
accepts v4 addresses.

Thanks,
jao

[stevie]

Got the same problem - also on Debian Squeeze.

The simplest workaround is to make kernelSupportsIPv6() return false.

[Grzegorz Żur]

The same happens on my Debian and I found out there is a bug number
560056 on it.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056

The best solution is setting net.ipv6.bindv6only to 0 by
sysctl -w net.ipv6.bindv6only=0
and modifying the same way file
/etc/sysctl.d/bindv6only.conf
so it is preserved after restart.

This fixes both Go tests and Java networking.

--
Grzegorz Żur

[Torsten Werner]

On 12 Mrz., 11:25, Grzegorz Żur <grzegorz....@gmail.com> wrote:
> The best solution is setting net.ipv6.bindv6only to 0 by
>   sysctl -w net.ipv6.bindv6only=0
> and modifying the same way file
>   /etc/sysctl.d/bindv6only.conf
> so it is preserved after restart.

The best solution is using the openjdk-6-jre >= 6b18~pre1-4.

Torsten