QA/Networking/Server software

Server operations

A networking server typically listens for new connections from clients. Basic operation doesn't require any name resolution as the server can listen on wildcard addresses.

Address list generation phase

Many servers support listening on specific local IPv4 and IPv6 addresses. It is especially useful for running multiple instances on one host, but it is also used as a security measure for example to limit scope to the local host. Although configuration typically includes literal addresses, it may be useful to use actual domain names like localhost or even those from DNS, provided that they are immediately resolvable using the local infrastructure.

Typical configuration situations:

• no configuration – server listens on :: and 0.0.0.0
• localhost – server listens on ::1 and 127.0.0.1
• list of domain names or literal IP addresses – server listens on listed or resolved IP addresses

Known issues:

• Fedora by default enables dual-stack sockets on ::0 address and therefore explicit listening on both wildcard addresses doesn't work as intended.

Query using getaddrinfo()

struct addrinfo hints = { .ai_flags = AI_PASSIVE };
struct addrinfo *res;
int status;

status = getaddrinfo(nodename, servname, &hints, &res);

Note: AI_PASSIVE option ensures NULL nodename is translated to :: and 0.0.0.0.

Note: You need to explicitly set IPV6_V6ONLY socket option on all IPv6 sockets to avoid conflict between an IPv4 and an IPv6 socket.

Binding and listening phase

Server should listen on all addresses from the previous phase.

Accepting clients phase

A dual-stack server accepts connections from clients of both protocols. It often needs to cope with both types of addresses for logging and access control purposes.

Related library calls:

• accept()
• getsockname()

Test cases

Testing servers is a bit more complicated in that different servers use IP addresses in different ways. So the test cases below are rather vague and must be adapted to specific server packages.

Loopback, IPv6 only server

Connectivity	IPv4	Any (loopback address wanted)
	IPv6	Any except disabled (loopback address required)
Other		Server software only listens on IPv6.

What is tested

• Ability to accept IPv6 connections.
• Correct handling of IPv6 loopback clients.

Steps to reproduce

1. Connect a client using localhost hostname.
2. Check server log for IPv6 connection.
3. Check successful operation.

Expected result

• Client connects to server using ::1 address.
• Server accepts the client connection and operates correctly.

Bad result

• Server refuses to serve the client e.g. due to access lists

containing only IPv4 loopback.

Remote client connected over IPv4

Source connectivity	IPv4	Global or masqueraded
	IPv6	None
Target connectivity	IPv4	Global
	IPv6	Global

What is tested

• Whether the software accepts IPv4 connections.

Steps to reproduce

• Connect a client via IPv4.
• Check server logs for connection details.
• Check successful operation.

Expected result

• Client connects using its IPv4 address or using

external IPv4 addresses of a NAT device.

• Server accepts the client connection and operates correctly.

Note: An IPv4-mapped IPv6 addres in the log is generally accepted but should be printed in a way showing the actual IPv4 address.

Bad result

• Server doesn't accept the connection, reports wrong connection data or fails to operate correctly.

Remote client connected over IPv6

Source connectivity	IPv4	None
	IPv6	Global
Target connectivity	IPv4	Global
	IPv6	Global

What is tested

• Whether the software accepts IPv6 connections.

Steps to reproduce

• Connect a client via IPv6.
• Check server logs for connection details.
• Check successful operation.

Expected result

• Client connects using its IPv6 address.
• Server accepts the client connection and operates correctly.

Bad result

• Server doesn't accept the connection, reports wrong connection data or fails to operate correctly.