Forum OpenACS Development: NaviServer on Windows: [ns_info address] returns IP v6 address
Executing the same statement on Linux I get "127.0.0.1", which also doesn't comply with the description of the command:
> ns_info address
> Returns the primary IP address of this machine,
> or "0.0.0.0" if unable to determine
Actually, this is what I'd be interested in: The "primary IP address".
1) get the hostname (via c-library function gethostname()).
2) if this fails, assume "localhost" as hostname
3) it determines the first IP address via the OS for this hostname (typically via c-library getaddrinfo()). When NaviServer is compiled with IPv6 support, the function might return an IPv6 address, when there is an IPv6 address associated with this name.
In general, it is no surprise, that a "ns_info address" returns different values on different machines. But you are right, the man page is not correct, it should read:
...returns the first IP address of the hostname of the machine, or the unspecified IP address (for IPv4 "0.0.0.0", for IPv6 "::").
On your linux/windows box, what do you get for "ns_info hostname"? it should be the same as what you get by running the cmd "hostname" under linux/windows. The probably easiest way to determine the first associated IP address for the returned hostname is to ping it.
Note that the result of [ns_info address] is not necessarily the same IP address that naviserver is listening; one nsd might be listening on multiple IP addresses (depending on the config-file you are using). For example, openacs.org listens on an IPv4 address and on an IPv6 address.
btw., if you do not care about IPv6, compile NaviServer without IPv6 support (configure flag).
Both machines have valid IPv4 addresses on their primary network adapters, assigned by DHCP.
- ws2012 for the Windows Server 2012, and ping ws2012 pings somehow using IPv6.
- "project-open-v50-dev" for my Linux box, and ping project-open-v50-dev pings to 127.0.0.1.
So that's consistent with your explanation on how ns_info address works. And you are right, that doesn't match the man-page text. And it doesn't match the intuition, at least not mine and/or the ]po[ use-case.
Also, with AOLserver 4.5.1 I get the correct ("intuitive") IP address on Windows. I could also swear that it also used to work like this on Linux with ]po[ V4.0.2 (but II can't test right now).
The US is already out of IPv4 addresses , so IPv6 will become more visible world-wide (see e.g. ). One option seems to be to change the priorities in windows to prefer IPv4 over IPv6 [3,4]. Another option would be to add an option to naviserver "ns_info address -prefer ipv4" (and maybe simiar commands), but in cases, where there is no ipv4 address assigned, this will fail.
Nice argument, but sorry, the behavior of ns_info address is
a) incorrect according to the man page,
b) incorrect according to the last AOLserver and
c) incorrect for our use-case.
We can't get much closer to the definition of a bug. And we don't have a single customer who'd enter a IPv6 IP-Address manually in a browser.
I've had to invest another 3 hours to create a robust and multi-platform parser for ifconfig and ipconfig, because I can't wait for you to finish this stuff.
About fixing this command: Let the man page guide you: "Primary IP address of this machine" is a pretty intuitive concept that works in 95% or all cases. Otherwise you've got a pretty useless command in your API...
Why don't you revert to the code in AOLserver?
I got the "bug" - my bug. I assumed that ns_info address on AOLserver 4.5.1 Linux as intuitively required. But it doesn't. I've just installed AOLserver 4.5.1 and checked.
So both system implement ns_info address in the same way, and reverting wouldn't fix my issue.
Conclusion: You could change the implementation in NaviServer in order to prefer the IPv4 address over the IPv6 address. But otherwise everything is like it was.
=> We'll work with our own implementation of extracting the IP from ifconfig/ipconfig tool output.
ns_addrbyhost -all [ns_info hostname]