-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: LookupNetIP returns IPv4 in IPv6 instead of IPv4 #53554
Comments
The method is currently just a wrapper around the old way. But the old way represents IPv4 in 16 bytes slice, so when this wrapper parses the slice it will always create IPv6 address. For IPv4 addreses it's IPv4 in IPv6. The fix just converts the old IPv4 address representation to 4 bytes slice before parsing, so it's parsed as IPv4 and not IPv4 in IPv6. Fixes golang#53554
Change https://go.dev/cl/414275 mentions this issue: |
It seems that the original IP is converted to IPv6 here: Lines 341 to 348 in 416c953
Maybe it's better to remove the conversion? func copyIP(x IP) IP {
- if len(x) < 16 {
- return x.To16()
- }
y := make(IP, len(x))
copy(y, x)
return y
} I run BTW, the 3 lines were added as part of the commit to fix #6465. I have tested on tip with the 3 lines removed and can not reproduce #6465. |
You are right. It seems quite weird to me that the |
@kasparjarek I'm sorry that my suggested approach turns out to need more changes than that. So I will send a CL myself. |
Change https://go.dev/cl/415580 mentions this issue: |
Hi @kasparjarek, how about the implementation in PR#56406? Let's just change the calling from |
net.IP states that a 16-byte slice can still be an IPv4 address. But after netip.Addr is introduced, it requires extra care to keep it as an IPv4 address when converting it to a netip.Addr using netip.AddrFromSlice. To address this issue, let's change the cgo resolver to return 4-byte net.IP for IPv4. The change will save us 12 bytes too. Please note that the go resolver already return IPv4 as 4-byte slice. The test TestResolverLookupIP has been modified to cover this behavior. So no new test is added. Fixes golang#53554. Change-Id: I0dc2a59ad785c0c67a7bc22433105529f055997f GitHub-Last-Rev: bd7bb2f GitHub-Pull-Request: golang#53638 Reviewed-on: https://go-review.googlesource.com/c/go/+/415580 Auto-Submit: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
What did you see instead?
The method LookupNetIP is currently just a wrapper around the old way. But the old way represents IPv4 in 16 bytes slice, so when this wrapper parses the slice it will always create an IPv6 address. For IPv4 addresses, it's IPv4 in IPv6. It makes it harder to manipulate with a new address representation. For example I cannot just simply compare result of
netip.MustParseAddr("142.251.36.142")
with the same address returned byLookupNetIP()
. The comparison results in non-zero value.I would propose converting the old address into 4 bytes slice (if it's IPv4 address) before parsing #53555 . What do you think?
The text was updated successfully, but these errors were encountered: