just found that using --winhttp-proxy-resolver works
but really, we should not need to..

[+eroman], who's really the expert in this space.

If you run IPConfig from the command line, do you see "0.9.201.45" anywhere?

Open cmd.exe and run the following commands:

> hostname

Now type that result into nslookup (XXX is just placeholder)

> nslookup XXX

Presumably this is returning the 0.9.201.45.

Lastly, run:

> ipconfig /all

Hi, appreciate the comments and suggestions, but as noted above, a full registry scan did not pick up the address, hence it does not show with IPCONFIG /ALL.  This address is not bound to any adapter (there is only 1 real NIC, the loopback and the ISATAP)
Also, as noted, process monitor whilst chrome starts can't pick up that address.
nslookup of hostname returns the correct IP, needs to be FQDN of course (single label name will not resolve in our environment)
It seems to be hardware dependent, as I can't replicate it on my test VM
desktop = HP EliteDesk 800 G2 SFF
system info is attached

Deleted: mh.nfo 2.4 MB

mh.nfo 2.4 MB Download

Thank you for providing more feedback. Adding requester "eroman@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> nslookup of hostname returns the correct IP, needs to be FQDN of course (single label name will not resolve in our environment)

That is probably the problem then.

The mechanism that Chrome uses to fulfill myIpAddress() is quite literally to try and resolve the retrieved hostname (dns search suffix and all).

This was matching Firefox at the time, but that may have changed now. We probably need a more complicated approach that enumerates the adapters instead.

Unfortunately myIPAddress() suffers from ambiguity since it only returns 1 address; but sounds like it isn't working for you at all.

Hi, thanks, though just confirming, NSLOOKUP works if the search suffix is used.
So when you say "(dns search suffix and all)" I'm somewhat confused
Is Chrome using a FQDN to resolve the IP used for myIPAddress() - or not ?
If it is using the FQDN, how is it being constructed on a Windows domain joined device ?  Is it using the hostname and the AD domain - which is always the primary search suffix for any domain joined machine ? or is it using the hostname lable, then appending one of the search suffixes from the TCP/IP config ?
thanks

We just use gethostname(), and do a standard IPv4-only DNS lookup on the result, returning the first result.

I believe I have identified the issue.
the hostname of this client is a number (it has no alpha characters)
when I convert that hostname into binary, then build an IP address out of the binary (taking 8 bits for each octet), then convert those 8 bit ‘chunks’ back to decimal – I get the IP address returned in the alert (noted above)
Therefore, I’m assuming your code, when it does gethostname(), if it gets a ‘number’ it assumes it is the IP address (and converts as needed) 

If our URL parser can parse it as an IPAddress, we do skip the DNS lookup.  If you can share it, what does the hostname actually look like?

the hostname is   641325 
 
when I convert that to binary, then back to a 4 octet decimal, I get 
0.9.201.32
which is remarkably close to the number reported in the log of "0.9.201.45"

so possibly something else is going on with that last octet, but I recon that is it

I'm not sure why we support entering an IPv4 address as a single number, though I'd guess it was because other browsers do, or did at one point.  It's certainly not mentioned in the "IPv4address" rule of RFC 3986 (The URI RFC - I'm not sure if there actually is an RFC that more directly covers text representation of IPv4 addresses).

I don't have FireFox handy, but Edge doesn't treat "http://641325/" as a URL, so maybe we can get rid of that funky behavior, which is something I'd definitely be in favor of doing, if we can get away with it.

Of course, it also looks to me like Edge doesn't try to do a DNS lookup, either.  Or at least it decides it's so un-URL-like that it does a search instead of trying to navigate (And the same is true for non-reserved addresses, like http://553641325/ - IPv4 addresses with a leading 0 are reserved).

Anyhow, using a pure numeric hostname doesn't seem like a great idea to me, so I'm really not too concerned about that use case, just think treating numbers as IPv4 addresses is weird, and it would be good to remove that if we can, which might coincidentally also fix your use case.

So the new standard for our large (22,000 user) organisation, is to use the asset number of the computer as their hostname.
It makes matching them in the finance system easy.
I think it’s valid, especially as it’s fully supported by all other systems

I guess we will amend the standard to include an alpha character
Chrome is not widely used, but used enough this is causing an issue, as I'm picking the fix may be some time off

Hrm...Firefox and Safari both recognize http://2130706433/ as http://127.0.0.1/, though IE does not.  Think we may be stuck with the behavior for now.  Could imagine doing DNS lookups before falling back to assuming it's an IP address, but down that path lies madness.

Hi, not sure why the behaviour of browsing to a number is relevant ?
this is about js function myipaddress() returning valid data
At the beginning of this thread it was noted that the process is to get the host name then perform a nslookup on that return 
If that was followed then the issue is resolved. The call to retrieve hostname in Windows is well documented 

https://msdn.microsoft.com/en-us/library/windows/desktop/ms738527(v=vs.85).aspx

That call, or others like it, are not ever returning an IP address 
Anyway we are renaming computers...

We have one way to convert strings to host names or IP addresses.  It behaves the same way on all platforms.  We get a string, pass it to the DNS resolver, and get out an IP (Regardless of whether it was an IP address or hostname).  We'd have to alter all callers, or add a magic way to bypass that, if we wanted to maintain old behavior for some callers, and implement a new magic one solely for the strings returned by gethostname.