github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh.(*connectionMaker).connectionTerminated.func1(0xc8223f1f08)
/go/src/github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh/connection_maker.go:195 +0x103
github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh.(*connectionMaker).queryLoop(0xc820014c60, 0xc820014c00)
/go/src/github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh/connection_maker.go:224 +0xf4
created by github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh.newConnectionMaker
/go/src/github.com/weaveworks/weave/vendor/github.com/weaveworks/mesh/connection_maker.go:74 +0x24a
The problem is in mesh.localPeer.createConnection. The connectionMaker has the target address as "0.0.0.0:6783", which is what it passes to that function as the peerAddr. We re-parse that into remoteTCPAddr with net.ResolveTCPAddr, which has the same string representation. So far so good. But then we initialise the remoteConnection data structure in newRemoteConnection() with a remoteTCPAddr of tcpConn.RemoteAddr().String(). That actually returns "127.0.0.1:6783". I've traced the origin of that to a syscall.Getpeername() in the go socket code.
AFAICT the code has always been like that. The obvious fix is to invoke newRemoteConnection() with peerAddr instead.
Discovered in weaveworks/weave#2527...
weave launch 0.0.0.0producesThe problem is in mesh.localPeer.createConnection. The connectionMaker has the target address as "0.0.0.0:6783", which is what it passes to that function as the peerAddr. We re-parse that into remoteTCPAddr with net.ResolveTCPAddr, which has the same string representation. So far so good. But then we initialise the remoteConnection data structure in newRemoteConnection() with a remoteTCPAddr of tcpConn.RemoteAddr().String(). That actually returns "127.0.0.1:6783". I've traced the origin of that to a
syscall.Getpeername()in the go socket code.AFAICT the code has always been like that. The obvious fix is to invoke newRemoteConnection() with peerAddr instead.