View Full Version : portable way to get local ip address
meshko
04-09-2003, 11:58 PM
Hi,
I'm looking for a (preferrably portable) way to get the local ip address different from 127.0.0.1.
When I do gethostbyname() on the result of gethostnae() I get 127.0.0.1
I found code sample which goes through all interfaces using ioctl and gets their ip address, but it only works on Linux and not on FreeBSD. Making it work on FreeBSD requires quite a lot of changes.
Also on Linux this code gives me struct in_addr which I then can convert to string and it shows correct IP (127.0.0.1) but when I try to compare my ia->s_addr to INADDR_LOOPBACK which is the constant for 127.0.0.1 they are not equal. What's up with that?
meshko
04-10-2003, 12:04 AM
OK, I know why my comparison didn't work -- the constant is in network byte order, so when I converted it it works. But the question about portability remains.
Thanks in advance!
RobSeace
04-10-2003, 01:19 PM
Actually, no, you got that backwards: INADDR_LOOPBACK (and all the
other INADDR_* constants) are in host byte order, not network byte
order... However, the value inside an in_addr is always in network
byte order...
If gethostname() or uname() give you a hostname that resolves to
127.0.0.1, then I'd say your host is misconfigured... It's not a problem
with your code, it's a problem with your server setup... The defined
hostname for a machine shouldn't be "localhost", or equivalent... (Unless
it has no real network interface at all, anyway...)
meshko
04-10-2003, 02:30 PM
Actually, no, you got that backwards: INADDR_LOOPBACK (and all the
other INADDR_* constants) are in host byte order, not network byte
order... However, the value inside an in_addr is always in network
byte order...
Thanks. How do I find out about things like that? I don't understand how to find documentation on structs and comments in the .h files itself are somewhat lacking.
If gethostname() or uname() give you a hostname that resolves to
127.0.0.1, then I'd say your host is misconfigured... It's not a problem
with your code, it's a problem with your server setup... The defined
hostname for a machine shouldn't be "localhost", or equivalent... (Unless
it has no real network interface at all, anyway...)
OK, could you tell me how to fix it?
I have the following /etc/hosts:
127.0.0.1 myhost myhost.dyndns.org localhost.localdomain localhost
192.168.1.23 myhost myhost.dyndns.org
Is this wrong?
Thakns
RobSeace
04-10-2003, 07:59 PM
Typically, you can configure the local hostname via the "hostname"
command... Usually, just "hostname <name>" does it, but consult
your own local manpages...
However, that "/etc/hosts" entry you have for 127.0.0.1 may be your
real problem, after all... Yes, it looks wrong to me... Usually, 127.0.0.1
would only be associated with "localhost" (and possibly
"localhost.localdomain")... You don't want any real hostname associated
with it... You want that associated with the real IP, which you seem to
have as well (but, it'd probably take the first occurance it finds)...
meshko
04-10-2003, 08:02 PM
yes, thank you. Removing my host name from the 127.0.0.1 entry helped.
Uzume
04-14-2003, 06:34 AM
As a side note, not all IN_ADDR constants are in host order. It is true all the IPv4 constanst are in host order but for some reason all the IPv6 IN_ADDR type constants are in network byte order (This seems to be in part due address size and initialization/size problems).
RobSeace
04-14-2003, 12:53 PM
Ah, but I said all the INADDR_* constants, and that's true; the IPv6
versions are called IN6ADDR_*... ;-)
I think the main reason is there's no way to use them as separate
individual values, for comparison purposes, or whatever, like you can
with the IPv4 values (since they're just 32-bit ints there, vs. a 128-bit
value, which has no native system type to hold it)... So, the only use
for them is to initialize in6_addr structs... They also had to come up
with a bunch of macros that weren't necessary for IPv4 to perform
address tests for you: all the IN6_IS_ADDR_*() stuff...
vBulletin® v3.7.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.