Traffic monitoring on LibreMesh

# Traffic monitoring on LibreMesh Keeping track of how much traffic each client is consuming is relevant for many purposes: monitoring, accountability, troubleshooting. This tends to be trivial in traditional networks (conntrack using IPTables), but in our situation it can be tricky because we have three kinds of traffic: * the one that passes through the mesh (batman-adv or babeld), * the one that goes to the node * the one that goes from the clients to the internet We are interested in keeping track: * how much traffic is produced by a node * how much traffic is handled by a node One way of working with this is by agregating the traffic that is generated by the hosts that are connected to the network using the IP leases of the DHCP server. This has the added advantage of allowing us to keep track of the consumption of clients across nodes, by agregating the traffic using [shared-state](https://github.com/libremesh/lime-packages/tree/master/packages/shared-state/). ## Draft of trying to track all connections In future iterations of this research we will try to have this problem solved. In order to get the current leases, we can obtain them by catting /tmp/dhcp.leases We have: * roaming IPs: IP address that come configured by a neighbour node and because the client has changed nodes but not re-requested IP we will not notice this. This can only happen if nodes are connected via the open AP config of the mesh nodes, or a similar configuration, or fixed IPs. Clients can connect to the network in via three scenaries: * Wifi Association only event: this is the case of a node that has fixed IP address or is roaming. * DHCP Lease only event: This is the case of a client connected via wired connection * Wifi association and DHCP lease events combined: this is the case when a client connects to the open hotspot provided by the node. In all of these cases we have access to the MAC address, so we can use it to track the connections. ## Track general traffic For now we will work on the traffic that each node generates. The local traffic consumption can be agregated by adding the traffic from these interfaces: br-lan, wlan0-ap, wlan0-apname, wlan1-ap, wlan1-apname. https://openwrt.org/packages/pkgdata/ulogd https://home.regit.org/wp-content/uploads/2013/03/ulogd2.pdf https://netfilter.org/projects/ulogd/index.html https://www.wzdftpd.net/blog/ulogd2-the-new-userspace-logging-daemon-for-netfilteriptables-part-2.html https://mohskitchen.wordpress.com/2012/08/27/accounting-with-ulogd-2-and-conntrack-on-a-gbit-nat/ ## Netflow Some basics: https://www.auvik.com/franklymsp/blog/netflow-basics/ https://casualhacking.io/blog/2009/12/17/fun-with-home-network-forensics.html ``` What Data are we collecting: Cisco NetFlow data includes simple header data about network communication. The network traffic is summarized into 'flows' or communications. So if you start up a TCP connection with your favorite video game and play for 20 minutes, that'll be 1 flow. The flow includes Source/Destination IP and Port, start/end time, flags, protocol, packets, and bytes and more. What the flows do no include are payload information. T ```