net.Conn.RemoteAddr() platform dependent return question

[pchris...@iparadigms.com]

Hi Y'all,

     Wondering if someone can give me some color (including if this Q would be more appropriately aimed at a different email-list). What I'm seeing is that net.Conn.RemoteAddr().String() returns strange results on the Mac platform, when the connection is made to the loopback device. I run the following program on two platforms (linux and mac)

{code}

package main

import (

"fmt"

"net"

"net/http"

"time"

)

type MyHandler struct {

}

func (h *MyHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {

}

func main() {

handler := &MyHandler{}

listener, err := net.Listen("tcp", ":80")

if err != nil {

panic(err)

}

go http.Serve(listener, handler)

time.Sleep(time.Second)

conn, err := net.Dial("tcp", "localhost:80")

if err != nil {

panic(err)

}

reportedIp := conn.RemoteAddr().String()

fmt.Printf("net.Dial maps %v --> %v\n", "localhost:80", reportedIp)

return

}

{code}

When I run the code on linux I see

{code}

## On Linux

linux_prompt > uname -a
Linux pc6a.local 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

linux_prompt > sudo -E go run hack/main.go 

net.Dial maps localhost:80 --> 127.0.0.1:80

{code}

which I would expect: localhost:80 being maped to 127.0.0.1:80

But when I run this program on mac

{code}

## On Mac

mac_prompt > uname -a
Darwin oakm07147fbf7.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

mac_prompt > sudo -E go run hack/main.go 

net.Dial maps localhost:80 --> 127.0.0.1:5001

{code}

It is very surprising to me that Darwin is maping localhost:80 --> 127.0.0.1:5001 ! Why is port 80 mapped to port 5001? This seems wrong to me, but hoping someone on this list can help me challenge this assumption if you see it differently. Thanks for any help.

-pete

Pete Christopher

iParadigms/Turnitin

[Dan Kinder]

I also see this happen and would like some input if anyone knows what's up.

It just affects tests for me seems unusual and could cause other unexpected behavior for folks.

[Benjamin Measures]

> strange results on the Mac platform, when the connection is made to the loopback device.

For a TCP connection there'll be a pair of 4-tuples of (localip, localport, remoteip, remoteport), one on local and one on remote.

BSD might be optimising the case where both are on localhost and just keeping one of the pair. Check this by inspecting the LocalAddr also.

[Dan Kinder]

Quick note for future reference to any unfortunate soul who runs into this same problem we did:

The culprit turned out to be Cisco Anyconnect VPN. Be wary of what it does to your network stack...

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/4bzFhjZHSl4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Dan Kinder
Senior Software Engineer
Turnitin – www.turnitin.com
dki...@turnitin.com

[William McGann]

This has bitten me on previous projects, to the point where I do all of my coding for work on a remote box via SSH or in a VM. Anyconnect works, but omg the problems I've encountered with their "magical" multiplexing of all traffic over a single port. ALL traffic.