This page is used to collect the feature requests for Wifidog The Next Generation and help organize the work related to that project.

Context -from the mailing list:

Text from email by Sylvain Carle - Board Member of ISF: "As some of you already know, we have been drafting a plan for the next version of wifidog, dubbed Wifidog TNG (the next generation).

We organized a few conference calls with other wifi orgs (Zap Québec, Zap Sherbrooke and other upcoming ZAPs) as well as with NYC Wireless and Wireless Toronto to collect as much as input as possible and gather consensus for future direction. I (SylvainCarle) also had good one-on-one chats with Benoit Grégoire, François Proulx and the current (and past) ISF board members. This is is first draft of the objectives for wifidog 2.0

A few principles first. This is to be a process as inclusive as possible, it's open for contribution to any able and willing developer. It will be organized from the current Trac ticket system and wiki (see a copy of this email at

There is a deadline for the first 2.0 release in August as several groups will need the new features for specific fall projects. As such, some ideas might be great but not consider for inclusion in the first release. A schedule for point releases (2.1, 2.2, etc) shall be discussed here but the goal is to be consistent with stable and supported releases and an "edge" version.

Goal : make wifidog easier to integrate with other related opensource projects."

features cut and added to list of key requirements below: <snip>

Thoughts on Next Generation: (please add more!)

  • Be backward compatible and build on the excellent core we already have
  • Integrate / "play nice" with other related tools (wifi, networking, authentification, content management, etc.)
  • Have two version, one "mini" for limited capacity hardware (as used in many existing installations worldwide, WRTG et al) and one "maxi" for more modern hardware (with much more processing power + memory)
  • Target platform: OpenWRT (Pyramid Linux as #2 and Sky OS as possible #3, we should also look at a deb/ubuntu packaging maybe)
  • Better reporting + integration with external graphing/reporting tools
  • Consolidate security patches and new ROM images
  • Support several modes: Authentification, Agreement et Content+Redirect
  • Development of a geolocation API for session/content/context
  • Integration with open source CMS for portal pages (via plugins): Wordpress is first candidate (Drupal and Pylons are considered) (see WifidogAPI for a discussion on the api)
  • Doc. the stack : Auth Server (hub), Gateway (node) and CMS (api)
  • Developing "ZAP in a Box" for new cities/regions (make it easier to start a new wireless orgs)
  • Exploration of MESH and other hardware
  • Updating routers remotely.
  • Increase throttling support (simultaneous connections per client, per-hotspot daily schedule, etc.
  • Integration with meshing protocols and management.
  • Ability to group nodes in different ways (several nodes per "hotspot", serveral hotspots in a group, overlaping groups, etc.).
  • Federation
  • Ability to use MySQL (database abstraction)
  • Reporting (to hotspot owners)

* Should play nice with latest linux linksys router (N), WRT160NL.

Thoughts snipped from Robin Jones's email on the mailing list:

"First of all, in order to ramp up the development of V2, or even finish V1, we need to get more people to:

a) send in more patches b) aid more in the testing of what has been achieved.

Also, we need more people with development skills in the following areas:

  • a) Graphic Design: I have worked hard to make the GUI more appealing and easier to understand, but I am no graphic designer by any means. Also I feel that I have received no feedback on the changes that have been made, so I can't continue to improve what I have already done.
  • b) Scripting: If someone could script the setup of WiFiDog auth, so that it makes sure all of the perquisites are installed, creates the necessary folders if they don't exist, and invokes install.php, for as many distributions as possible, I think that both the current community and new members will be most grateful
  • c) More ideas and concept GUIs for easier navigation of the auth server, I have always thought that there should be a tree view on the right-hand side which drills down by Server > Networks > Venues > Nodes, with the view being restricted by permissions.
  • d) Documentation Writers: All the information is there, it is just hard to find what you need, this needs to be compiled and corrected, also lots more developer documentation would make it easier for people to get involved.

From Gabe Sawhney from the dev list:

  • accommodate the WRT54G investment that our venue partners have already made, as well as allow us to manage the (probably) ROBIN-based routers that we'll start deploying"
  • more intelligence on the gateway side, so that users are still able to get online if the router can't find the server.
  • interested in stepping away from an authentication model, and move towards one of (bandwidth) accounting. (Whereby users are only required to authenticate if they cross a bandwidth usage threshold.) This approach would improve the usability of our network (giving us a distinct advantage over commercial WISPs), it would reduce support requests, maybe make building out a mesh easier, and make our network finally not-totally-annoying for users on mobile devices.

Information about related tools on