1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
We need better network address conv helpers.
This is what our applets want:
sockaddr -> hostname
udhcp: hostname -> ipv4 addr
nslookup: hostname -> list of names - done
tftp: host,port -> sockaddr
nc: host,port -> sockaddr
inetd: ?
traceroute: ?, hostname -> ipv4 addr
arping hostname -> ipv4 addr
ping6 hostname -> ipv6 addr
ifconfig hostname -> ipv4 addr (FIXME error check?)
ipcalc ipv4 addr -> hostname
syslogd hostname -> sockaddr
inet_common.c: buggy. hostname -> ipv4 addr
mount hostname -> sockaddr_in
==================
HOWTO get rid of inet_ntoa/aton:
foo.sin_addr.s_addr = inet_addr(cp);
-
inet_pton(AF_INET, cp, &foo.sin_addr);
inet_aton(cp, &foo.sin_addr);
-
inet_pton(AF_INET, cp, &foo.sin_addr);
ptr = inet_ntoa(foo.sin_addr);
-
char str[INET_ADDRSTRLEN];
ptr = inet_ntop(AF_INET, &foo.sin_addr, str, sizeof(str));
===================
struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
size_t ai_addrlen;
struct sockaddr *ai_addr;
char *ai_canonname;
struct addrinfo *ai_next;
};
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
void freeaddrinfo(struct addrinfo *res);
const char *gai_strerror(int errcode);
The members ai_family, ai_socktype, and ai_protocol have the same meaning
as the corresponding parameters in the socket(2) system call. The getad-
drinfo(3) function returns socket addresses in either IPv4 or IPv6 address
family, (ai_family will be set to either AF_INET or AF_INET6).
The hints parameter specifies the preferred socket type, or protocol. A
NULL hints specifies that any network address or protocol is acceptable.
If this parameter is not NULL it points to an addrinfo structure whose
ai_family, ai_socktype, and ai_protocol members specify the preferred
socket type. AF_UNSPEC in ai_family specifies any protocol family (either
IPv4 or IPv6, for example). 0 in ai_socktype or ai_protocol specifies
that any socket type or protocol is acceptable as well. The ai_flags mem-
ber specifies additional options, defined below. Multiple flags are spec-
ified by logically OR-ing them together. All the other members in the
hints parameter must contain either 0, or a null pointer.
The node or service parameter, but not both, may be NULL. node specifies
either a numerical network address (dotted-decimal format for IPv4, hex-
adecimal format for IPv6) or a network hostname, whose network addresses
are looked up and resolved. If hints.ai_flags contains the AI_NUMERICHOST
flag then the node parameter must be a numerical network address. The
AI_NUMERICHOST flag suppresses any potentially lengthy network host
address lookups.
The getaddrinfo(3) function creates a linked list of addrinfo structures,
one for each network address subject to any restrictions imposed by the
hints parameter. The ai_canonname field of the first of these addrinfo
structures is set to point to the official name of the host, if
hints.ai_flags includes the AI_CANONNAME flag. ai_family, ai_socktype,
and ai_protocol specify the socket creation parameters. A pointer to the
socket address is placed in the ai_addr member, and the length of the
socket address, in bytes, is placed in the ai_addrlen member.
If node is NULL, the network address in each socket structure is initial-
ized according to the AI_PASSIVE flag, which is set in hints.ai_flags.
The network address in each socket structure will be left unspecified if
AI_PASSIVE flag is set. This is used by server applications, which intend
to accept client connections on any network address. The network address
will be set to the loopback interface address if the AI_PASSIVE flag is
not set. This is used by client applications, which intend to connect to
a server running on the same network host.
If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are
returned in the list pointed to by result only if the local system has at
least has at least one IPv4 address configured, and IPv6 addresses are
only returned if the local system has at least one IPv6 address config-
ured.
If hint.ai_flags specifies the AI_V4MAPPED flag, and hints.ai_family was
specified as AF_INET6, and no matching IPv6 addresses could be found, then
return IPv4-mapped IPv6 addresses in the list pointed to by result. If
both AI_V4MAPPED and AI_ALL are specified in hints.ai_family, then return
both IPv6 and IPv4-mapped IPv6 addresses in the list pointed to by result.
AI_ALL is ignored if AI_V4MAPPED is not also specified.
service sets the port number in the network address of each socket struc-
ture. If service is NULL the port number will be left uninitialized. If
AI_NUMERICSERV is specified in hints.ai_flags and service is not NULL,
then service must point to a string containing a numeric port number.
This flag is used to inhibit the invocation of a name resolution service
in cases where it is known not to be required.
==============
int getnameinfo(const struct sockaddr *sa, socklen_t salen,
char *host, size_t hostlen,
char *serv, size_t servlen, int flags);
The getnameinfo(3) function is defined for protocol-independent
address-to-nodename translation. It combines the functionality
of gethostbyaddr(3) and getservbyport(3) and is the inverse of
getaddrinfo(3). The sa argument is a pointer to a generic socket address
structure (of type sockaddr_in or sockaddr_in6) of size salen that
holds the input IP address and port number. The arguments host and
serv are pointers to buffers (of size hostlen and servlen respectively)
to hold the return values.
The caller can specify that no hostname (or no service name) is required
by providing a NULL host (or serv) argument or a zero hostlen (or servlen)
parameter. However, at least one of hostname or service name must be requested.
The flags argument modifies the behaviour of getnameinfo(3) as follows:
NI_NOFQDN
If set, return only the hostname part of the FQDN for local hosts.
NI_NUMERICHOST
If set, then the numeric form of the hostname is returned.
(When not set, this will still happen in case the node's name
cannot be looked up.)
NI_NAMEREQD
If set, then a error is returned if the hostname cannot be looked up.
NI_NUMERICSERV
If set, then the service address is returned in numeric form,
for example by its port number.
NI_DGRAM
If set, then the service is datagram (UDP) based rather than stream
(TCP) based. This is required for the few ports (512-514) that have different
services for UDP and TCP.
=================
Modified IPv6-aware C code:
struct addrinfo *res, *aip;
struct addrinfo hints;
int sock = -1;
int error;
/* Get host address. Any type of address will do. */
bzero(&hints, sizeof(hints));
hints.ai_flags = AI_ALL|AI_ADDRCONFIG;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(hostname, servicename, &hints, &res);
if (error != 0) {
(void) fprintf(stderr,
"getaddrinfo: %s for host %s service %s\n",
gai_strerror(error), hostname, servicename);
return (-1);
}
/* Try all returned addresses until one works */
for (aip = res; aip != NULL; aip = aip->ai_next) {
/*
* Open socket. The address type depends on what
* getaddrinfo() gave us.
*/
sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol);
if (sock == -1) {
perror("socket");
freeaddrinfo(res);
return (-1);
}
/* Connect to the host. */
if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) {
perror("connect");
(void) close(sock);
sock = -1;
continue;
}
break;
}
freeaddrinfo(res);
Note that for new applications, if you write address-family-agnostic data structures,
there is no need for porting.
However, when it comes to server-side programming in C/C++, there is an additional wrinkle.
Namely, depending on whether your application is written for a dual-stack platform, such
as Solaris or Linux, or a single-stack platform, such as Windows, you would need to
structure the code differently.
Here's the corresponding server C code for a dual-stack platform:
int ServSock, csock;
/* struct sockaddr is too small! */
struct sockaddr_storage addr, from;
...
ServSock = socket(AF_INET6, SOCK_STREAM, PF_INET6);
bind(ServSock, &addr, sizeof(addr));
do {
csock = accept(ServSocket, &from, sizeof(from));
doClientStuff(csock);
} while (!finished);
|
