Simplify network setup

testcases/lib/tst_net_vars.c new file +16 -0

+
+static int read_prefix(const char *ip_str, int is_ipv6)
+{
+	uint8_t family = is_ipv6 ? AF_INET6 : AF_INET;
+
+	char buf[16384];
+	int len;
+
+	struct {
+		struct nlmsghdr nlhdr;
+		struct ifaddrmsg addrmsg;
+	} msg;
+
+	struct nlmsghdr *retmsg;
+
+	int sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);

testcases/lib/tst_net_vars.c new file +16 -0

+
+	while NLMSG_OK(retmsg, len) {
+		struct ifaddrmsg *retaddr;
+		struct rtattr *retrta;
+		char pradd[128];
+		int attlen;
+
+		retaddr = (struct ifaddrmsg *)NLMSG_DATA(retmsg);
+		retrta = (struct rtattr *)IFA_RTA(retaddr);
+		attlen = IFA_PAYLOAD(retmsg);
+
+		while RTA_OK(retrta, attlen) {
+			if (retrta->rta_type == IFA_ADDRESS) {
+				inet_ntop(family, RTA_DATA(retrta), pradd, sizeof(pradd));
+				if (!strcmp(pradd, ip_str))
+					return retaddr->ifa_prefixlen;

testcases/lib/tst_net_vars.c line 127

Quoted 3 lines

testcases/lib/tst_net_vars.c new file +3 -0

+	struct in_addr mask;
+
+	memset(&mask, 0, sizeof(mask));

FYI for these memsets you could use 'struct foo bar = { 0 }' instead. Although it generates warnings on older compilers if the struct starts with another composite data type.

Quoted 4 lines

testcases/lib/tst_net_vars.c new file +4 -0

+	struct {
+		struct nlmsghdr nlhdr;
+		struct ifaddrmsg addrmsg;
+	} msg;

testcases/lib/tst_net_vars.c line 499

Quoted 8 lines

testcases/lib/tst_net_vars.c new file +8 -0

+	msg.nlhdr.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifaddrmsg));
+	msg.nlhdr.nlmsg_flags = NLM_F_REQUEST | NLM_F_ROOT;
+	msg.nlhdr.nlmsg_type = RTM_GETADDR;
+	msg.addrmsg.ifa_family = family;
+
+	send(sock, &msg, msg.nlhdr.nlmsg_len, 0);
+	len = recv(sock, buf, sizeof(buf), 0);
+	retmsg = (struct nlmsghdr *)buf;

No error checking? I suppose it is unlikely to fail, but it can't hurt.

Quoted 21 lines

testcases/lib/tst_net_vars.c new file +21 -0

+
+	while NLMSG_OK(retmsg, len) {
+		struct ifaddrmsg *retaddr;
+		struct rtattr *retrta;
+		char pradd[128];
+		int attlen;
+
+		retaddr = (struct ifaddrmsg *)NLMSG_DATA(retmsg);
+		retrta = (struct rtattr *)IFA_RTA(retaddr);
+		attlen = IFA_PAYLOAD(retmsg);
+
+		while RTA_OK(retrta, attlen) {
+			if (retrta->rta_type == IFA_ADDRESS) {
+				inet_ntop(family, RTA_DATA(retrta), pradd, sizeof(pradd));
+				if (!strcmp(pradd, ip_str))
+					return retaddr->ifa_prefixlen;
+			}
+			retrta = RTA_NEXT(retrta, attlen);
+
+		}
+		retmsg = NLMSG_NEXT(retmsg, len);

testcases/lib/tst_net_vars.c line 107

Quoted 5 lines

testcases/lib/tst_net_vars.c new file +5 -0

+	}
+
+	return -1;
+}
+

Thank you,
Richard.

Hi,

another version of tst_net_vars network setup helper.
v4->v5:
* Clenup unneded variables (reverse IP related).
* Don't require to have mask in IP address. Use netlink to detect prefix when address is presented on some of the NIC on the system or fallback to default ones (24 for IPv4, 64 for IPv6).
* Fix detecting wrong subnet with network not round up by 8 (IPv4 resp 16 (IPv6). E.g.: problem IP addressed like 10.2.0.1/22 10.2.1.1/22.
* Add more environment variables (e.g. prefix, whole IP address)
* Rewritten (again) unused network generation to fix overlap with used IP addresses.
* Simplify tst_ipaddr() (in testcases/lib/test_net.sh).
* Use tst_brk() to exit on error.
* Cleanup warnings and formatting.

There is still requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6) as then IPV{4,6}_NETWORK variables would be empty, which is not expected by tests (they join it with address separators with {L,R}HOST_IPV{4,6}_HOST. Even we got rid of reverse related variables we still need IPV{4,6}_NETWORK variables for some tests.

Quoted 16 lines · Petr Vorel

Hi,

another version of tst_net_vars network setup helper.
v4->v5:
* Clenup unneded variables (reverse IP related).
* Don't require to have mask in IP address. Use netlink to detect prefix when address is presented on some of the NIC on the system or fallback to default ones (24 for IPv4, 64 for IPv6).
* Fix detecting wrong subnet with network not round up by 8 (IPv4 resp 16 (IPv6). E.g.: problem IP addressed like 10.2.0.1/22 10.2.1.1/22.
* Add more environment variables (e.g. prefix, whole IP address)
* Rewritten (again) unused network generation to fix overlap with used IP addresses.
* Simplify tst_ipaddr() (in testcases/lib/test_net.sh).
* Use tst_brk() to exit on error.
* Cleanup warnings and formatting.

Quoted 5 lines

There is still requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6) as then IPV{4,6}_NETWORK variables would be empty, which is not expected by tests (they join it with address separators with {L,R}HOST_IPV{4,6}_HOST. Even we got rid of reverse related variables we still need IPV{4,6}_NETWORK variables for some tests.

Hi Petr,

But you removed such dependency on the prefix from test_net.sh in the third patch... so we could just print the warning that configuration is not appropriate for the old tests, that is for stress/multicast, stress/route groups only.

Regarding IPV{4,6}_NETWORK calculation, I believe it would much simpler ifwe saved the same part of address from IPV{4,6}_HOST variables to_NETWORK variable and what is differ to the other variables.There is no need to any additional checks for these environment variables or I'm missing something?

Hmm, I didn't find how the patch is getting network prefix on the remote host, is it because of the assumption that they should be the same on both hosts?

It is fine for now as it's
not so common for a test environment to have different ones, so the better approach in the future is to make a separate tool (installed on both hosts with LTP) and get prefixes from local and remote host similar to tst_get_hwaddrs() in test_net.sh.

Quoted 5 lines

There is still requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6) as then IPV{4,6}_NETWORK variables would be empty, which is not expected by tests (they join it with address separators with {L,R}HOST_IPV{4,6}_HOST. Even we got rid of reverse related variables we still need IPV{4,6}_NETWORK variables for some tests.

Hi Petr,

But you removed such dependency on the prefix from test_net.sh in the third patch... so we could just print the warning that configuration is not appropriate for the old tests, that is for stress/multicast, stress/route groups only.

Hi Alexey,

Quoted 10 lines

Quoted 5 lines

There is still requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6) as then IPV{4,6}_NETWORK variables would be empty, which is not expected by tests (they join it with address separators with {L,R}HOST_IPV{4,6}_HOST. Even we got rid of reverse related variables we still need IPV{4,6}_NETWORK variables for some tests.

Hi Petr,
But you removed such dependency on the prefix from test_net.sh in the third patch... so we could just print the warning that configuration is not appropriate for the old tests, that is for stress/multicast, stress/route groups only.

Right, I'll remove requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6). There are other restrictions you probably don't like:
* Don't use 32 (IPv4) and 128 (IPv6): I'd keep this restriction. What do you think?
* Require to use the same prefix: I'd keep it for now.

Quoted 4 lines

Right, I'll remove requirement network prefix to be < 8 (IPv4) resp. 16 (IPv6). There are other restrictions you probably don't like:
* Don't use 32 (IPv4) and 128 (IPv6): I'd keep this restriction. What do you think?
* Require to use the same prefix: I'd keep it for now.

I'm for a warning message that some network/stress tests not supporting such config.

BTW: I probably have source lines > 80 chars. My Vim doesn't highlight anything, but checkpatch.pl complain. I might have wrong vim configuration.

Hi,

Quoted 2 lines · On Wed, 3 May 2017 18:07:48 +0200 "Petr Vorel" <[email protected]> wrote:

BTW: I probably have source lines > 80 chars. My Vim doesn't highlight anything, but checkpatch.pl complain. I might have wrong vim configuration.

Are you using checkpatch.pl from kernel 4.11? It was recently changed to follow the actual style guidelines which say lines over 80 chars are preferable to strings being split over multiple lines. Maybe Vim is aware of that?

Quoted 6 lines

Quoted 2 lines

BTW: I probably have source lines > 80 chars. My Vim doesn't highlight anything, but checkpatch.pl complain. I might have wrong vim configuration.

Are you using checkpatch.pl from kernel 4.11? It was recently changed to follow the actual style guidelines which say lines over 80 chars are preferable to strings being split over multiple lines. Maybe Vim is aware of that?

Or may be vim's configuration has wrong tab size, should be 8 characters for Linux coding style.