Re6st Home Re6st

    How to test re6st-node Package

    • Last Update:2022-07-13
    • Version:001
    • Language:en

    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:
    # increase OpenVPN verbosity:

    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/", 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

    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 --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:
    # uncomment the following 2 lines to increase OpenVPN verbosity:

    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;'