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: ListenUDP doesn't work with ":port" or "0.0.0.0:port" on Windows #22811

Closed
toqueteos opened this issue Nov 19, 2017 · 15 comments

Comments

Projects
None yet
7 participants
@toqueteos
Copy link

commented Nov 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

(We can fix it earlier if warranted.)

@toqueteos

This comment has been minimized.

Copy link
Author

commented Nov 20, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Author

commented Nov 21, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 22, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2017

@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

This comment has been minimized.

Copy link
Author

commented Nov 30, 2017

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.

@toqueteos toqueteos closed this Nov 30, 2017

@golang golang locked and limited conversation to collaborators Nov 30, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.