Page MenuHomeFreeBSD

Add tests verifying IPv4/IPv6 output for TCP/UDP/raw paths.
ClosedPublic

Authored by melifaro on Mar 20 2020, 3:30 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Dec 22, 9:41 AM
Unknown Object (File)
Thu, Dec 19, 7:04 PM
Unknown Object (File)
Thu, Dec 19, 3:45 PM
Unknown Object (File)
Fri, Dec 6, 10:50 AM
Unknown Object (File)
Nov 20 2024, 3:29 PM
Unknown Object (File)
Nov 20 2024, 3:21 PM
Unknown Object (File)
Nov 20 2024, 1:34 PM
Unknown Object (File)
Nov 12 2024, 10:29 PM

Details

Summary

Add basic tests verifying most common output codepaths for TCP,UDP and raw sockets.

Each test is implemented in 2 vnet jails, interacting over epair interface(s).
Multipath tests currently do not work on stock -head.

Test Plan
kyua test -k /usr/tests/sys/netinet/Kyuafile output
output:output_raw_flowid_mpath_success  ->  passed  [0.462s]
output:output_raw_success  ->  passed  [0.083s]
output:output_tcp_flowid_mpath_success  ->  passed  [1.889s]
output:output_tcp_setup_success  ->  passed  [0.171s]
output:output_udp_flowid_mpath_success  ->  passed  [9.382s]
output:output_udp_setup_success  ->  passed  [1.265s]
kyua test -k /usr/tests/sys/netinet6/Kyuafile output6
output6:output6_raw_flowid_mpath_success  ->  passed  [2.224s]
output6:output6_raw_success  ->  passed  [1.904s]
output6:output6_tcp_flowid_mpath_success  ->  passed  [2.817s]
output6:output6_tcp_setup_success  ->  passed  [1.753s]
output6:output6_udp_flowid_mpath_success  ->  passed  [5.127s]
output6:output6_udp_setup_success  ->  passed  [3.138s]

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

melifaro edited the test plan for this revision. (Show Details)
melifaro added reviewers: network, transport, kp.
tests/sys/common/vnet.subr
16 ↗(On Diff #69719)

Do we need this? We should already be adding epair0a to created_interfaces.lst, and deleting that one deletes epair0b as well.

tests/sys/common/vnet.subr
16 ↗(On Diff #69719)

In short, yes.

Currently, there is no guarantee that jail is destroyed upon return of the jail -r cmd. For example, when some connections inside the jail are in TIME_WAIT state, destruction is delayed till fin_wait2 timeout. As a result, interface may appear in the host jail only after 60 seconds.

Please take a look at the following example:

#!/bin/sh


epair=$(ifconfig epair create)
jail_name=j-`date +%s`
jail -c name=${jail_name}a persist vnet vnet.interface=${epair}
jail -c name=${jail_name}b persist vnet vnet.interface=${epair%a}b
jexec ${jail_name}a ifconfig ${epair} inet 192.168.0.1/24
jexec ${jail_name}b ifconfig ${epair%a}b inet 192.168.0.2/24
jexec ${jail_name}b nc -l 4242 &
sleep 0.1
echo test | jexec ${jail_name}a nc -Nn 192.168.0.2 4242
jexec ${jail_name}a netstat -an
jail -r ${jail_name}a
jail -r ${jail_name}b
sleep 0.1
ifconfig -l
echo ----
jls -N
echo ----
jls -dN
echo Sleeping..
sleep 58
ifconfig -l
sleep 3
ifconfig -l

It outputs

test
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 192.168.0.1.48519      192.168.0.2.4242       TIME_WAIT
em0 em1 em2 lo0 epair0b
----
 JID             IP Address      Hostname                      Path
----
 JID             IP Address      Hostname                      Path
 j-1584786208a                                                 /
Sleeping..
em0 em1 em2 lo0 epair0b
em0 em1 em2 lo0 epair0b epair0a

@bz could you consider taking a look?

tests/sys/common/vnet.subr
16 ↗(On Diff #69719)

Let me put it differently: it does not guarantee that interface won't be leaked but increases this possibility.

I'd prefer to have the proper solution but was unable to find one.

  • shutting down interface does not help
  • removing interface alias does not help
  • destroying inside the jail does not work
  • jail -m for vnet.interface - not sure how this would work, as there can be multiple interfaces
  • time_wait can be reduced to hunderds of milliseconds but that looks like another workaround.

Thanks for the explanation. That makes sense.

This revision is now accepted and ready to land.Mar 21 2020, 11:04 AM