Member EPS::ClientHull::async_read_tun_tap (void)

See this regression in kernel 3.19 and above: https://bugzilla.kernel.org/show_bug.cgi?id=96381 The problem is the tun/tap API is incorrectly returning 0 bytes instead of EAGAIN when nothing is available to read. To work around this, let's insert increasingly long pauses if the error is EOF.

Member EPS::ClientHull::process_tun_tap_packet (EPS::NetBuffer *nb)

check to see if the UDP channel is up

send this packet over UDP instead of TCP

Member EPS::Hull::start_async_accept (void)

fixme: even if the pool is empty, if this client has a reserved ip address we still need to accept it

Member EPS::Hull::start_signal_handling (void)

define our own error category derived from error_category

Member EPS::log_backtrace (void)

why does this not compile in clang/pc-bsd?

Member EPS::parse_network_and_mask (const std::string &str, IPv4 &network, IPv4 &netmask)

only 24-bit "class C" networks are currently supported

Member EPS::ServerHull::processComm (const EPS::TConnPtr &connection, EPS::NetBuffer *nb, const EPS::CommHeader1 *header, const EPS::ECommType type)

If we only decrypted enough to read the full CommData1 header, then we wouldn't have to decrypt the entire buffer. We'd have the destination to which the encrypted packet needs to be sent. But at the moment we either decrypt just the common header or the entire packet.

Member EPS::ServerHull::setup_address_pool (void)

this will need to be changed once we support anything other than a simple /24

Member EPS::set_tun_tap_routes (const uint32_t &network_in_network_order, const uint32_t &netmask_in_network_order, const std::string &device_name)

routes not needed at this point in time

Member EPS::TrackerData::eps_uptime

I dislike the mix of std::chrono and time_t, but I'm not yet familiar enough with std::chrono to make it do exactly what I want.

Member EPS::validate_network_against_existing_routes (const uint32_t &eps_network_in_host_order, const uint32_t &eps_netmask_in_host_order)

Need to find a way to get the existing routes in FreeBSD so we can validate the new EPS address.