WISP-in-a-box Way Forward - Revision history

Sebastian: /* Our Approach */

2008-09-09T04:45:38Z

Our Approach

← Older revision		Revision as of 06:45, 9 September 2008
Line 41:		Line 41:

	* Server Administration -- brings up Webmin		* Server Administration -- brings up Webmin
	** This will not only allow us to configure the server, but also execute arbitrary commands on all the mesh nodes using Webmin's cluster functionality. We will strip down a version of Webmin to run on the client nodes and use Webmin's cluster modules on the server to communicate with them. ''Comment: Running stripped down webmin on the nodes might neither be feasible nor needed - instead, we will copy the functionality of such a cluster control, ~~hwowever~~ implement it using generic remote commands rather than webmin instances.''		** This will not only allow us to configure the server, but also execute arbitrary commands on all the mesh nodes using Webmin's cluster functionality. We will strip down a version of Webmin to run on the client nodes and use Webmin's cluster modules on the server to communicate with them. ''Comment: Running stripped down webmin on the nodes might neither be feasible nor needed - instead, we will copy the functionality of such a cluster control, howwever implement it using generic remote commands rather than webmin instances.''
	* Vouchers -- brings up phpMyPrepaid, our data billing control system		* Vouchers -- brings up phpMyPrepaid, our data billing control system
	** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network		** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network

Sebastian: /* Our Approach */ webmin on nodes?

2008-09-09T04:45:11Z

Our Approach: webmin on nodes?

← Older revision		Revision as of 06:45, 9 September 2008
Line 41:		Line 41:

	* Server Administration -- brings up Webmin		* Server Administration -- brings up Webmin
	** This will not only allow us to configure the server, but also execute arbitrary commands on all the mesh nodes using Webmin's cluster functionality. We will strip down a version of Webmin to run on the client nodes and use Webmin's cluster modules on the server to communicate with them.		** This will not only allow us to configure the server, but also execute arbitrary commands on all the mesh nodes using Webmin's cluster functionality. We will strip down a version of Webmin to run on the client nodes and use Webmin's cluster modules on the server to communicate with them. ''Comment: Running stripped down webmin on the nodes might neither be feasible nor needed - instead, we will copy the functionality of such a cluster control, hwowever implement it using generic remote commands rather than webmin instances.''
	* Vouchers -- brings up phpMyPrepaid, our data billing control system		* Vouchers -- brings up phpMyPrepaid, our data billing control system
	** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network		** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network

Kroux at 19:55, 4 August 2008

2008-08-04T19:55:55Z

Kroux at 21:38, 23 July 2008

2008-07-23T21:38:55Z

Tom: /* AP-only Nodes */

2008-07-23T14:00:04Z

AP-only Nodes

← Older revision		Revision as of 16:00, 23 July 2008
Line 87:		Line 87:

	=== AP-only Nodes ===		=== AP-only Nodes ===
	The mesh nodes will use their radios exclusively for the mesh backhaul. Clients can be attached directly to the Ethernet ports of these nodes, however it may be useful to have wireless client access as well. In this case, a second device can be attached to the mesh node to act as an access point. These devices can also be Linksys WRTs or similar~~. They will be bridged to the DHCP server of the captive portal~~ running ~~on the mesh node, and so need no special functionality.~~		The mesh nodes will use their radios exclusively for the mesh backhaul. Clients can be attached directly to the Ethernet ports of these nodes, however it may be useful to have wireless client access as well. In this case, a second device can be attached to the mesh node to act as an access point. These devices can also be Linksys WRTs or similar, running OpenWRT with:

	* ~~If central~~ configuration ~~isn't desirable then any device that can operate as a pure AP without a DHCP server will do (the Linksys stock firmware, for instance).~~		* CoovaChilli
	* If configuration ~~via the dashboard is desired, then the nodes will run OpenWRT and a barebones dashboard client that allows for configuration of the AP's SSID, etc.~~		* Dashboard Client with:
			** AP-only node configuration module
			** CoovaChilli configuration module

	=== Task Breakdown ===		=== Task Breakdown ===

Tom: /* Task Breakdown */

2008-07-23T10:58:33Z

Task Breakdown

← Older revision		Revision as of 12:58, 23 July 2008
Line 98:		Line 98:
	## Further examination of ROBIN to see which parts of it can be modified for our purposes		## Further examination of ROBIN to see which parts of it can be modified for our purposes
	## Adaptation of Webmin's cluster tools for use on the mesh		## Adaptation of Webmin's cluster tools for use on the mesh
			## Determine appropriate tools for QoS [starting point: Zeroshell]
	## Update API design & specification		## Update API design & specification
	## Dashboard framework design and implementation		## Dashboard framework design and implementation
Line 109:		Line 110:
	## 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).		## 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).
	## CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).		## CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).

	~~Notes: These need to be done relatively sequentially, however once the dashboard and mesh client frameworks are in place different modules can be developed in parallel.~~

	# Minimal interface development for starter devices (at least the WRT, Mesh Potato, and Ubiquity nodes): Inveneo		# Minimal interface development for starter devices (at least the WRT, Mesh Potato, and Ubiquity nodes): Inveneo

Tom at 10:20, 23 July 2008

2008-07-23T10:20:39Z

← Older revision		Revision as of 12:20, 23 July 2008
Line 5:		Line 5:
	[[Image:Grafic_(Modified).png\|thumb\|400px]]		[[Image:Grafic_(Modified).png\|thumb\|400px]]

	[[Image:Grafic-telco_(Modified).png\|thumb\|400px\|Icon sources:http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]		[[Image:Grafic-telco_(Modified).png\|thumb\|400px\|Icon sources: http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]

	The entire WISP-in-a-box system consists of:		The entire WISP-in-a-box system consists of:

Tom at 10:20, 23 July 2008

2008-07-23T10:20:21Z

← Older revision		Revision as of 12:20, 23 July 2008
Line 5:		Line 5:
	[[Image:Grafic_(Modified).png\|thumb\|400px]]		[[Image:Grafic_(Modified).png\|thumb\|400px]]

	[[Image:Grafic-telco_(Modified).png\|thumb\|400px]]		[[Image:Grafic-telco_(Modified).png\|thumb\|400px\|Icon sources:http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]

	The entire WISP-in-a-box system consists of:		The entire WISP-in-a-box system consists of:

Kroux at 09:29, 23 July 2008

2008-07-23T09:29:21Z

← Older revision		Revision as of 11:29, 23 July 2008
Line 10:		Line 10:

	* A central dashboard, running on the gateway server, from which:		* A central dashboard, running on the gateway server, from which:
	** the network can be monitored and all ~~node~~ can be configured		** the network can be monitored and all nodes can be configured
	** ~~pre-paid vouches~~ can be administered		** prepaid vouchers can be administered
	** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered		** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered
	** all functionality will work without upstream Internet access		** all functionality will work without upstream Internet access

Tom at 09:11, 23 July 2008

2008-07-23T09:11:01Z

← Older revision		Revision as of 11:11, 23 July 2008
Line 46:		Line 46:
	** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that Michael Jenkins can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.		** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that Michael Jenkins can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.
	* Network Status -- new custom dashboard component with following features:		* Network Status -- new custom dashboard component with following features:

	** A semi-detailed list of all the nodes in the mesh, including:		** A semi-detailed list of all the nodes in the mesh, including:
	*** the node's IP and MAC addresses		*** the node's IP and MAC addresses

← Older revision		Revision as of 21:55, 4 August 2008
Line 12:		Line 12:
	** the network can be monitored and all nodes can be configured		** the network can be monitored and all nodes can be configured
	** prepaid vouchers can be administered		** prepaid vouchers can be administered
	** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered		** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered
	** all functionality will work without upstream Internet access		** all functionality will work without upstream Internet access
	* Mesh nodes which:		* Mesh nodes which:
	** receive configuration updates from the central dashboard		** receive configuration updates from the central dashboard
	** run a captive portal that interacts with clients and authenticates against the gateway server		** run a captive portal that interacts with clients and authenticates against the gateway server
	** run intra-mesh QoS software		** run intra-mesh QoS software
	** route themselves intelligently using BATMAN		** route themselves intelligently using BATMAN

	=== Component Diagram ===		=== Component Diagram ===
Line 46:		Line 46:
	** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that researchers can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.		** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that researchers can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.
	* Network Status -- new custom dashboard component with following features:		* Network Status -- new custom dashboard component with following features:
	** A semi-detailed list of all the nodes in the mesh, including:		** A semi-detailed list of all the nodes in the mesh, including:
	*** the node's IP and MAC addresses		*** the node's IP and MAC addresses
	*** the node's current status (simple up or down)		*** the node's current status (simple up or down)
	*** when they were last heard from (when an update from that node was last received)		*** when they were last heard from (when an update from that node was last received)
	*** how many hops and/or what route the node currently has to the gateway		*** how many hops and/or what route the node currently has to the gateway
Line 62:		Line 62:
	** Change channel of mesh network		** Change channel of mesh network
	** Other features? Open to discussion.		** Other features? Open to discussion.
			** Note - It might be necessary to have multiple classes of mesh devices on the network, to accommodate a combination of different hardwares, different channels, etc.
	* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:		* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:
	** On the server, for outgoing traffic going to the upstream connection		** On the server, for outgoing traffic going to the upstream connection

← Older revision		Revision as of 23:38, 23 July 2008
Line 7:		Line 7:
	[[Image:Grafic-telco_(Modified).png\|thumb\|400px\|Icon sources: http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]		[[Image:Grafic-telco_(Modified).png\|thumb\|400px\|Icon sources: http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]

	The entire WISP-in-a-box system consists of:		The entire WISP-in-a-box system consists of:

	* A central dashboard, running on the gateway server, from which:		* A central dashboard, running on the gateway server, from which:
Line 16:		Line 16:
	* Mesh nodes which:		* Mesh nodes which:
	** receive configuration updates from the central dashboard		** receive configuration updates from the central dashboard
	** run a captive portal that interacts with clients and authenticates against the gateway server		** run a captive portal that interacts with clients and authenticates against the gateway server
	** run intra-mesh QoS software		** run intra-mesh QoS software
	** route themselves intelligently using BATMAN		** route themselves intelligently using BATMAN

	=== Component Diagram ===		=== Component Diagram ===
Line 44:		Line 44:
	* Vouchers -- brings up phpMyPrepaid, our data billing control system		* Vouchers -- brings up phpMyPrepaid, our data billing control system
	** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network		** phpMyPrepaid additionally controls the CoovaChilli instances running on all routers, including the ability to restrict or permit free access to the rest of the mesh network
	** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that ~~Michael Jenkins~~ can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.		** We need to also design in some way of dumping the user usage data that FreeRADIUS stores so that researchers can do usage studies on it. The local user needs to be able to easily dump this data and send it back to the CSIR for study.
	* Network Status -- new custom dashboard component with following features:		* Network Status -- new custom dashboard component with following features:
	** A semi-detailed list of all the nodes in the mesh, including:		** A semi-detailed list of all the nodes in the mesh, including:
Line 58:		Line 58:
	*** Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools		*** Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools

	* ~~Backbone~~ Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):		* Mesh Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):
	** Change SSID of mesh ~~backhaul~~		** Change SSID of mesh network
	** Change channel of mesh ~~backhaul~~		** Change channel of mesh network
	** Other features? Open to discussion.		** Other features? Open to discussion.
	* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:		* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:
Line 70:		Line 70:
	** Any kind of WPA authentication a user might want to run on the AP		** Any kind of WPA authentication a user might want to run on the AP

	Possible other voice-related modules include Asterisk and A2billing pages.		Possible other voice-related modules include Asterisk and A2billing modules or pages.

	The dashboard will send out all configuration updates using a standardized API; any mesh node in the network will have to run a client implementing this API that receives configuration messages from the dashboard and makes the necessary changes to files on its system. The API will be just as modular as the dashboard, so if a user wants to only implement certain features (say, add billing to an existing network) she would only need to implement a client for the platform her nodes are running (or, ideally, there will already be a client for that platform). Through the dashboard the user could then disable the unwanted modules. The dashboard will only send out updates for the components that are enabled, and the client will only modify configuration files for the components it receives.		The dashboard will send out all configuration updates using a standardized API; any mesh node in the network will have to run a client implementing this API that receives configuration messages from the dashboard and makes the necessary changes to files on its system. The API will be just as modular as the dashboard, so if a user wants to only implement certain features (say, add billing to an existing network) she would only need to implement a client for the platform her nodes are running (or, ideally, there will already be a client for that platform). Through the dashboard the user could then disable the unwanted modules. The dashboard will only send out updates for the components that are enabled, and the client will only modify configuration files for the components it receives.
Line 87:		Line 87:

	=== AP-only Nodes ===		=== AP-only Nodes ===
	The mesh nodes will use their radios exclusively for the mesh backhaul. Clients can be attached directly to the Ethernet ports of these nodes, however it may be useful to have wireless client access as well. In this case, a second device can be attached to the mesh node to act as an access point. These devices can also be Linksys WRTs or similar, running OpenWRT with:		The mesh nodes will use their radios exclusively for the mesh network ('backhaul'). Clients can be attached directly to the Ethernet ports of these nodes, however it may be useful to have wireless client access as well. In this case, a second device can be attached to the mesh node to act as an access point. These devices can also be Linksys WRTs or similar, running OpenWRT with:

	* CoovaChilli		* CoovaChilli