Design Document: Check the FFH Functionality

[lemoer]

Design Document: Check the FFH Functionality

The goal is to test the functionality of the backend of Freifunk Hannover.

Specification

Checks that should be performed

1. Check if an IP address can be obtained via DHCP.
2. Check if that IP address works to reach the internet (ping).
3. Check if ==sufficient bandwidth*== is available via that IP.
4. Check if the DNS Server from the DHCP lease works.
5. Check if an IPv6 address can be obtained via SLAAC.
6. Check if that IPs address works to reach the internet (ping).
7. Check if ==sufficient bandwidth*== is available via that IPv6.
8. Check if the DNS Server from the SLAAC lease works.

Modalities of the Checks

• Checks should be performed on a regular basis: once per hour.
• Checks should be performed for every domain.
• Checks should be performed for every supernode individually.
• Failing checks should trigger a Zabbix Problem State.

==* = yet inaccurate specification, should be discussed==

Technological Challenges

1. Access to all domains is necessary.
2. Broadcast DHCP requests will be redirected (as unicast packets) to the "selected" gateway by a batman mechanism. Testing specific supernodes is therefore a challenge.
3. Multiple IPv6 addresses from different gateways will be obtained via SLAAC.
   • (Especially without gluon-radv-filterd.)
   • IPv6 addresses from different gateways also have different default routes.
   • Managing the differnt IPs and different default routes will be dificult.
   • Testing specific supernodes is therefore a challenge.
4. A list of "operative" supernodes (that should be tested) must be obtained.
   • Maybe even additional metadata for them must be available. (like e.g. the mac address of that supernode on batX).
5. I am not really sure, how we can obtain the DNS-Server from SLAAC. If we use the autoconfiguration from linux, it will probably not use or obtain the DNS-Server from the router advertisement.

Addressing the Technological Problems

1. Use harvester, which has access to all domains.
2. Use unicast DHCP. Then batmans mechanism does not kick in and we can test specific supernodes.
   • There is check_dhcp.c from FreifunkBremen, which does that.
3. Block all traffic except from one supernode via IP6Tables.
   • (They mac of that supernode is needed.)
   • ==Does this really work as we expect?==
4. ==(TBA)== ???
5. ==(TBA)== ???

==TBA = To Be Addressed==

Test Flow

Specified Inputs: Supernode to be tested, Domain to be tested.

1. Create a macvtap on top of batX.
2. Move that macvtap to a network namespace (to have isolated conditions).
3. Block all traffic from everything except for the mac of the supernode to be tested via ip6tables. (To avoid accepting wrong SLAAC information.)
4. Try to obtain a DHCP lease via unicast DHCP.
   • If this works:
     1. Assign that IP and default route.
     2. Ping 8.8.8.8 with that IP
        • If this works:
          1. Test bandwidth (somehow??? yet unclear???)
             • If this works: passed.
             • If this doesn't work: IPv4 Bandwidth Test failed.
        • If this doesn't work:
          • IPv4 Internet Reachabilty Check failed.
          • Do not check perform the bandwidth check. It will fail anyways.
     3. Try to resolve "google.com" via the DNS-Server from the DHCP lease.
        • If this works: passed.
        • If this doesn't work: IPv4 DNS failed.
   • If this doesn't work: IPv4 DHCP failed.
     • Do not do any more IPv4 tests. They are pointless without a working DHCP.
5. Try to obtain an IPv6 via SLAAC.
   • Wait for a timeout.
   • If this works:
     1. Assign that IP and default route.
     2. Ping 2001:4860:4860::8888 with this IP
        • If this works:
          1. Test bandwidth (somehow??? yet unclear???)
             • If this works: passed.
             • If this doesn't work: IPv6 Bandwidth Test failed.
        • If this doesn't work:
          • IPv6 Internet Reachabilty Check failed.
          • Do not check perform the bandwidth check. It will fail anyways.
     3. Try to resolve "google.com" via the DNS-Server from the router advertisement.
        • If this works: passed.
        • If this doesn't work: IPv6 DNS failed.
   • If this doesn't work:
     • IPv6 SLAAC failed.
     • Do not do any more IPv6 tests. They are pointless without a working SLAAC.
6. Leave the network namespace and destroy it.

Used Techologies

• linux kernel
• macvtap
• network namespaces
• check_dhcp.c from FreifunkBremen

Open Questions

• How do we check for bandwidth?
  • Iperf3 internally? Download a blob from a webserver?
  • What bandwidth do we consider as sufficient?
• How do we create multiple test results for zabbix from a single programm run?

Open Questions Leo:

• Check if the IPv6 RA Filtering via IP6Tables works as expected.
• How do we obtain the MAC of the supernodes in a domain a priori?

Design Consequences

• The software could also be used if there is only access to a single domain.
  • Still, this software can be used to test all supernodes in that domain.
• This software can be used even without having a direct VPN connection to each supernode.
  • But of course, it will rely on cross-traffic then.

[CodeFetch]

I had a Raspberry Pi with a WiFi USB stick in Essen connected to a Freifunk router which it controlled via PySSH to change the configuration and test all supernodes including speedtests. This way you don't need to maintain additional stuff and can have this setup at multiple sites with different internet providers and actually see whether Gluon nodes have a proper connection.