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: The requested address is not valid in its context. #34171

Closed
eycorsican opened this issue Sep 7, 2019 · 4 comments
Closed

net: The requested address is not valid in its context. #34171

eycorsican opened this issue Sep 7, 2019 · 4 comments

Comments

@eycorsican
Copy link

@eycorsican eycorsican commented Sep 7, 2019

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

$ go version
go version go1.13 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\eric\AppData\Local\go-build
set GOENV=C:\Users\eric\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\eric\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
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
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\eric\AppData\Local\Temp\go-build933876154=/tmp/go-build -gno-record-gcc-switches

What did you do?

Run the following code, 192.168.1.114 is the IP address of the local network adapter.

package main

import (
        "net"
        "log"
)

func main() {
        d := &net.Dialer{
                LocalAddr: &net.TCPAddr{
                        IP: net.ParseIP("192.168.1.114"),
                        Port: 0,
                },
        }
        c, e := d.Dial("tcp", "127.0.0.1:8080")
        if e != nil {
                panic(e)
        }
        log.Printf("conn %v %v %v", c, c.LocalAddr(), c.RemoteAddr())
}

What did you expect to see?

Successfully connects to the TCP server listening at ":8080".

What did you see instead?

panic: dial tcp 192.168.1.114:0->127.0.0.1:8080: connectex: The requested address is not valid in its context.

goroutine 1 [running]:
main.main()
C:/share/gotest/main.go:17 +0x2bf
exit status 2

I am not sure if this is the expected behavior on Windows, but the code works fine on macOS, if that's expected, perhaps we should have it documented.

@antong

This comment has been minimized.

Copy link
Contributor

@antong antong commented Sep 8, 2019

This is not a Go issue, it is a Windows feature (google "strong host model"). The same thing happens with any other programming language. You can connect to "192.168.1.114:8080" in your example, but not 127.0.0.1 as you bound to another interface. What are you trying to achieve by binding the tcp client to a specific local address?

@eycorsican

This comment has been minimized.

Copy link
Author

@eycorsican eycorsican commented Sep 8, 2019

There are multiple default routes to different gateways on my machine, something looks like this:

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.255.0.1       10.255.0.2     37
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.114    300

By default traffic are going out through 10.255.0.2, while some traffic are desired to go out through 192.168.1.114, via binding to that interface.

But if it's the case that the destination address is 127.0.0.1, and we are binding to 192.168.1.114, the above error occurs. In fact, it's quite easy to distinguish traffic targeting 127.0.0.1 and don't bind to a specific interface while sending them, just would like to know if there is a cleaner solution.

@antong I tried to disable the strong host model with the following commands, and the program still fails, am I missing something?

PS C:\Windows\system32> netsh interface ipv4 set interface "WiFi" WeakHostSend=enabled
Ok.

PS C:\Windows\system32> netsh interface ipv4 set interface "WiFi" WeakHostReceive=enabled
Ok.

PS C:\Windows\system32> netsh interface ipv4 show interface 'WiFi'

Interface WiFi Parameters
----------------------------------------------
IfLuid                             : wireless_32768
IfIndex                            : 24
State                              : connected
Metric                             : 100
Link MTU                           : 1500 bytes
Reachable Time                     : 36500 ms
Base Reachable Time                : 30000 ms
Retransmission Interval            : 1000 ms
DAD Transmits                      : 3
Site Prefix Length                 : 64
Site Id                            : 1
Forwarding                         : enabled
Advertising                        : disabled
Neighbor Discovery                 : enabled
Neighbor Unreachability Detection  : enabled
Router Discovery                   : dhcp
Managed Address Configuration      : enabled
Other Stateful Configuration       : enabled
Weak Host Sends                    : enabled
Weak Host Receives                 : enabled
Use Automatic Metric               : disabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 1800 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 0
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled
ECN capability                     : application
RA Based DNS Config (RFC 6106)     : disabled
DHCP/Static IP coexistence         : disabled
@eycorsican

This comment has been minimized.

Copy link
Author

@eycorsican eycorsican commented Sep 8, 2019

I also tried to send traffic to another interface (192.168.119.49), with the strong host model enabled for both interfaces (192.168.119.49 and 192.168.1.114), I got a different error:

panic: dial tcp 192.168.1.114:0->192.168.119.49:8080: connectex: A connection attempt failed because the connected party did not properly respond after a period of time
, or established connection failed because connected host has failed to respond.

With the strong host model disabled, it worked.

But it failed anyway when sending to the loopback interface, it's seems that the loopback is somewhat special, and it's not related to the strong host model.

@eycorsican

This comment has been minimized.

Copy link
Author

@eycorsican eycorsican commented Sep 8, 2019

Closing since it's indeed not a Go specific issue.

@eycorsican eycorsican closed this Sep 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.