George's Research - Revision history

Ajay: Replacing page with 'Category: Development Team Research Pages migrated to wireless dev'

2009-08-06T13:07:59Z

Replacing page with 'Category: Development Team Research Pages migrated to wireless dev'

George: /* Review and decisions on tools/ingredients tested */

2008-09-18T13:01:40Z

Review and decisions on tools/ingredients tested

← Older revision		Revision as of 15:01, 18 September 2008
Line 156:		Line 156:

	I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a [http://ipkg.k1k2.de/packages ipkg mirror] that provides packages (package webif-mesh) that install BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on [http://www.diniro.net/fabbblog/wireless-mesh-networks-manet.html this page (MANET Mesh Network)], which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.		I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a [http://ipkg.k1k2.de/packages ipkg mirror] that provides packages (package webif-mesh) that install BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on [http://www.diniro.net/fabbblog/wireless-mesh-networks-manet.html this page (MANET Mesh Network)], which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.


			==Network Management==

			===QoS===

			X-WRT has an interface for QoS. I havent looked at it yet (it requires that you install certain packages before you can explore the QoS X-WRT interface). I plan to look into it, and hope it is something that will really help in the QoS implementation.

	=Discussions=		=Discussions=

George: /* Network Monitoring */

2008-09-18T12:39:28Z

Network Monitoring

← Older revision		Revision as of 14:39, 18 September 2008
Line 155:		Line 155:
	==Network Monitoring==		==Network Monitoring==

	I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a [http://ipkg.k1k2.de/packages ipkg] ~~mirror~~ that provides packages (package webif-mesh) that install BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on [http://www.diniro.net/fabbblog/wireless-mesh-networks-manet.html this page (MANET Mesh Network)], which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.		I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a [http://ipkg.k1k2.de/packages ipkg mirror] that provides packages (package webif-mesh) that install BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on [http://www.diniro.net/fabbblog/wireless-mesh-networks-manet.html this page (MANET Mesh Network)], which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.

	=Discussions=		=Discussions=

George: /* Network Monitoring */

2008-09-18T12:39:00Z

Network Monitoring

← Older revision		Revision as of 14:39, 18 September 2008
Line 155:		Line 155:
	==Network Monitoring==		==Network Monitoring==

	I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a ipkg mirror that provides a package that ~~installs~~ BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on this page, which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.		I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a [http://ipkg.k1k2.de/packages ipkg] mirror that provides packages (package webif-mesh) that install BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on [http://www.diniro.net/fabbblog/wireless-mesh-networks-manet.html this page (MANET Mesh Network)], which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.

	=Discussions=		=Discussions=

George: /* Review and decisions on tools/ingredients tested */

2008-09-18T12:34:33Z

Review and decisions on tools/ingredients tested

← Older revision		Revision as of 14:34, 18 September 2008
Line 152:		Line 152:
	** More inituitive to the non-technical user, 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.		** Though setup is complicated, this can be rectified having phpMyPrepaid pre-installed. Skinning can also be resolved.

			==Network Monitoring==

			I have setup a mini-mesh that uses the BATMAN protocol, just for me to experiment with BATMAN. But this also gave me a chance to try out DD-WRT, which is what I used. There is a ipkg mirror that provides a package that installs BATMAN along with a nice X-WRT BATMAN web interface for making configurations for BATMAN, and also shows a BATMAN connectivity status section. Screenshots of this interface are available on this page, which also has a screenshot of a graphical representation of the BATMAN nodes generated by a visualization server. It would be interesting to be able show this kind of representation in the dashboard, without requiring X to display. I intend to try to display BATMAN based network information in the dashboard, using the BATMAN X-WRT web interface as a reference.

	=Discussions=		=Discussions=

George: /* Various */

2008-08-28T09:49:55Z

Various

← Older revision		Revision as of 11:49, 28 August 2008
Line 169:		Line 169:
	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.		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==~~		==Concerns atm/Where do we go from this point?==



	==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.		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.

George: /* Dashboard API Thoughts */

2008-08-28T09:49:19Z

Dashboard API Thoughts

← Older revision		Revision as of 11:49, 28 August 2008
Line 171:		Line 171:
	==Concerns at the moment==		==Concerns at the moment==

	~~===Dashboard API Thoughts===~~
	* SNMP? (SNMP stack for eg on an OpenWRT linksys box?)
	** Well, it seems DD-WRT supports SNMP(see [here http://www.dd-wrt.com/wiki/index.php/SNMP]) This looks great in-terms of SNMP and network monitoring support. IMHO, if using this, one would hardly have to write any shell scripts/low level coding to gather a lot of information expected from network monitoring (see the supported SNMP OIDs).
	* ROBIN-based scheme?
	* Simple shell scripts?

	* API ?

	==Where do we go from this point?==		==Where do we go from this point?==

George: /* Where do we go from this point? */

2008-08-28T09:48:55Z

Where do we go from this point?

← Older revision		Revision as of 11:48, 28 August 2008
Line 185:		Line 185:
	* SNMP server-side/client-nodes implementation		* 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.		** 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.
	** Well, it seems DD-WRT supports SNMP(see [here http://www.dd-wrt.com/wiki/index.php/SNMP]) This looks great in-terms of SNMP and network monitoring support. IMHO, if using this, one would hardly have to write any shell scripts/low level coding to gather a lot of information expected from network monitoring (see the supported SNMP OIDs).		** Well, it seems DD-WRT supports SNMP(see [here http://www.dd-wrt.com/wiki/index.php/SNMP]) This looks great in-terms of SNMP and network monitoring support. IMHO, if using this, one would hardly have to write any shell scripts/low level coding to gather a lot of information expected from network monitoring (see the supported SNMP OIDs). Of course, problem arises when we use a box other than any Linux/BSD / DD-WRT Linksy boxes that may not support SNMP.
	* (XML?)/API implementation for client-dashboard communication		* (XML?)/API implementation for client-dashboard communication
	** 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 great from a monitoring perspective, not for making/pushing configurations hence 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.		** 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 great from a monitoring perspective, not for making/pushing configurations hence 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.

George: /* Where do we go from this point? */

2008-08-28T09:47:17Z

Where do we go from this point?

← Older revision		Revision as of 11:47, 28 August 2008
Line 185:		Line 185:
	* SNMP server-side/client-nodes implementation		* 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.		** 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.
			** Well, it seems DD-WRT supports SNMP(see [here http://www.dd-wrt.com/wiki/index.php/SNMP]) This looks great in-terms of SNMP and network monitoring support. IMHO, if using this, one would hardly have to write any shell scripts/low level coding to gather a lot of information expected from network monitoring (see the supported SNMP OIDs).
	* (XML?)/API implementation for client-dashboard communication		* (XML?)/API implementation for client-dashboard communication
	** 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 great from a monitoring perspective, not for making/pushing configurations hence 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.		** 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 great from a monitoring perspective, not for making/pushing configurations hence 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.

George: /* Where do we go from this point? */

2008-08-28T09:46:31Z

Where do we go from this point?

← Older revision		Revision as of 11:46, 28 August 2008
Line 186:		Line 186:
	** 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.		** 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		* (XML?)/API implementation for client-dashboard communication
	** ~~See concerns~~ on ~~API~~ in the ~~previous~~ section.		** 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 great from a monitoring perspective, not for making/pushing configurations hence 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.
			<!--=Technical information on work done=
			This section contains documentation on work done regarding testing of an implementation that would make it as easy as possible for a would-be entrepreneur in a wireless mesh network to deploy an ISP service. The entrepreneur should be able to manage, monitor and charge users with ease. -->
	* Implementing dashboard clients using the API for the various platforms (OpenWRT/Ubiquity/FreeBSD Bokkie)		* 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.		** Once an communication spec/framework has been established, dashboard clients have to be developed for supporting this API on various mesh node devices.