doc/developer/WiFiDog_V2

Version 2 (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

Proposed architecture and ideas

Threads

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