ioctl() with IPv6 addresses??

[willy2]

Can I retrieve a IPv6 address using ioctl(ioctlSock, SIOCGIFADDR, &ifreq) call???

[mlampkin]

That is OS dependent... what are you using...

Have you looked at the source code for ifconfig / similar programs for your deployment ~ probably would find it a very good example... ;-)

For Linux I would try it and then determine what was returned by getting the size of he ifru_addr / ifr_addr struct within ifr_req to determine the type ( just one of several ways )...

Another option would be ( on some systems ) to use retnetlink...

Michael

[RobSeace]

I don't think it's likely to work on any system... Because, "ifr_addr"
has always been defined as just a plain old "struct sockaddr",
which simply isn't big enough to hold a sockaddr_in6... I suppose
a system could throw a union'd sockaddr_in6 into "struct ifreq" to
set aside the necessary space, but it would break binary
backwards-compatability, of course... (I suppose some smart
measures could be put in place such that it could detect if you're
using the old ifreq, and if so limit you to IPv4 only, but still allow
newer programs to get IPv6...) But, still, I've yet to see any system
actually do this... My RH9 system certainly doesn't... Do newer
Linux systems do so?? I believe most Linux stuff resorts to reading
"/proc/net/" files to get at IPv6 info... *shrug*

But, as Michael says: check the source for your system's "ifconfig"
and similar apps, and see what they do... They'd be likely to use
the best method...

[mlampkin]

I didn't get a chance to try it thats why I was suggesting ifconfig and retnetlink if available...

Gonna 2x check it but thought that a posix sockaddr_storage type ( the suggestion for IPv6 in getpeername etc. ) was also mapped to sockaddr in linux... which would give the required space, alignment and compatibility...

But then again... I may be thinking of the wrong OS... or hallucinating... ;-)


Michael

[willy2]

i am working on proprietary os. i just wanted to confirm whether other os support it or not.

[RobSeace]

Hmmm, no Michael, I do believe you're hallucinating... ;-) No,
you're probably just thinking of the magic "transparent union" stuff
that Linux (well, the glibc headers, along with GCC, really) does
so that you can pass in any sockaddr_* struct to any function
that's normally declared to only take a "struct sockaddr *"... But,
as near as I can see, plain old "struct sockaddr" is still the same
as it's always ever been: just sa_family, and a 14-byte sa_data
buffer... But, "struct sockaddr_storage" exists; and, if they had
used that in "struct ifreq", there wouldn't be this problem that there
is today... But, of course, sockaddr_storage is a lot newer than
ifreq, too...