How to test the re6st-node package

Here are some manual tests one can perform when testing a new re6st package. It is assumed the code has already been sufficiently tested with the re6st demo.

Test re6st update

Making sure re6st can update properly without manual assistance is very important, as failure to do so could break a whole re6st network when updating. Install the package on a computer already running a working re6st. Multiple re6stnet configurations can be tested, but one configuration with max-clients > 0 and client-count > 0 should at least be tested. To debug properly, include these lines in your re6stnet.conf:

# increase re6stnet verbosity:
verbose 3
# enable OpenVPN logging:
ovpnlog
# increase OpenVPN verbosity:
O--verb
O3

Test re6stnet service

After installing or upgrading re6st-node, the re6stnet service should be enabled and active by default

systemctl is-enabled re6stnet && systemctl is-active re6stnet

You should also check that the service was restarted properly, you can use checkrestart command from debian-goodies package

Test if processes spawned correctly and interfaces are setup

ps auxf | grep re6stnet

ip link

There should be at least one re6stnet process and babeld process running after update. If max-clients is non-zero, a re6stnet-tcp interface should be setup, and if client-count is non-zero, re6stnetX interfaces should start appearing as tunnels are made. Each interface has a openvpn process with --dev <interface-name> associated to it, and an entry in ip link output.

The loopback interface (or the interface specified with the interface option) should have a re6st global IPv6 assigned.

Check logs for error:

Go to /var/log/re6stnet/ and check re6stnet.log. You can search for "Traceback" to check if python errors occured. Note that not all errors indicate abnormal re6st, for instance:

Traceback (most recent call last):
  File "/opt/re6st/eggs/re6stnet-0.568-py2.7.egg/re6st/registry.py", line 742, in rpc
    n = len(h) // 2

TypeError: object of type 'NoneType' has no len()

This error means the node didn't get an answer when contacting the registry, which could be due to a temporary network downtime unrelated to the upgrade

Test default route

After a few moments, re6st should choose an interface for the default route

ip -6 route | grep default

If default parameter is set in re6stnet conf:

ping -6 google.com

Else you can try to directly ping the neighbour at the other end of the re6st tunnel and see if you receive a duplicate packet

ping -6 ff02::1%<default-interface>

Test new re6st install

Install re6st-node on a computer with empty /etc/re6stnet folder, and which didn't previously have re6st

Test re6st-conf

re6st-conf --fingerprint ALG:FINGERPRINT --registry URL -d /etc/re6stnet --token TOKEN

 Check P-VIFIB-Re6stnet for fingerprint and url information. For instance the command for trial network is:

sudo re6st-conf --fingerprint sha256:499a44702d687e968c047d28e33f59e5c3bae71a38619dc730152a3557c20301 --registry http://re6stnet.gnet.erp5.cn/ --dir /etc/re6stnet/ --token TOKEN

/etc/re6stnet should contain:

ca.crt  cert.crt  cert.key  re6stnet.conf

Check re6stnet.conf contents:

registry <registry-url>
ca <path-to-ca>
cert <path-to-cert>
key <path-to-key>
# increase re6stnet verbosity:
#verbose 3
# enable OpenVPN logging:
#ovpnlog
# uncomment the following 2 lines to increase OpenVPN verbosity:
#O--verb
#O3

Redo the tests from previous section

Check processes are spawned correctly, check interfaces, check the logs and the default route

Check the cache

You can check the cache is being correctly populated with addresses by dumping the contents of the peer table in /var/lib/re6stnet/cache.db

sqlite3 /var/lib/re6stnet/cache.db 'SELECT * FROM peer;'