-
Notifications
You must be signed in to change notification settings - Fork 158
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
Specify src_ip
correctly in Transmit
s in iroh-net
#2632
Comments
The problem also arises when you have multiple addresses on the same subnet on the same interface. IIRC this is the default on Windows, and a supported configuration on Linux, due to RFC 4941 privacy extensions: a host may have both a stable EUI-64 address, a primary temporary address, and one or more old temporary addresses being turned down, all on the same WAN subnet. An IPv6-based protocol is unlikely to be able to establish a connection correctly in this environment without correctly specifying source addresses. As a general rule of thumb, you should send from whatever address you received on, for a given path. |
(I previously wrote this on discord somewhere, repeating here) We need to store the I'm not sure if this should be blocking for the transition to 0.11, what do you think @matheus23 ? I do think we should do the same on all platforms regardless. |
Yeah agreed, we should do this & do it like this.
I don't think this should be blocking the transition.
|
Currently, the
src_ip
values forquinn::Transmit
s are indirectly set by us via our rewriting ofdst_ip
(and choice ofdst_ip
in the relay case) in theRecvMeta
ofpoll_recv
(inMagicSock
).This can cause issues, e.g. when unspecified IP addrs (
0.0.0.0
or::
) make it tosrc_ip
. Windows seems more pedantic about this and errors out.We return unspecified IP addrs, because we set
dst_ip
toMagicSock::normalized_local_addr
.As an interim solution, we've set it to
None
on windows.I suspect this can cause issues when there's multiple IP interfaces connected to the device and the OS ends up choosing the wrong one.
Instead, we should probably figure out the interface we want to send from via netcheck.
More information in this PR comment.
The text was updated successfully, but these errors were encountered: