net: ListenUDP doesn't work with ":port" or "0.0.0.0:port" on Windows

[toqueteos]

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

go version go1.9.2 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

$ go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\code\go
set GORACE=
set GOROOT=C:\go
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

What did you do?

Here's a program that works perfectly on linux (tried on go version go1.5.1 linux/amd64 and playground):
https://play.golang.org/p/LBPPVD9H9e

It starts two UDP listeners (:11000 and :11001), sets up a reader for each listener, tries sending a message from server1 to server2 and another one the other way around.

What did you expect to see?

It's a simple UDP ping-pong, so it should work just fine, no errors.

What did you see instead?

write udp [::]:11000->:11001: wsasendto: The requested address is not valid in its context

[odeke-em]

/cc @alexbrainman @bradfitz

[bradfitz]

What does Go 1.9 on Linux do?
What does Go 1.8 on Windows do?

[bradfitz]

Tentatively flagging this as Go 1.11 for now, until more is known.

[bradfitz]

(We can fix it earlier if warranted.)

[toqueteos]

What does Go 1.9 on Linux do?

I updated my Go installation to go version go1.9.2 linux/amd64.

Output: everything is ok

Same as in playground.

What does Go 1.8 on Windows do?

I downgraded my Go installation to go version go1.8.5 windows/amd64

Output: write udp [::]:11000->:11001: wsasendto: The requested address is not valid in its context

[crvv]

The error comes from (*net.UDPConn).WriteToUDP(message, net.ResolveUDPAddr("udp", ":11001")).
The destination should be localhost:11001.
On MacOS, I can get a similar error panic: write udp [::]:11000->:11001: sendto: no route to host.
I think this is not bug in Go but an implementation difference among the kernels.

[alexbrainman]

The error comes from (*net.UDPConn).WriteToUDP(message, net.ResolveUDPAddr("udp", ":11001")).

The error happens in https://play.golang.org/p/LBPPVD9H9e on line 48

conn.WriteToUDP(message, addr)

which calls Windows WSASendTo API that fails with WSAEADDRNOTAVAIL. According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms741693(v=vs.85).aspx - "... WSAEADDRNOTAVAIL - The remote address is not a valid address (such as ADDR_ANY) ...". I suspect we use ADDR_ANY here.

The destination should be localhost:11001.

Yes, that will fix it. But maybe we could handle code as is. Leaving for @mikioh and @bradfitz to decide what to do here.

Alex

[toqueteos]

@alexbrainman So it is fine to use :11001 in net.ListenUDP but not in (*UDPConn).WriteToUDP? If that solves the issue I can live with that.

EDIT: Although either the docs or the error should point to this solution if it's the proper way to do it.

[mikioh]

Just FYI: I just filed #22827, hope that the issue describes the root cause of this issue well. Also I'm not keen on using the name localhost as a quick hack, so I also filed #22826 for tracking the localhost stuff.

[mikioh]

I guess that the snippet below could help to understand the circumstances:

package main

import (
        "fmt"
        "net"
)

func main() {
        for _, cf := range []struct {
                name, src, dst string
        }{
                {"4-4", "udp4", "udp4"},
                {"6-6", "udp6", "udp6"},
                {"any-any", "udp", "udp"},
                {"4-any", "udp4", "udp"},
                {"6-any", "udp6", "udp"},
                {"any-4", "udp", "udp4"},
                {"any-6", "udp", "udp6"},
                {"4-6", "udp4", "udp6"},
                {"6-4", "udp6", "udp4"},
        } {
                cd, err := net.ListenPacket(cf.dst, ":0")
                if err != nil {
                        fmt.Println("FAIL", err, "\n")
                        continue
                }
                defer cd.Close()
                cs, err := net.ListenPacket(cf.src, ":0")
                if err != nil {
                        fmt.Println("FAIL", err, "\n")
                        continue
                }
                defer cs.Close()

                fmt.Printf("%s: src=%v dst=%v\n", cf.name, cs.LocalAddr(), cd.LocalAddr())

                _, err = cs.WriteTo([]byte("*"), cd.LocalAddr())
                if err != nil {
                        fmt.Println("FAIL", err, "\n")
                        continue
                }
                var b [1]byte
                _, auxrt, err := cd.ReadFrom(b[:])
                if err != nil {
                        fmt.Println("FAIL", err, "\n")
                        continue
                }
                fmt.Printf("SUCCESS by routing with %v\n\n", auxrt)
        }
}

[alexbrainman]

@alexbrainman So it is fine to use :11001 in net.ListenUDP but not in (*UDPConn).WriteToUDP?

I do not know the answer to your question. I am not an expert in this area, and I do not want to confuse you. I will defer to Mikio.

Alex

[crvv]

So it is fine to use :11001 in net.ListenUDP but not in (*UDPConn).WriteToUDP? If that solves the issue I can live with that.

This is correct and I think this is the least surprised behavior.

In Go package net, the host can be empty and an empty host means an unspecified IP address(0.0.0.0 or ::0).

If you don't specify an address to listen, it will listen on all addresses.
If you don't specify an address to send a package, where do you expect it to be sent to?

Maybe the document(https://golang.org/pkg/net/#Dial) should be better. It is

For TCP, UDP and IP networks, if the host is empty or a literal unspecified IP address, as in ":80", "0.0.0.0:80" or "[::]:80" for TCP and UDP, "", "0.0.0.0" or "::" for IP, the local system is assumed.

I think "the local system" is confusing.

[crvv]

The meaning of an empty host is documented in three functions.

https://golang.org/pkg/net/#Dial

For TCP, UDP and IP networks, if the host is empty or a literal unspecified IP address, as in ":80", "0.0.0.0:80" or "[::]:80" for TCP and UDP, "", "0.0.0.0" or "::" for IP, the local system is assumed.

https://golang.org/pkg/net/#Listen

For TCP networks, if the host in the address parameter is empty or a literal unspecified IP address, Listen listens on all available unicast and anycast IP addresses of the local system.

https://golang.org/pkg/net/#ListenPacket

For UDP and IP networks, if the host in the address parameter is empty or a literal unspecified IP address, ListenPacket listens on all available IP addresses of the local system except multicast IP addresses.

So an empty host is an unspecified address in Listen and ListenPacket. But an empty host is localhost in Dial.

See func Dial for a description of the network and address parameters.

This sentence repeated 9 times in https://golang.org/pkg/net
And it also appears in the doc of function Listen although an empty host in Listen is different with one in Dial.

The problem is, a *UDPAddr can be used in DialUDP, ListenUDP, and WriteToUDP.
It is strange that a single *UDPAddr can be different addresses when used in different functions.

[mikioh]

@toqueteos,

There's #22827 for tracking the root cause of this issue, feel free to close this issue.

So it is fine to use :11001 in net.ListenUDP but not in (*UDPConn).WriteToUDP?

For connection setup, you need to let the protocol stack inside the kernel know what your endpoint wants to receive. For data transmission, you must be sure the passing destination identifier is appropriate for the protocol stack inside the kernel. In your case, the IPv4 address 0.0.0.0/32 or IPv6 address ::/128 is valid for connection setup because the address is considered as a wildcard reception address by convention. However, as described in #22827, 0.0.0.0/32 or ::/128 is not valid for data transmission because it's invalid for IP routing.

@crvv,

Feel free to open a new issue for documentation improvement and send a CL.

[toqueteos]

Ok, then I'm closing this!

@mikioh Sure, that makes perfect sense, just wanted to confirm.

Anyway it's very weird that ListenUDP allows using WriteToUDP but the *UDPConn returned by DialUDP doesn't. I found it's because they connect using a different "mode" but it's never mentioned in the docs.

EDIT: I'll confirm my suspicions on this, recheck docs and create another issue if something doesn't add up.