code review 13370043: go.crypto/ssh: use 127.0.0.1 during TestKexAlgorithms (...

go.crypto/ssh: use 127.0.0.1 during TestKexAlgorithms (fixes windows build)

[brainman, 2013-08-29 02:46:44]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go.crypto

[mikio, 2013-08-29 02:50:01]

LGTM

[remyoudompheng, 2013-08-29 02:51:58]

Any reason you chose 127.0.0.1 over localhost?

[brainman, 2013-08-29 02:55:21]

On 2013/08/29 02:51:58, remyoudompheng wrote:
> Any reason you chose 127.0.0.1 over localhost?

I looked at tests in net. That is what used there.

I am not happy that ":0" works on linux, but breaks on windows. Do you think we
should report it as an issue?

Alex

[brainman, 2013-08-29 02:57:51]

*** Submitted as
https://code.google.com/p/go/source/detail?r=9a3505763940&repo=crypto ***

go.crypto/ssh: use 127.0.0.1 during TestKexAlgorithms (fixes windows build)

R=golang-dev, mikioh.mikioh, remyoudompheng
CC=golang-dev
https://codereview.appspot.com/13370043

[mikio, 2013-08-29 03:04:17]

On Thu, Aug 29, 2013 at 11:55 AM,  <alex.brainman@gmail.com> wrote:

>> Any reason you chose 127.0.0.1 over localhost?
>
> I looked at tests in net. That is what used there.

I think we can't assume that each of node under tests has a such
universal mapping btw conventional name "localhost" and "127.0.0.1" or
"::1". Honestly, I didn't know that some Linux distro has a separate
name for "::1", "ip6-localhost".

[brainman, 2013-08-29 03:08:15]

On 2013/08/29 03:04:17, mikio wrote:
> 
> ...

Should ":0" work on everywhere?

If it should, then we should implement and document it to work everywhere.

If it shouldn't, then we should implement and document it to work everywhere.

I am concerned it works in some places, but not in others.

Alex

[mikio, 2013-08-29 03:27:51]

On Thu, Aug 29, 2013 at 12:08 PM,  <alex.brainman@gmail.com> wrote:

> Should ":0" work on everywhere?

Probably, I expect it would work as a number literal for transport
layer protocol's ephemeral port.
But not sure for Plan 9.

> I am concerned it works in some places, but not in others.

Yay, Issue 5632: net: Improve docs

[brainman, 2013-08-29 05:55:18]

On 2013/08/29 03:27:51, mikio wrote:
> 
> > Should ":0" work on everywhere?
> 
> Probably, ...

Listener translates ":0" into address 0.0.0.0. Windows connect does not allow
connection to that address. From
http://msdn.microsoft.com/en-us/library/aa923167.aspx

" ... If the address member of the structure specified by the name parameter is
all zeroes, connect will return the error WSAEADDRNOTAVAIL. ..."

Can you explain to me where the problem is?

Alex

[mikio, 2013-08-29 06:11:44]

On Thu, Aug 29, 2013 at 2:55 PM,  <alex.brainman@gmail.com> wrote:

> Listener translates ":0" into address 0.0.0.0. Windows connect does not
> allow connection to that address. From
> http://msdn.microsoft.com/en-us/library/aa923167.aspx
>
> " ... If the address member of the structure specified by the name
> parameter is all zeroes, connect will return the error WSAEADDRNOTAVAIL.
> ..."
>
> Can you explain to me where the problem is?

Ah, I now realised that making an active open connection to the
wildcard address is a platform-dependent behavior. Traditional
stack usually attempts to route to the local stuff, usually loopback
address or so. Good to know that, thanks.

[brainman, 2013-08-29 06:39:58]

On 2013/08/29 06:11:44, mikio wrote:
> 
> ... Traditional
> stack usually attempts to route to the local stuff, usually loopback
> address or so. ...

Should we translate 0.0.0.0 into 127.0.0.1 under the covers then?

Alex

[mikio, 2013-08-29 07:24:08]

On Thu, Aug 29, 2013 at 3:39 PM,  <alex.brainman@gmail.com> wrote:

> Should we translate 0.0.0.0 into 127.0.0.1 under the covers then?

Or reject wildcard stuff at Dial.
But it seems like documentation might be better.

[brainman, 2013-08-29 07:31:27]

On 2013/08/29 07:24:08, mikio wrote:
> 
> Or reject wildcard stuff at Dial.

I am not expert enough to decide what is right, but I agree we must do one or
the other.

> But it seems like documentation might be better.

No. We need to fix the issue. Then we can document whatever decision we make.

Alex

[mikio, 2013-08-29 07:44:21]

On Thu, Aug 29, 2013 at 4:31 PM,  <alex.brainman@gmail.com> wrote:

> No. We need to fix the issue. Then we can document whatever decision we
> make.

I'm not sure this is an issue, but please file an issue.

[brainman, 2013-08-30 06:48:22]

On 2013/08/29 07:44:21, mikio wrote:
> 
> I'm not sure this is an issue, but please file an issue.

Done. https://code.google.com/p/go/issues/detail?id=6290

Alex