George's Research

The current information here builds on content that has been transferred from the more technically-oriented of mine, WISP Coova phpmyprepaid link to this page.

Overview on ISP requirements/specifications

This section attempts to formulate a basic set of specifications for an ISP (billing / services / etc), and assumptions taken regarding these specs during technical implementation described in the next section. Some of the information here is also based on that gathered by Henk Kotze.

High level definition of use cases

From ISP manager's point of view:

• Web based user interface, that provides seamless access to all required tools and efficient enough to require very little use of commands/text-based configuration.
• ISP manager gets all info and set up radius, etc....
• Linksys should be preconfigured by ISP manager

From Client's point of view:

• Contact ISP (physically go to person / telephone / ?)
• Buy equipment (wireless/wired NIC) and prepaid time from ISP manager?
• Assume that client is in range of hotspot (for now)
• Client installs equipment (probably part of package from ISP)
• switch on
• connect PC / laptop to network
• opens browser with own PC (assume client has PC...)
• Enter username , password (web portal?)
• One should be able to go to internet
• When limit is reached, cut off

Billing Model

• Prepaid
  • Credit Card-related payment (which also includes paypal.com,etc.) is not suitable. With the prepaid billing system, users can pay directly and get a ticket with login details. Implementation at the moment is based on this model.
• Contracts / Subscriptions
  • ?

• Usage plan
  • Time-based usage
    • Users get disconnected after a set period of time for which they have paid.
    • Different plans available (e.g, 10 min / 15 min/ 30 min / 1 hr / 2+ hrs / etc)
  • Bandwidth-based usage
    • (total of upload and download)
    • Different plans available (e.g, 5MB / 10 MB / 20MB / 50MB / 100MB / 1GB/ 2GB /etc)

User interface / Captive Portal

• When a user tries to access an external website (a site that requires paid access), he/she is re-directed to login page where the user should enter details provided on the ticket. The user should also be able to check how much bandwidth / time remaining at any time before/after/while surfing. It would be nice for the user to be able access this information through the captive portal.
• Additional thoughts: In the case of ISPs located within a community network, it would be nice for the captive portal to somehow bond with the local community web portal (Perhaps important updates/announcements from community members/leaders on the login portal, etc ?)
• More thoughts on this: For user to have a object in the browser that will show his/her usage details, possibilities while browsing:
  • Frames: E.g, if the user is not logged on and types URL.com in his browser, once he/she is re-directed to the login portal, logs in and is authenticated, the user is then re-directed to a page containing a small upper frame that shows the users usage/bill details, and the main frame of the page will show URL.com .
    • Pros: fairly easy to implement.
    • Cons: If the user closes this window or types another url in the browser address input, then this ¨closes¨ the frames page.
  • Browser extension/ActiveX/object: E.g, if the user uses the firefox browser for access, a firefox extension can be designed to show usage.
    • Pros: available any time to the user when browsing in firefox.
    • Cons: Can be complex/take more time to implement; More importantly, a firefox extension will only work on firefox, hence if another browser is used instead (e.g. Internet Explorer/Safari/Opera), this becomes pointless.

ISP Management Tool

• ISP should easily be able to manage users (add/edit/reset password/ban/etc)
• ISP should also be able to monitor usage of users (individual / general usage trend/tracking of all users)
• ISP should also be able manage / diagnose network problems (push configs to nodes, track problematic nodes, etc)
  • Some information available on Tom's research page regarding this.

List of tasks involved

The breakdown below is more short-term oriented, to make it easier to follow.

Tasks in the short-term

• Dashboard: debugging, monitoring nodes on the network.
  • Am discussing with and considering re-use of portions of Lawrence´s work (info on signal strength, device details, etc.)
• Dashboard: basic mesh-provisioning functionality (ssh commands, pushing basic configs, etc.)

• Identify and "extract" aspects of Zeroshell that are useful for WISP-in-a-box (QoS, etc).

• Test coova-chilli FreeBSD port for functionality on the "Bokkie" Router
  • Compiles successfully under FreeBSD-x86.

• Improve ISP client side functionality (client logon service, Browser extension?, etc.)

• Skinning of phpMyPrepaid to make it user-friendly and easy-on-the-eyes (fairly complete).
• Testing of coova, phpmyprepaid, webmin (fairly complete).
• Ironing out phpMyPrepaid bugs/issues to make it suitable for functioning in such a setup (satisfactory).

Setup Ingredients

Diagram of initial WISPiab-billing setup using Coova, myPhpPrepaid.

The tools used to setup this testbed:

• Coova WISP-in-a-box Wireless Africa wiki, URL
• phpMyPrepaid Wireless Africa wiki, URL
• FreeRADIUS
• MySQL
• Ubuntu Hardy Server - This is the distro that was used for the gateway server. In future, it is intended to have this setup (when finalized) integrated into Inveneo Hub Server Linux.

Review and decisions on tools/ingredients tested

While making choices on the various tools mentioned in this section, it is also kept in mind that these may change if over time / during testing / implementation phases it is established that the tools in question are not suitable.

With regard to the AAA backend (authorization, authentication, accounting), we have decided to use FreeRADIUS (the best known open-source RADIUS tool) for this purpose. Hence tools required to deal with AAA aspects, (e.g, Captive Portal, Billing System, etc.) must be capable of integration with FreeRADIUS.

Captive Portal

• Coova-chilli
  • Based on the now defunct Coova.
  • Active development.
  • Best known-tool for comprehensive RADIUS support at the moment.

Billing system / interface

• daloRadius
  • Very nice css-interface, and neat layout.
  • Easy to setup.
  • User is expected to have an understanding of basic FreeRADIUS-related attributes, in order to create user accounts, etc.
  • Since the users of this are expected to be non-technical, phpMyPrepaid is considered to be a better option in this regard.

• phpMyPrepaid (final choice)
  • Not an aesthetic interface. Needs skinning.
  • A bit more complicated to setup, compared to daloRadius.
  • More inituitive to the non-technical user, compared to daloRadius.
  • Though setup is complicated, this can be rectified having phpMyPrepaid pre-installed. Skinning can also be resolved.

Discussions

I intend to add information/thoughts/points derived from discussions between everyone involved in WISP-in-a-box and projects that tie into this.

Various

Coova-Chilli FreeBSD port

A third-party port of coova-chilli for the FreeBSD platform is available (at this link). It successfully compiles under FreeBSD. Once I have tested it and if it is successful, the plan is to test and run it on the Bokkie FreeBSD platform.

UDPATE: It runs, but provides the following error:

iptables: command not found.

Coova-chilli uses iptables to set up firewall rules. But from what I find on google, there is no port of iptables available for FreeBSD (some technical issue). However, from discussions based on the Coova-chilli FreeBSD there are responses saying it works. So I am not sure whats going on, but I´ll keep searching for answers on this.

Concerns at the moment

Dashboard API Thoughts

• SNMP? (Is it possible to implement an SNMP task for eg on an OpenWRT linksys box?)
• ROBIN-based scheme?
• Simple shell scripts?

• API ?

This has me really stumped at the moment. I (and others) think it would be a great idea to have an API / higher-layer communication ¨language¨ (e.g XML, etc) implemented for communication between the dashboard client and server. This is mainly for using devices of different platforms (e.g something other than OpenWRT-based devices) in future. If we have such a standard, then for each new platform device that is introduced, ideally the only major work that will have to be done is to implement a dashboard client for the required platform that understands the communication language, and nothing on the server side or otherwise would have to be tampered with. I would have liked using some XML variant, which I think would have been great and easily doable, but apparently this could possibly lead to a lot of overhead traffic in the mesh. I dont know too much about SNMP, am looking into it, but personally (based on what I know at this stage) SNMP is not a substitute for the ¨communication language¨ in mind, and will need to be complemented by something more. Any help/ideas/thoughts here is appreciated.

Where do we go from this point?

The following is a very rough list of my thoughts on the more important tasks that need attention to get things off the ground quickly. These are not the only tasks involved but are what I am considering to be more important at the moment.

• SNMP server-side/client-nodes implementation
  • We need to implement SNMP support for more efficient management of nodes by the server. Comprehensive knowledge of SNMP (from a development perpective as well) is required for this.
• (XML?)/API implementation for client-dashboard communication
  • See concerns on API in the previous section.
• Implementing dashboard clients using the API for the various platforms (OpenWRT/Ubiquity/FreeBSD Bokkie)
  • Once an communication spec/framework has been established, dashboard clients have to be developed for supporting this API on various mesh node devices.
• Network Management/Monitoring
  • Need to investigate/implement (preferably adopt an existing but suitable project (open-source)) an efficient network monitoring/mgmt web interface that is to be integrated into the dashboard
  • Must support functions in the scope of the following:
    • Graphical mapping of nodes in the network (graphically display which nodes are down, up, connected to which SSID/channel, etc)
    • Graphical display of measurements where possible (signal strength, etc)
    • Log manager that logs date/times for downtime, configuration changes, etc for maintenance purposes.
    • Easily/quickly configure each node e.g click on any node that shows on the graphical map and instantly be able to issue commands to it.
    • Configuration backup: Make periodical backups of configurations of each node (either saved on the node itself or on the server), and provide an easy mechanism to restore any backup config if necessary.
    • add more here...
• Testing WISP in a test mesh-network?
  • Need to test the WISP setup in a test-mesh network before deployment in an actual mesh.