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.

Sign up for GitHub

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

Jump to bottom

net: Failed net.LookupAddr in ipv6 wrt leading zeroes #8996

Closed
gopherbot opened this issue Oct 24, 2014 · 6 comments
Closed

net: Failed net.LookupAddr in ipv6 wrt leading zeroes #8996

gopherbot opened this issue Oct 24, 2014 · 6 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@gopherbot
Copy link
Contributor

by viriketo:

IPv6 addresses may have leading zeros or not. They are optional. The address comparisons
for net.LookupAddr work by string comparison, so they may fail in case of the /etc/hosts
entry not matching exactly the LookupAddr parameter.

For example, these are equivalent addresses:
fce6:d1ad:ca44:9625:e589:3806:0248:8591
fce6:d1ad:ca44:9625:e589:3806:248:8591

The related code: http://golang.org/src/pkg/net/hosts.go
@gopherbot
Copy link
Contributor Author

Comment 1 by viriketo:

The same can be said of ipv4 addresses in fact. They can have leading zeroes.

@ianlancetaylor
Copy link
Member

Comment 2:

Labels changed: added repo-main, release-go1.5.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@odeke-em
Copy link
Member

If anyone has a way to, would you mind providing some test cases in direct relation to this issue? This is because I've been looking at this and so far I have built an independent package for ip comparison. Thank you.

@nightlyone
Copy link
Contributor

An alternative aproach would be to look for ":0" or ".0" in the provided address and call net.ParseIP() followed by String() on it to normalize such rare cases and do the lookup with that result instead.

@odeke-em
Copy link
Member

odeke-em commented Mar 8, 2015

Nice, thank you for that @nightlyone. For some reason, I assumed that since this hadn't been implemented in the standard library, that there were problems with the parsing itself. Turns out your approach is way simpler and cleaner.

@rsc rsc removed the repo-main label Apr 14, 2015
@gopherbot
Copy link
Contributor Author

CL https://golang.org/cl/10306 mentions this issue.

@mikioh mikioh closed this as completed in 9378493 Jun 2, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5
Development

No branches or pull requests
6 participants
@bradfitz @rsc @nightlyone @ianlancetaylor @odeke-em @gopherbot