net,net/http,crypto/tls: some tests fail if network addresses have been translated

[laboger]

What version of Go are you using (go version)?

$ go version
go version devel +14a133f Tue Nov 5 21:16:50 2019 +0000 linux/ppc64le
go version go1.13 gccgo (GCC) 10.0.0 20191105 (experimental) linux/ppc64le

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

linux/ppc64le power8

What did you do?

Trying to run the golang and gccgo tests for net, net/http, and crypto/tls on a system where someone had done network address translation. See below for example of how it could be reproduced.

What did you expect to see?

PASS

What did you see instead?

~/golang/plain/go/src/net$ ./net.test 
--- FAIL: TestConnAndPacketConn (0.50s)
    packetconn_test.go:152: read udp 127.0.0.1:37440->127.0.0.1:38376: i/o timeout
--- FAIL: TestUDPServer (110.09s)
    server_test.go:320: #0: read udp 127.0.0.1:39312: i/o timeout
    server_test.go:320: #1: read udp 127.0.0.1:34202: i/o timeout
    server_test.go:320: #2: read udp 127.0.0.1:44195: i/o timeout
    server_test.go:320: #7: read udp 127.0.0.1:51421: i/o timeout
    server_test.go:320: #8: read udp4 127.0.0.1:53997: i/o timeout
    server_test.go:320: #9: read udp4 127.0.0.1:58202: i/o timeout
    server_test.go:320: #10: read udp4 127.0.0.1:55888: i/o timeout
    server_test.go:320: #15: read udp4 127.0.0.1:36888: i/o timeout
    server_test.go:320: #19: read udp4 127.0.0.1:37530: i/o timeout
    server_test.go:320: #20: read udp4 127.0.0.1:50267: i/o timeout
    server_test.go:320: #21: read udp4 127.0.0.1:57797: i/o timeout
FAIL

~/golang/plain/go/src/net/http$ ./http.test
--- FAIL: TestSetsRemoteAddr_h1 (0.00s)
    serve_test.go:1248: Expected local addr; got "9.40.192.157:50248"
--- FAIL: TestSetsRemoteAddr_h2 (0.01s)
    serve_test.go:1248: Expected local addr; got "9.40.192.157:42918"
FAIL

~/golang/plain/go/src/crypto/tls$ ./tls.test
--- FAIL: TestDynamicRecordSizingWithStreamCipher (5.00s)
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38236 != 127.0.0.1:38236
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38236
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38238 != 127.0.0.1:38238
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38238
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38240 != 127.0.0.1:38240
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38240
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38242 != 127.0.0.1:38242
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38242
    handshake_test.go:287: localPipe: unexpected connection: 9.40.192.157:38244 != 127.0.0.1:38244
    handshake_test.go:279: localPipe: timeout waiting for 127.0.0.1:38244
    handshake_test.go:293: localPipe: failed to connect: <nil>
..... lots more

We found that doing something like this

sudo iptables -t nat -A POSTROUTING -j MASQUERADE

Will result in these failures and then this

sudo iptables -t nat -F POSTROUTING

makes it work again.

Fails on this system in the same way in gccgo and golang. Doesn't fail on systems with normal network address settings.

[bcmills]

CC @mikioh @bradfitz @FiloSottile

[laboger]

I thought if there was a way to determine if the network mappings were not the usual default, then just skip the test. I could test it with some suggestions on how to check for that.