Version 3 (modified by papril, 14 years ago)


Problems in V1

  • Too many connections to the authentication server (one per connected client every x minutes)
  • Remove ClientTimeout. All decisions regarding a client timeout should be decided by the auth server
  • wdctl restart adds a lot of dirty code for it to work. (if we download the configuration periodically from the auth server, we don't need the wdctl restart anymore)
  • Firewall abstraction was done quickly
  • No QoS support
  • Doesn't verify that the FW modules work (unless you use the shell script wifidog-init provided, Linux only)
  • Protocol is too simplistic, not flexible, proprietary
  • Wifidog doesn't open internet connection when auth server is not available (needs a policy when that happens.... allow all or deny all)

Proposed V2 features

  • Configuration downloaded from auth server on startup (and periodically) including "who should be connected" (so it gets back to where it was on a restart)
  • QoS support
  • Versioned and more standard protocol
  • Better URLs (RESTful philosophy?)

Proposed architecture and ideas


Main program

  • Launches a "status" or "authserv" thread
  • It waits for the status thread to download the configuration succesfully before initializing networking and denying clients
  • Once initialized, it waits for connections on its port (redirected from firewall) ** Handles traffic the same way as before (forward to login page... gets back a token later, tests the token with the auth server, applies firewall rules)

Status thread

  • Contacts the auth server and sends status every 5 minutes (default)
    • Wifidog uptime
    • System uptime
    • System free memory
    • System load average
    • Other stats...
    • Currently connected clients
      • Incoming bandwidth statistics
      • Outgoing bandwidth statistics
      • QoS settings
      • Specific firewall rules
  • If auth server can't be contacted for some reason, retry faster (30 seconds maybe)
  • If it failed contacting the auth server twice, apply the "what to do when the internet is down" policy (either "allow" or "reject but explain what's going on")
  • When it receives the status from the auth server, it will also receive a list of "who's supposed to be connected". It will do a DIFF of this with what it has to remove/add who should be there

Things tested

JSON for protocol

XML or YAML would have been great, but I tried to use Syck ( and it didn't seem trivial to use, it looks like it supports a stream parser, we need something more like a DOM to find values returned.

JSON (with json-c-0.7) gives us that in C and is quite elegant.

Here's how we can generate JSON:

struct json_object *status_object = json_object_new_object();
json_object_object_add(status_object, "wifidog_version", json_object_new_string(VERSION));
json_object_object_add(status_object, "protocol_version", json_object_new_double(2.0));
json_object_object_add(status_object, "node_id", json_object_new_string(node_id));
json_object_object_add(status_object, "fetch_config", json_object_new_boolean(1));

struct json_object *node_status_object = json_object_new_object();
json_object_object_add(node_status_object, "wifidog_uptime", json_object_new_int(25));
json_object_object_add(node_status_object, "sys_uptime", json_object_new_int(get_sys_uptime()));
json_object_object_add(node_status_object, "sys_loadavg", json_object_new_double(get_sys_loadavg()));
json_object_object_add(node_status_object, "sys_memfree", json_object_new_int(get_sys_memfree()));

char * json = json_object_to_json_string(status_object);

It returns the JSON string.

To parse:

struct json_object * json_object = json_tokener_parse(the_string);
struct json_object * value_json_object = json_object_object_get(json_object, "node_id");
printf("%s\n", json_object_get_string(value_json_object));

This will retrieve the string value of "node_id" at the first level in the tree.