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.

Central Dashboard Interface

Concerns at the moment

Dashboard API Thoughts

• SNMP?
• ROBIN-based scheme?
• Simple shell scripts?

List of tasks involved

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

• Testing of coova, phpmyprepaid, webmin.
• These tools were used to setup a ISP testbed. (see below)
• Ironing out phpMyPrepaid bugs/issues to make it suitable for functioning in such a setup.

I have added a more detailed task breakdown for the long-term, based on that from Tom´s page.

Detailed, long-term Task Breakdown

1. Dashboard: debugging, monitoring nodes on the network
   1. Further examination of ROBIN to see which parts of it can be modified for our purposes
   2. Adaptation of Webmin's cluster tools for use on the mesh
   3. Determine appropriate tools for QoS [starting point: Zeroshell]
   4. Update API design & specification
   5. Dashboard framework design and implementation
   6. Mesh update client framework design and implementation
   7. Dashboard module implementation
      1. Network Monitoring
      2. Network Configuration – basics (Channel, SSID, etc)
      3. Network Configuration – QoS settings
      4. Network Configuration – AP-only settings
      5. Adapt phpMyPrepaid's CoovaChilli configuration to send out updates via standardized API rather than only changing local configuration file.
   8. Co-development with dashboard modules: mesh client update modules for each dashboard component, designed initially for the WRT but as portable as possible (for most modules portability should be trivial, as the software on the node the update client is configuring will be the same).
   9. CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).

More immediate tasks

• 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.)

• 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).

• Test coova-chilli FreeBSD port for functionality on the "Bokkie" Router
  • Compiles successfully under FreeBSD-x86.
• Identify and "extract" aspects of Zeroshell that are useful for WISP-in-a-box (QoS, etc).

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.