net: use original raddr param for RemoteAddr if getpeername fails?

[rsc]

package main

import (
        "fmt"
        "net"
        "os"
)

func main() {
        localAddr := net.ParseIP(os.Args[1])
        remoteAddr := net.ParseIP(os.Args[2])
        netProto := os.Args[3]

        c, err := net.DialIP(netProto, &net.IPAddr{localAddr}, &net.IPAddr{remoteAddr})
        if err != nil {
                fmt.Printf("DialIP failed: %v\n", err)
                return
        }
        fmt.Printf("LocalAddr: %v, RemoteAddr: %v\n", c.LocalAddr(), c.RemoteAddr())
}

# ./test 172.23.124.29 172.23.124.30 ip:tcp
LocalAddr: 172.23.124.29, RemoteAddr: <nil>
# ./test 172.23.124.29 172.23.124.30 ip:udp
LocalAddr: 172.23.124.29, RemoteAddr: <nil>
# ./test 172.23.124.29 172.23.124.30 ip:112
LocalAddr: 172.23.124.29, RemoteAddr: <nil>

because 

# strace ./test 172.23.124.29 172.23.124.30 ip:udp

socket(PF_INET, SOCK_RAW, IPPROTO_UDP)  = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("172.23.124.29")}, 16) = 0
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("172.23.124.30")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(17),
sin_addr=inet_addr("172.23.124.29")}, [16]) = 0
getpeername(3, 0xf8400000e0, [112])     = -1 ENOTCONN (Transport
endpoint is not connected)
======================

[rsc]

Comment 1:

Labels changed: added size-m.

[rsc]

Comment 2:

Labels changed: added suggested.

[gopherbot]

Comment 3 by tylerbunnell:

I'd like to give this one a go, but I'm unable to duplicate the bug.
On OSX 10.8.2 it says "operation not permitted" unless I run it with sudo, in which case
it will run, but the RemoteAddr is always the same as what I put in originally.
Is there something I need to do in order to force this bug to appear?

[mikioh]

Comment 4:

At least this happens on Linux.
Perhaps BSD variants are fine.

[gopherbot]

Comment 5 by tylerbunnell:

Bollocks. I don't have a linux system on which to test this.
Perhaps I can put together a VM or something.

[rsc]

Comment 6:

This issue was closed by revision 06cbe78.

Status changed to Fixed.

[mikioh]

Comment 7:

This issue was closed by revision bfb32dc.