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: unable to bind the specified network card to establish a TCP connection #39293

Closed
caleb-letsgo opened this issue May 28, 2020 · 4 comments
Closed

Comments

@caleb-letsgo
Copy link

@caleb-letsgo caleb-letsgo commented May 28, 2020

Failure to bind to the specified network card will occur on some machines. I wanted to connect from 192.168.1.101, but actually went to the 26.26.26.1 network card, but the source address of the packet was 192.168.1.101. Very strange.
It's been on two devices, but the other devices are fine. The systems of the two devices in question are: win7 ultimate and win10 enterprise. Other devices have no problems with such systems.
Is it unclear whether golang supports bind? Or is there some other software that affects bind?

golang version : go1.14

netAddr := &net.UDPAddr{}
netAddr.(*net.UDPAddr).IP = net.ParseIP("192.168.1.101")

dialer := net.Dialer{LocalAddr: netAddr, Timeout: 5 * time.Second}
dialer.Dial(network, address)
@davecheney
Copy link
Contributor

@davecheney davecheney commented May 28, 2020

Thank you for raising this issue. Can you please provide a runnable code sample that someone who does not have access to your environment can use to verify the issue you are seeing.

Thank you

@ianlancetaylor ianlancetaylor changed the title Unable to bind the specified network card to establish a TCP connection net: unable to bind the specified network card to establish a TCP connection May 28, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 28, 2020

Setting the LocalAddr field will cause the net package to call bind. I'm not sure this is a Go problem.

@antong
Copy link
Contributor

@antong antong commented May 29, 2020

You don't bind a socket to a network card, you bind it to a local IP address (and port). The routing system (using the routing table) determines where the traffic goes. So, it is not strange that the source address for outgoing packets is the address you bound the socket to. That is always the case. Now, Windows by default uses the strong host model, which means that outgoing packets must have a source address that is assigned to the outgoing network interface. This rule is also used to make the routing decision, so if you force the local IP address by binding a socket to an address, then for an outgoing packet a route will be selected that satisfies the requirement. So if the routing table contains several possible routes to a destination, for example Wi-Fi and Ethernet both with a default route, then if you bind a socket to the Wi-Fi address, then packets will be routed using the default route on the Wi-Fi interface even if the Ethernet interface has a default route with a lower metric. This is because the strong host model does not allow packets going out on the Ethernet interface with the source address assigned to the Wi-Fi interface. If I interpret @caleb-letsgo 's issue correctly, this behavior was what was expected. Now for the Windows devices where it doesn't work this way, these devices probably are configured to use the weak send model instead. Note that most other systems such as Linux do not support the strong host model at all, so they always work as your two problematic Windows systems.

@caleb-letsgo
Copy link
Author

@caleb-letsgo caleb-letsgo commented Jun 6, 2020

Thank you very much。what you said is right, awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.