Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
laboger opened this issue Nov 5, 2019 · 2 comments

Comments

@laboger
Copy link
Contributor

@laboger laboger commented Nov 5, 2019

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 bcmills added this to the Backlog milestone Nov 6, 2019
@bcmills bcmills added the help wanted label Nov 6, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Nov 6, 2019

@laboger

This comment has been minimized.

Copy link
Contributor Author

@laboger laboger commented Nov 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.