aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/ipv4_ipv6.txt223
-rw-r--r--docs/new-applet-HOWTO.txt3
2 files changed, 2 insertions, 224 deletions
diff --git a/docs/ipv4_ipv6.txt b/docs/ipv4_ipv6.txt
deleted file mode 100644
index 92010b59c..000000000
--- a/docs/ipv4_ipv6.txt
+++ /dev/null
@@ -1,223 +0,0 @@
-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. */
- memset(&hints, 0, 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);
diff --git a/docs/new-applet-HOWTO.txt b/docs/new-applet-HOWTO.txt
index 37a78e95b..6f89cbe1d 100644
--- a/docs/new-applet-HOWTO.txt
+++ b/docs/new-applet-HOWTO.txt
@@ -46,6 +46,7 @@ int mu_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
int mu_main(int argc, char **argv)
{
int fd;
+ ssize_t n;
char mu;
fd = xopen("/dev/random", O_RDONLY);
@@ -123,7 +124,7 @@ lib-$(CONFIG_MU) += mu.o
Add the applet to Config.in in the chosen directory:
-config CONFIG_MU
+config MU
bool "MU"
default n
help