http://wirelessafrica.meraka.org.za/wiki/api.php?action=feedcontributions&feedformat=atom&user=Kroux
WirelessAfrica - User contributions [en]
2026-04-18T13:57:15Z
User contributions
MediaWiki 1.42.7
http://wirelessafrica.meraka.org.za/wiki/index.php?title=VO_Requirements_%26_Functionality_Questions&diff=4798
VO Requirements & Functionality Questions
2009-10-15T09:30:47Z
<p>Kroux: </p>
<hr />
<div>== Understanding the bigger picture ==<br />
<br />
The development on this project is done in phases. New functionalities/features are added with each phase until we reach our target system. All development work of every phase should be aligned with our end system in mind. In order for developers to make the right design choices that will not limit future functionality, they need to have a clear end target that they are working towards.<br />
<br />
This page is here to help the developers to get a better understanding of the bigger picture and to make sure the target we design for is clearly defined and does not move around. <br />
<br />
Please add any project related questions/thoughts on this page so that we can sort them and see what information is still missing.<br />
<br />
=== VO (village operator) in action ===<br />
<br />
Lets assume the the new VO has all the kit installed. The gateway (WISP) box is connected to the Internet and he is now ready to commission his new business. His first customers are three schools, the local Municipality and two owners of a local Spaza shop who wants a network connection at the shop and at both their homes. The two shop owners are very excited and they want to put a web server at their shop and they are thinking about opening a little Internet cafe very soon.<br />
<br />
=== Definitions ===<br />
* User - An accounting entity with a user name and password. Typically represents an individual or an organisation.<br />
* Edge device - A device that is part of the local wireless network (e.g. talk mesh protocol) and allows other devices to connect through the wireless network. HPNs and 'Basic Nodes' are edge devices.<br />
* HPN - High Performance Node<br />
* BN - Basic Node<br />
<br />
=== Random questions / thoughts ===<br />
<br />
* What Internet contract packages are available from the VO - prepaid, contract, local, gov sites only ???<br />
* Is data traffic contained on the local wireless network free / flat fee / pay per usage<br />
* must a user do some login before he can use the local network<br />
* must the network be able to log all user traffic between local users<br />
* can a user use the local network without buying prepaid/account from the VO<br />
* How must a prepaid package be activated / deactivated<br />
* Are there any bandwidth limits tied to a Internet package<br />
* Are there any data caps associated with the different package<br />
* Must a prepaid user login before he can use the Internet<br />
* Must a prepaid user login before he can send data on the local network (no Internet)<br />
* How about a gaming server on the local network, does it need to login some where<br />
* Can more than one user share the same prepaid account, and at the same time<br />
* If a school uses prepaid, do they share the same account, or each user in school<br />
* How will someone running an Internet cafe resell his prepaid bandwidth<br />
* Is a prepaid account tied to certain time duration<br />
* How does a person get onto the network?<br />
* If login is necessary, how do peripherals like printers and ATAs authenticate?<br />
* What devices should be 'approved' for use on the network<br />
<br />
=== The VO ===<br />
A VO is a person or an entity whose primary objective is running (at a profit) a wireless network. To this end, the following describes the needs or requirements of the VO to meet his objective.<br />
<br />
The VO needs:<br />
<br />
1. A healthy and working network<br />
<br />
2. Diagnostic tools for the network<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
4. Service management of the network<br />
<br />
5. A view of the usage of the network<br />
<br />
6. To manage (activate/deactivate) edge devices on the network<br />
<br />
<br />
1. A healthy and working network<br />
<br />
-> Each network element MUST handle all routing and communications other network elements. <br />
<br />
-> Each network element MUST require of the VO as minimum as possible configuration without compromising its usability or effectiveness.<br />
<br />
<br />
2. Diagnostic tools for the network<br />
<br />
At a minimum, the VO is provided with a web based diagnostic tools. <br />
<br />
-> The diagnostic tools are enough for the VO to establish any problem that may be there. <br />
<br />
-> The diagnostic tools can interface with other systems, e.g SMS, email.<br />
<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
-> VO will be able create and modify user accounts<br />
<br />
-> VO provides a number of service options for different users<br />
<br />
-> VO can monitor usage of the internet connection<br />
<br />
-> VO can monitor usage of the local network<br />
<br />
-> VO can block access to the network for certain users<br />
<br />
<br />
4. Service management of the network <br />
<br />
-> The VO is able to prioritise certain services within the network<br />
<br />
-> The VO is able to block or enable certain services<br />
<br />
<br />
5. A view of the usage of the network<br />
<br />
-> The VO is able to see the usage of the whole network<br />
<br />
-> The VO is able to see the usage of each network element<br />
<br />
<br />
6. To manage (activate/deactivate) edge devices in the network<br />
<br />
-> VO can allow (new) edge devices to join the network<br />
<br />
-> VO can block edge devices from accessing the local network</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=VO_Requirements_%26_Functionality_Questions&diff=4797
VO Requirements & Functionality Questions
2009-10-15T09:30:13Z
<p>Kroux: </p>
<hr />
<div>== Understanding the bigger picture ==<br />
<br />
The development on this project is done in phases. New functionalities/features are added with each phase until we reach our target system. All development work of every phase should be aligned with our end system in mind. In order for developers to make the right design choices that will not limit future functionality, they need to have a clear end target that they are working towards.<br />
<br />
This page is here to help the developers to get a better understanding of the bigger picture and to make sure the target we design for is clearly defined and does not move around. <br />
<br />
Please add any project related questions/thoughts on this page so that we can sort them and see what information is still missing.<br />
<br />
=== VO (village operator) in action ===<br />
<br />
Lets assume the the new VO has all the kit installed. The gateway (WISP) box is connected to the Internet and he is now ready to commission his new business. His first customers are three schools, the local Municipality and two owners of a local Spaza shop who wants a mesh connection at the shop and at both their homes. The two shop owners are very excited and they want to put a web server at their shop and they are thinking about opening a little Internet cafe very soon.<br />
<br />
=== Definitions ===<br />
* User - An accounting entity with a user name and password. Typically represents an individual or an organisation.<br />
* Edge device - A device that is part of the local wireless network (e.g. talk mesh protocol) and allows other devices to connect through the wireless network. HPNs and 'Basic Nodes' are edge devices.<br />
* HPN - High Performance Node<br />
* BN - Basic Node<br />
<br />
=== Random questions / thoughts ===<br />
<br />
* What Internet contract packages are available from the VO - prepaid, contract, local, gov sites only ???<br />
* Is data traffic contained on the local wireless network free / flat fee / pay per usage<br />
* must a user do some login before he can use the local network<br />
* must the network be able to log all user traffic between local users<br />
* can a user use the local network without buying prepaid/account from the VO<br />
* How must a prepaid package be activated / deactivated<br />
* Are there any bandwidth limits tied to a Internet package<br />
* Are there any data caps associated with the different package<br />
* Must a prepaid user login before he can use the Internet<br />
* Must a prepaid user login before he can send data on the local network (no Internet)<br />
* How about a gaming server on the local network, does it need to login some where<br />
* Can more than one user share the same prepaid account, and at the same time<br />
* If a school uses prepaid, do they share the same account, or each user in school<br />
* How will someone running an Internet cafe resell his prepaid bandwidth<br />
* Is a prepaid account tied to certain time duration<br />
* How does a person get onto the network?<br />
* If login is necessary, how do peripherals like printers and ATAs authenticate?<br />
* What devices should be 'approved' for use on the network<br />
<br />
=== The VO ===<br />
A VO is a person or an entity whose primary objective is running (at a profit) a wireless network. To this end, the following describes the needs or requirements of the VO to meet his objective.<br />
<br />
The VO needs:<br />
<br />
1. A healthy and working network<br />
<br />
2. Diagnostic tools for the network<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
4. Service management of the network<br />
<br />
5. A view of the usage of the network<br />
<br />
6. To manage (activate/deactivate) edge devices on the network<br />
<br />
<br />
1. A healthy and working network<br />
<br />
-> Each network element MUST handle all routing and communications other network elements. <br />
<br />
-> Each network element MUST require of the VO as minimum as possible configuration without compromising its usability or effectiveness.<br />
<br />
<br />
2. Diagnostic tools for the network<br />
<br />
At a minimum, the VO is provided with a web based diagnostic tools. <br />
<br />
-> The diagnostic tools are enough for the VO to establish any problem that may be there. <br />
<br />
-> The diagnostic tools can interface with other systems, e.g SMS, email.<br />
<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
-> VO will be able create and modify user accounts<br />
<br />
-> VO provides a number of service options for different users<br />
<br />
-> VO can monitor usage of the internet connection<br />
<br />
-> VO can monitor usage of the local network<br />
<br />
-> VO can block access to the network for certain users<br />
<br />
<br />
4. Service management of the network <br />
<br />
-> The VO is able to prioritise certain services within the network<br />
<br />
-> The VO is able to block or enable certain services<br />
<br />
<br />
5. A view of the usage of the network<br />
<br />
-> The VO is able to see the usage of the whole network<br />
<br />
-> The VO is able to see the usage of each network element<br />
<br />
<br />
6. To manage (activate/deactivate) edge devices in the network<br />
<br />
-> VO can allow (new) edge devices to join the network<br />
<br />
-> VO can block edge devices from accessing the local network</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=VO_Requirements_%26_Functionality_Questions&diff=4796
VO Requirements & Functionality Questions
2009-10-15T09:26:58Z
<p>Kroux: </p>
<hr />
<div>== Understanding the bigger picture ==<br />
<br />
The development on this project is done in phases. New functionalities/features are added with each phase until we reach our target system. All development work of every phase should be aligned with our end system in mind. In order for developers to make the right design choices that will not limit future functionality, they need to have a clear end target that they are working towards.<br />
<br />
This page is here to help the developers to get a better understanding of the bigger picture and to make sure the target we design for is clearly defined and does not move around. <br />
<br />
Please add any project related questions/thoughts on this page so that we can sort them and see what information is still missing.<br />
<br />
=== VO (village operator) in action ===<br />
<br />
Lets assume the the new VO has all the kit installed. The gateway (WISP) box is connected to the Internet and he is now ready to commission his new business. His first customers are three schools, the local Municipality and two owners of a local Spaza shop who wants a mesh connection at the shop and at both their homes. The two shop owners are very excited and they want to put a web server at their shop and they are thinking about opening a little Internet cafe very soon.<br />
<br />
=== Definitions ===<br />
* User - An accounting entity with a user name and password. Typically represents an individual or an organisation.<br />
* Edge device - A device that is part of the mesh network (talk mesh protocol) and allows other devices to connect through the mesh. HPNs and Basic Mesh Nodes are edge devices.<br />
* HPN - High Performance Node<br />
* BN - Basic Node<br />
<br />
=== Random questions / thoughts ===<br />
<br />
* What Internet contract packages are available from the VO - prepaid, contract, local, gov sites only ???<br />
* Is data traffic on the mesh free / flat fee / pay per usage<br />
* must a user do some login before he can use the mesh<br />
* must the mesh be able to log all user traffic between mesh users<br />
* can a user use the mesh without buying prepaid/account from the VO<br />
* How must a prepaid package be activated / deactivated<br />
* Are there any bandwidth limits tied to a Internet package<br />
* Are there any data caps associated with the different package<br />
* Must a prepaid user login before he can use the Internet<br />
* Must a prepaid user login before he can send data on the mesh (no Internet)<br />
* How about a gaming server on the mesh, does it need to login some where<br />
* Can more than one user share the same prepaid account, and at the same time<br />
* If a school uses prepaid, do they share the same account, or each user in school<br />
* How will someone running an Internet cafe resell his prepaid bandwidth<br />
* Is a prepaid account tied to certain time duration<br />
* How does a person get onto the network?<br />
* If login is necessary, how do peripherals like printers and ATAs authenticate?<br />
* What devices should be 'approved' for use on the network<br />
<br />
=== The VO ===<br />
A VO is a person or an entity whose primary objective is running (at a profit) a wireless network. To this end, the following describes the needs or requirements of the VO to meet his objective.<br />
<br />
The VO needs:<br />
<br />
1. A healthy and working network<br />
<br />
2. Diagnostic tools for the network<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
4. Service management of the network<br />
<br />
5. A view of the usage of the network<br />
<br />
6. To manage (activate/deactivate) edge devices on the network<br />
<br />
<br />
1. A healthy and working network<br />
<br />
-> Each network element MUST handle all routing and communications other network elements. <br />
<br />
-> Each network element MUST require of the VO as minimum as possible configuration without compromising its usability or effectiveness.<br />
<br />
<br />
2. Diagnostic tools for the network<br />
<br />
At a minimum, the VO is provided with a web based diagnostic tools. <br />
<br />
-> The diagnostic tools are enough for the VO to establish any problem that may be there. <br />
<br />
-> The diagnostic tools can interface with other systems, e.g SMS, email.<br />
<br />
<br />
3. To manage users or subscribers to the network<br />
<br />
-> VO will be able create and modify user accounts<br />
<br />
-> VO provides a number of service options for different users<br />
<br />
-> VO can monitor usage of the internet connection<br />
<br />
-> VO can monitor usage of the local network<br />
<br />
-> VO can block access to the network for certain users<br />
<br />
<br />
4. Service management of the network <br />
<br />
-> The VO is able to prioritise certain services within the network<br />
<br />
-> The VO is able to block or enable certain services<br />
<br />
<br />
5. A view of the usage of the network<br />
<br />
-> The VO is able to see the usage of the whole network<br />
<br />
-> The VO is able to see the usage of each network element<br />
<br />
<br />
6. To manage (activate/deactivate) edge devices in the network<br />
<br />
-> VO can allow (new) edge devices to join the network<br />
<br />
-> VO can block edge devices from accessing the mesh network</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=User:Ajay&diff=4784
User:Ajay
2009-09-28T04:37:51Z
<p>Kroux: </p>
<hr />
<div>==DIY Mesh Guide==<br />
[[DIY_Mesh_Guide]]<br />
<br />
<br />
==WISP in a box project==<br />
<br />
[[WISP_in_a_Box_Development]]<br />
<br />
[[The_WISP-in-a-box_project]]<br />
<br />
[[WISP-in-a-box_Way_Forward]]<br />
<br />
[[WISP_Coova_phpMyPrepaid]]<br />
<br />
<br />
==High Performance Node ==<br />
<br />
[[High_performance_node_page]] - migrated<br />
<br />
[[High_Performance_Node_-_Setup]] Setup for bokkie routers at Ndlovu<br />
<br />
[[High_Performance_Node_-_Specification]] - migrated<br />
<br />
[[High_Performance_Node_-_Dev_and_Test_Network]] - migrated<br />
<br />
[[High_Performance_Node_-_Software]] Software related - migrated<br />
<br />
==VoIP==<br />
<br />
[[VoIP]]<br />
<br />
<br />
== Development Team Research Pages ==<br />
'''George: ''' [[George%27s_Research]] - migrated<br />
<br />
'''Johann: ''' [[Johann%27s_Research]] - migrated<br />
<br />
'''Lawrence: ''' [[Lawrence%27s_Research]] - migrated<br />
<br />
'''Ntuthuko: ''' [[Ntuthuko%27s_Research]] - migrated<br />
<br />
'''Tom: ''' [[Tom%27s_research]]<br />
<br />
'''Ajay: ''' [[Ajay%27s_research]] - migrated<br />
<br />
'''Gerhard: ''' [[Gerhard%27s_research]] - migrated<br />
<br />
'''John: ''' [[John%27s_research]] - migrated<br />
<br />
'''Antoine:''' [[Antoine%27s_Research]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Lawrence%27s_Research&diff=4614
Lawrence's Research
2009-04-16T10:18:28Z
<p>Kroux: /* Features of the High Performance Node (HPN) */</p>
<hr />
<div>[[Category: Development Team Research Pages]]<br />
= Avila board development [ Avila GW2348-4 Intel XScale IXP425] =<br />
The intention of this exercise is to get the board to run Linux. There are number of ways to do this and will consider as many as feasible. <br />
== Running OpenWRT on Avila board ==<br />
The following steps were performed to get the board to run OpenWRT<br />
===Requirements===<br />
A. Installing and setting up tftp server (Ubuntu, hardy)<br />
<br />
B. Download two files 'openwrt-ixp4xx-squashfs.img' and 'openwrt-ixp4xx-zImage'<br />
<br />
C. Upload OpenWRT onto the board<br />
==== A. Installing and setting up tftp server (Ubuntu, hardy)====<br />
The diagram below shows the setup we will be using to setup and test the tftp server. The tftp server machine, sun, will be given IP address 192.168.3.1 and the client machine, moon, will be given IP address 192.168.3.2.<br />
[[Image:Tftp.jpg|left|Tftp server (sun) to be tested using client PC(moon)]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
miguel@sun:~ sudo apt-get install xinetd tftpd tftp<br />
miguel@sun:~ vi /etc/xinetd.d/tftp <br />
;Add the following lines in /etc/xinetd.d/tftp<br />
service tftp<br />
{<br />
protocol = udp<br />
port = 69<br />
socket_type = dgram<br />
wait = yes<br />
user = nobody //Please note if you have trouble with running tftpd, change "nobody" to "root"<br />
server = /usr/sbin/in.tftpd<br />
server_args = /tftpboot<br />
disable = no<br />
}<br />
;Create /tftpboot directory<br />
miguel@sun:~ sudo mkdir /tftpboot<br />
miguel@sun:~ sudo chmod -R 777 /tftpboot //Please note the permissions need not be 777 but should be at least 444 (i.e readable by all) <br />
miguel@sun:~ sudo chown -R nobody /tftpboot //Please change "nobody" to "root" if in file /etc/xinetd.d/tftp you have specified "root"<br />
<br />
;Start tftpd using xinetd<br />
<br />
miguel@sun:~ sudo /etc/init.d/xinetd start<br />
<br />
;Testing tftp server <br />
We test tftp server by transfering a file from a client called 'moon' with IP address 192.168.3.2) to tftp server called 'sun' with IP address 192.168.3.1. Assuming you have file testTFTP.txt in your home directory on the client machine:<br />
miguel@moon:~ ls -l testTFTP.txt<br />
-rw-r--r-- 1 miguel miguel 3551088 2008-04-19 15:52 testTFTP.txt<br />
miguel@moon:~ tftp 192.168.3.1<br />
miguel@moon:~ trace<br />
miguel@moon:~ put testTFTP.txt<br />
sent WRQ <file=testTFTP.txt, mode=netascii><br />
received ACK <block=0><br />
sent DATA <block=1, 512 bytes><br />
received ACK <block=1><br />
sent DATA <block=2, 512 bytes><br />
received ACK <block=2><br />
.<br />
.<br />
.<br />
received]] ACK <block=6933><br />
sent DATA <block=6934, 512 bytes><br />
received ACK <block=6934><br />
sent DATA <block=6935, 512 bytes><br />
received ACK <block=6935><br />
sent DATA <block=6936, 368 bytes><br />
received ACK <block=6936><br />
Sent 3551088 bytes in 5.8 seconds<br />
Now logon to the 'sun' machine (the tftp server) and run 'ls' and your uploaded file should be there(hopefully).<br />
miguel@sun:~ ls - -l /tftpboot/<br />
-rw-r--r-- 1 root root 3551088 2008-04-19 15:52 testTFTP.txt<br />
;We now have a working tftp server!!<br />
<br />
==== B. '''Download''' two files, '''openwrt-ixp4xx-squashfs.img''' and '''openwrt-ixp4xx-zImage''' on to tftp server====<br />
<br />
Visit http://ftp.iasi.roedu.net/mirrors/openwrt.org/snapshots/ixp4xx/ and download files ''openwrt-ixp4xx-squashfs.img'' and ''openwrt-ixp4xx-zImage'' and save these files to /tftpboot directory of the tftp server. Make sure the files are readable <br />
miguel@sun:~ ls - -l /tftpboot/<br />
-rw-r--r-- 1 root root 3551088 2008-04-19 15:52 testTFTP.txt<br />
-rw-r--r-- 1 root root 1179648 2008-08-06 18:32 openwrt-ixp4xx-squashfs.img<br />
-rw-r--r-- 1 root root 1034156 2008-08-06 18:32 openwrt-ixp4xx-zImage<br />
<br />
<br />
<br />
==== C. Upload OpenWRT onto the board====<br />
Make sure you have a terminal emulation program, like minicom(*nix) or HyperTerminal(Windows). <br />
<br />
Setting up the serial interface on your Laptop/PC. Startup minicom and then Type "Ctrl+a o" or "Ctrl+A O" <br />
<br />
+-----[configuration]------+ <br />
| Filenames and paths |<br />
| File transfer protocols |<br />
| Serial port setup |<br />
| Modem and dialing |<br />
| Screen and keyboard |<br />
| Save setup as dfl |<br />
| Save setup as.. |<br />
| Exit |<br />
+--------------------------+<br />
<br />
Scroll down to option ''Serial port setup''<br />
<br />
+-----------------------------------------------------------------------+<br />
| A - Serial Device : /dev/ttyS0 |<br />
| B - Lockfile Location : /var/lock |<br />
| C - Callin Program : |<br />
| D - Callout Program : |<br />
| E - Bps/Par/Bits : 115200 8N1 |<br />
| F - Hardware Flow Control : No |<br />
| G - Software Flow Control : No |<br />
| |<br />
| Change which setting? |<br />
+-----------------------------------------------------------------------+<br />
<br />
Select the letters A-G to change the settings and press the "enter" key to get out of the menu back to the main menu. The final settings should be as shown above.<br />
<br />
Connect the Avila board to your PC/laptop using a serial cable. Power-up the Avila and repeatedly press Ctrl+C until the board displays Redboot. This is what I see on my board:<br />
+No devices on IDE controller 0<br />
Trying NPE-B...success. Using NPE-B with PHY 0.<br />
Ethernet eth0: MAC address 00:d0:12:03:24:67<br />
IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0<br />
Default server: 192.168.3.1<br />
<br />
RedBoot(tm) bootstrap and debug environment [ROM]<br />
Gateworks certified release, version 2.02 - built 05:22:19, Mar 3 2006<br />
<br />
Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE<br />
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.<br />
Copyright (C) 2004, 2005 Gateworks Corporation<br />
<br />
RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available<br />
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.<br />
== Executing boot script in 2.500 seconds - enter ^C to abort<br />
^C<br />
RedBoot> ^C<br />
RedBoot> ^C<br />
<br />
As shown, my board has the follwoing IP settings:<br />
<br />
Local IP address: 192.168.3.2<br />
Local IP address mask: 255.255.255.0<br />
Default server IP address: 192.168.3.1<br />
<br />
If after pressing Ctrl+C your board didn't not display the same information as above, then to see your IP settings do this <br />
RedBoot> ip_address<br />
IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0<br />
Default server: 192.168.3.1<br />
Use the "ip_address" command to change the IP settings if you need to. Remember in our case we have the tftp server set to 192.168.3.1 so the line "Default server: 192.168.3.1" above is correct. Change yours if it's not correct.<br />
<br />
<br />
Now we need to initialize the FLASH<br />
RedBoot>fis init<br />
Answer yes by typing Y or y to the question below<br />
About to initialize [format] FLASH image system - continue (y/n)?<br />
You should see the following output:<br />
*** Initialize FLASH Image System<br />
... Erase from 0x50080000-0x50fe0000: ...............................<br />
.....................................................................<br />
.......................<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
RedBoot><br />
Next we check to see free available space<br />
RedBoot> fis free<br />
0x50080000 .. 0x50FE0000<br />
Therefore we have 0x00f60000 (16MB) available space<br />
We now copy the linux file from the ftp server as raw data (option -r) to memory address 0x0080000 (option -b) and want a progress indicator (option -v).<br />
RedBoot> load -r -v -b 0x00800000 openwrt-ixp4xx-zImage<br />
This process should take about 5 seconds,if you get any errors then make sure you have the tftp server running correctly and that the file you are copying is there, and further that the IP addresses are correct. From the above command you should see:<br />
Using default protocol (TFTP)<br />
/<br />
Raw file loaded 0x00800000-0x00967c93, assumed entry at 0x00800000<br />
RedBoot><br />
We proceed to create a flash image which we call 'linux' from the the file we've just loaded from the tftp server.<br />
RedBoot> fis create linux<br />
The output should be<br />
... Erase from 0x50080000-0x50280000: ................<br />
... Program from 0x00800000-0x00a00000 at 0x50080000: ................<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
RedBoot><br />
<br />
then need to <br />
We now need to copy the root filesystem from the tftp server as raw data (option -r) to memory address 0x0080000 (option -b) and want a progress indicator (option -v). Type the following command;<br />
RedBoot> load -r -v -b 0x00800000 openwrt-ixp4xx-squashfs.img<br />
The output is:<br />
Using default protocol (TFTP)<br />
/<br />
Raw file loaded 0x00800000-0x00d13fff, assumed entry at 0x00800000 <br />
RedBoot><br />
We once again check to see the available flash space<br />
RedBoot> fis free<br />
0x50180000 .. 0x50FE0000<br />
Therefore we have 0x00EF0000(about 14.7MB) of flash available.<br />
<br />
We then proceed to create an root filesystem image onto the FLASH using the entire available space.<br />
RedBoot> fis create -l 0xe60000 rootfs<br />
<br />
The output should be:<br />
... Erase from 0x50180000-0x50fe0000: ...................................................................................................................<br />
... Program from 0x00800000-0x00920000 at 0x50180000: .........<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
RedBoot> <br />
<br />
Finally, we run the ''fconfig'' command to write the boot script and also make any changes we may need.<br />
RedBoot> fconfig<br />
For our purposes we will only specify the boot script and leave the other settings unchanged by entering the "Enter" key. The boot script we will enter is:<br />
<br />
>> fis load linux<br />
>> exec<br />
Hit the "enter" key twice after the "exec" word. <br />
Enter Y or y when prompted with <br />
Update RedBoot non-volatile configuration - continue (y/n)? y <br />
The complete output should be:<br />
RedBoot> fconfig<br />
Run script at boot: true<br />
Boot script: <br />
Enter script, terminate with empty line<br />
>> fis load linux<br />
>> exec<br />
>> <br />
Boot script timeout (100ms resolution): 25<br />
Use BOOTP for network configuration: false<br />
Gateway IP address: <br />
Local IP address: 192.168.3.2<br />
Local IP address mask: 255.255.255.0<br />
Default server IP address: 192.168.3.1<br />
Console baud rate: 115200<br />
GDB connection port: 9000<br />
Force console for special debug messages: false<br />
Network debug at boot time: false<br />
Default network device: npe_eth0<br />
Update RedBoot non-volatile configuration - continue (y/n)? y<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
RedBoot> <br />
Now we reset the Avila board<br />
RedBoot> reset<br />
<br />
<br />
Linux should now be booting. After a long display of messages you should see the message:<br />
mini_fo: using storage directory: /jffs<br />
- init -<br />
After which it prints<br />
Please press Enter to activate this console.<br />
If you happened to have missed these above messages and it appears as though the board has "hanged" you need to hit the "Enter" key to see the prompt.<br />
BusyBox v1.8.2 (2008-08-06 07:33:12 PDT) built-in shell (ash)<br />
Enter 'help' for a list of built-in commands. <br />
<br />
_______ ________ __<br />
| |.-----.-----.-----.| | | |.----.| |_<br />
| - || _ | -__| || | | || _|| _|<br />
|_______|| __|_____|__|__||________||__| |____|<br />
|__| W I R E L E S S F R E E D O M<br />
KAMIKAZE (bleeding edge, r12194) -------------------<br />
* 10 oz Vodka Shake well with ice and strain<br />
* 10 oz Triple sec mixture into 10 shot glasses.<br />
* 10 oz lime juice Salute!<br />
---------------------------------------------------<br />
root@OpenWrt:/#<br />
<br />
End!!<br />
===NOTES===<br />
In the above the steps, the root filesystem and the kernel were two different files. In the section on downloading and making our own customized images, we'll show how to combine the two files into one, so that from Redboot we only load one file instead of two.<br />
<br />
== Configuring the Avila board ==<br />
===Configuring the Ethernet ports ===<br />
By default(from the downloaded images), the two Ethernet ports (eth0 and eth1) are not configurable since their hardware addresses are 00:00:00:00:00:00<br />
root@OpenWrt:~# ifconfig -a<br />
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 <br />
BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br />
<br />
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 <br />
BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br />
<br />
On further inspection, I found that the reason why the hardware addresses are 00:00:00:00:00:00 is because the network drivers for the LAN interfaces were neither loaded (as modules) nor created during compilation! A solution to the above problem is to download (svn) the source (either the trunk or kamikaze) and then make sure that the LAN network driver modules created/loaded.<br />
<br />
===Working from the source code===<br />
Create a working space from which you run:<br />
svn co https://svn.openwrt.org/openwrt/trunk/ ///To download the trunk<br />
OR!!!<br />
svn co https://svn.openwrt.org/openwrt/tags/kamikaze_7.09 ///To download the kamikaze release<br />
<br />
The following steps apply to either the trunk or Kamikaze. After the above commands are done the run:<br />
$make<br />
OR!!<br />
$make menuconfig<br />
<br />
====To merge the kernel and root filesystem into one image====<br />
During menuconfig, select '''ramdisk''' under option '''Target Images'''. Save the configuration, exit the menu and type '''make''' again.<br />
$make<br />
The build process will take a few hours since it has to download the sources and only then it build the images.<br />
<br />
After the build process, in the '''bin''' directory you will have either two files '''openwrt-ixp4xx-squashfs.img''' and '''openwrt-ixp4xx-zImage''' or only one file '''openwrt-ixp4xx-zImage''' (provided your selected '''ramdisk''' as you '''Target Image''')<br />
<br />
'''NOTE: Ramdisk means all changes, you make on the filesystem, will be lost on reboot.'''<br />
<br />
====Load the image(s)====<br />
Follow the steps described above in section '''C. Upload OpenWRT onto the board''' to load the images. Check the LAN addresses<br />
root@OpenWrt:~# ifconfig -a<br />
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 <br />
BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br />
<br />
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 <br />
BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br />
<br />
Alas, the LAN hardware addresses are still 00:00:00:00:00:00!!!<br />
====Diagnostics====<br />
When the system starts up, look at the following messages<br />
Using base address 0x00800000 and length 0x0031d030<br />
Uncompressing Linux.......................................................................................................................................... done, booting the kernel.<br />
Linux version 2.6.26.2 (lawrence@bluesky) (gcc version 4.1.2) #1 Fri Aug 22 12:44:15 SAST 2008<br />
CPU: XScale-IXP42x Family [690541c1] revision 1 (ARMv5TE), cr=000039ff<br />
Machine: Intel IXDP425 Development Platform<br />
And in particular the line <br />
Machine: Intel IXDP425 Development Platform<br />
It should instead say<br />
Machine: Gateworks Avila Network Platform<br />
<br />
Check Redboot's version <br />
RedBoot> version<br />
<br />
RedBoot(tm) bootstrap and debug environment [ROM]<br />
Gateworks certified release, version 2.02 - built 05:22:19, Mar 3 2006<br />
<br />
Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE<br />
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.<br />
Copyright (C) 2004, 2005 Gateworks Corporation<br />
<br />
RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available<br />
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.<br />
Apparently this version of Redboot is old which causes it to pass a wrong machine id to the linux kernel; So instead of using openwrt-ixp4xx-zImage as the kernel use the kernel named openwrt-avila-zImage, and everything should be fine.<br />
<br />
Pheeew!!!<br />
====Final Solution====<br />
So here's the short of story of the above<br />
RedBoot> ^C<br />
RedBoot> fis init<br />
<br />
About to initialize [format] FLASH image system - continue (y/n)? y<br />
*** Initialize FLASH Image System<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
<br />
RedBoot> load -r -v -b 0x00800000 openwrt-avila-zImage<br />
<br />
<br />
Using default protocol (TFTP)<br />
\<br />
Raw file loaded 0x00800000-0x008f211f, assumed entry at 0x00800000<br />
<br />
RedBoot> fis create linux<br />
<br />
... Erase from 0x50080000-0x50180000: ........<br />
... Program from 0x00800000-0x008f2120 at 0x50080000: ........<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
<br />
RedBoot> load -r -v -b 0x00800000 openwrt-ixp4xx-squashfs.img<br />
<br />
Using default protocol (TFTP)<br />
\<br />
Raw file loaded 0x00800000-0x0093ffff, assumed entry at 0x00800000<br />
<br />
RedBoot> fis create -l 0xe60000 rootfs<br />
<br />
... Erase from 0x50180000-0x50fe0000: ...................................................................................................................<br />
... Program from 0x00800000-0x00940000 at 0x50180000: ..........<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
<br />
RedBoot> fconfig<br />
<br />
Run script at boot: true<br />
Boot script: <br />
.. fis load linux<br />
.. exec<br />
Enter script, terminate with empty line<br />
>> fis load linux<br />
>> exec<br />
>> <br />
Boot script timeout (100ms resolution): 25<br />
Use BOOTP for network configuration: false<br />
Gateway IP address: <br />
Local IP address: 192.168.3.2<br />
Local IP address mask: 255.255.255.0<br />
Default server IP address: 192.168.3.1<br />
Console baud rate: 115200<br />
GDB connection port: 9000<br />
Force console for special debug messages: false<br />
Network debug at boot time: false<br />
Default network device: npe_eth0<br />
Update RedBoot non-volatile configuration - continue (y/n)? y<br />
... Unlock from 0x50fe0000-0x51000000: .<br />
... Erase from 0x50fe0000-0x51000000: .<br />
... Program from 0x03fe0000-0x04000000 at 0x50fe0000: .<br />
... Lock from 0x50fe0000-0x51000000: .<br />
<br />
RedBoot> reset<br />
<br />
<br />
===Customizing the firmware===<br />
To include your startup scripts do:<br />
<br />
1) Create a directory called '''files''' in the trunk/top directory<br />
<br />
2) From within the '''files''' directory create the subdirectory(ies) and store the file in the appropriate directory<br />
<br />
3) Rebuild the firmware<br />
<br />
<br />
Examples, to have a passwd file in the /etc/ directory do:<br />
mkdir $(TOPDIR)/files/etc/<br />
cp passwd $(TOPDIR)/files/etc/passwd<br />
To have your startup script called '''myinit''' do:<br />
mkdir $(TOPDIR)/files/etc/<br />
cp myinit $(TOPDIR)/files/etc/init.d/myinit<br />
Please note, for startup scripts you MUST at the beginning of the file define the line START $NUMBER<br />
<br />
e.g.<br />
START 40<br />
This will cause a file '''S40myinit''' to be created in directory /etc/rc.d/<br />
<br />
====Passing kernel commands at boot time====<br />
By default the kernel is passed the following commands:<br />
root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit<br />
The above parameters are specified in the '''kernel_menuconfig" option of make, so do:<br />
$make kernel_menuconfig //then select the '''Boot options''' option<br />
<br />
===Network connection===<br />
I've compiled in the firewall, which by default blocks all incoming connections. For now simply switch off the firewall<br />
root@OpenWrt:/# chmod 666 /etc/init.d/firewall<br />
root@OpenWrt:/# reboot<br />
====Kernel error when loading linux kernel====<br />
I now enable wireless interface wifi0 from file ''''/etc/config/wireless'''.<br />
config wifi-device wifi0<br />
option type atheros<br />
option channel 11 <br />
<br />
# REMOVE THIS LINE TO ENABLE WIFI:<br />
# option disabled 1<br />
<br />
config wifi-iface<br />
option device wifi0<br />
option mode sta<br />
option ssid avilabatman <br />
option encryption none <br />
Now I reboot the board..<br />
root@OpenWrt:/# reboot<br />
Below is what happens<br />
<br />
Trying NPE-B...success. Using NPE-B with PHY 0.<br />
Ethernet eth0: MAC address 00:d0:12:03:24:67<br />
IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0<br />
Default server: 192.168.3.1<br />
<br />
RedBoot(tm) bootstrap and debug environment [ROM]<br />
Gateworks certified release, version 2.02 - built 05:22:19, Mar 3 2006 <br />
<br />
Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE<br />
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.<br />
Copyright (C) 2004, 2005 Gateworks Corporation <br />
<br />
RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available<br />
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.<br />
== Executing boot script in 2.500 seconds - enter ^C to abort<br />
RedBoot> fis load linux<br />
RedBoot> exec<br />
Using base address 0x00800000 and length 0x000f9378<br />
Uncompressing Linux..................................................................... done, booting the kernel.<br />
Linux version 2.6.26.2 (lawrence@bluesky) (gcc version 4.1.2) #3 Mon Aug 25 15:15:49 SAST 2008<br />
CPU: XScale-IXP42x Family [690541c1] revision 1 (ARMv5TE), cr=000039ff<br />
Machine: Gateworks Avila Network Platform<br />
Memory policy: ECC disabled, Data cache writeback<br />
CPU0: D VIVT undefined 5 cache<br />
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets<br />
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets<br />
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256<br />
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit<br />
PID hash table entries: 256 (order: 8, 1024 bytes)<br />
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)<br />
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)<br />
Memory: 64MB = 64MB total<br />
Memory: 62720KB available (1892K code, 180K data, 100K init)<br />
SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1<br />
Mount-cache hash table entries: 512<br />
CPU: Testing write buffer coherency: ok<br />
net_namespace: 640 bytes<br />
NET: Registered protocol family 16<br />
IXP4xx: Using 16MiB expansion bus window size<br />
PCI: IXP4xx is host<br />
PCI: IXP4xx Using direct access for memory space<br />
PCI: bus0: Fast back to back transfers enabled<br />
dmabounce: registered device 0000:00:04.0 on pci bus<br />
NET: Registered protocol family 2<br />
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)<br />
TCP established hash table entries: 2048 (order: 2, 16384 bytes)<br />
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)<br />
TCP: Hash tables configured (established 2048 bind 2048)<br />
TCP reno registered<br />
NET: Registered protocol family 1<br />
IXP4xx Queue Manager initialized.<br />
squashfs: version 3.0 (2006/03/15) Phillip Lougher<br />
Registering mini_fo version $Id$<br />
JFFS2 version 2.2. (NAND) (SUMMARY) �© 2001-2006 Red Hat, Inc.<br />
msgmni has been set to 122<br />
io scheduler noop registered<br />
io scheduler deadline registered (default)<br />
gpiodev: gpio device registered with major 253<br />
gpiodev: gpio platform device registered with access mask 000002AA<br />
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled<br />
serial8250.0: ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale<br />
console [ttyS0] enabled<br />
serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale<br />
IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank<br />
Intel/Sharp Extended Query Table at 0x0031<br />
Using buffer write method<br />
cfi_cmdset_0001: Erase suspend on write enabled<br />
Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0xfe0000<br />
5 RedBoot partitions found on MTD device IXP4XX-Flash.0<br />
Creating 5 MTD partitions on "IXP4XX-Flash.0":<br />
0x00000000-0x00080000 : "RedBoot"<br />
0x00080000-0x00180000 : "linux"<br />
0x00180000-0x00fe0000 : "rootfs"<br />
mtd: partition "rootfs" set to be root filesystem<br />
mtd: partition "rootfs_data" created automatically, ofs=2E0000, len=D00000 <br />
0x002e0000-0x00fe0000 : "rootfs_data"<br />
0x00fe0000-0x00fff000 : "FIS directory"<br />
0x00fff000-0x01000000 : "RedBoot config"<br />
i2c /dev entries driver<br />
ds1672 0-0068: chip found, driver version 0.4<br />
ds1672 0-0068: rtc core: registered ds1672 as rtc0<br />
i2c-gpio i2c-gpio.0: using pins 7 (SDA) and 6 (SCL)<br />
ad7418 0-0028: ad7418 chip found<br />
ad7418 0-0028: configuring for mode 1<br />
IXP4xx Watchdog Timer: heartbeat 60 sec<br />
nf_conntrack version 0.5.0 (1024 buckets, 4096 max)<br />
ip_tables: (C) 2000-2006 Netfilter Core Team<br />
TCP westwood registered<br />
NET: Registered protocol family 17<br />
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com><br />
All bugs added by David S. Miller <davem@redhat.com><br />
XScale DSP coprocessor detected.<br />
Unknown/missing Avila model number -- defaults will be used<br />
eth0: MII PHY 0 on NPE-B<br />
eth1: MII PHY 1 on NPE-C<br />
Registered led device: user<br />
ds1672 0-0068: setting system clock to 2009-08-26 12:35:01 UTC (1251290101)<br />
VFS: Mounted root (squashfs filesystem) readonly.<br />
Freeing init memory: 100K<br />
Please be patient, while OpenWrt loads ...<br />
- preinit -<br />
Press CTRL-C for failsafe<br />
switching to jffs2<br />
mini_fo: using base directory: /<br />
mini_fo: using storage directory: /jffs<br />
- init - <br />
<br />
Please press Enter to activate this console. firmware: requesting NPE-B<br />
NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL<br />
NPE-B: firmware functionality 0x2, revision 0x2:1<br />
eth0: link down<br />
NET: Registered protocol family 10<br />
lo: Disabled Privacy Extensions<br />
ADDRCONF(NETDEV_UP): eth0: link is not ready<br />
PPP generic driver version 2.4.2<br />
ip6_tables: (C) 2000-2006 Netfilter Core Team<br />
ipt_time loading<br />
wlan: trunk<br />
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1<br />
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready<br />
ath_hal: module license 'Proprietary' taints kernel.<br />
ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417, REGOPS_FUNC)<br />
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk)<br />
ath_rate_minstrel: look around rate set to 10%<br />
ath_rate_minstrel: EWMA rolloff level set to 75%<br />
ath_rate_minstrel: max segment size in the mrr set to 6000 us<br />
wlan: mac acl policy registered<br />
ath_pci: trunk<br />
PCI: enabling device 0000:00:04.0 (0340 -> 0342)<br />
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps<br />
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps<br />
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps<br />
wifi0: H/W encryption support: WEP AES AES_CCM TKIP<br />
ath_pci: wifi0: Atheros 5413: mem=0x48000000, irq=25<br />
skb_under_panic: text:bf0ba140 len:28 put:24 head:c300c61e data:c300c5f8 tail:0xc300c614 end:0xc300c680 dev:<NULL><br />
Unable to handle kernel NULL pointer dereference at virtual address 00000000<br />
pgd = c3f1c000<br />
[00000000] *pgd=03f4d031, *pte=00000000, *ppte=00000000<br />
Internal error: Oops: 817 [#1]<br />
Modules linked in: ath_pci wlan_xauth wlan_wep wlan_tkip wlan_ccmp wlan_acl ath_rate_minstrel ath_hal(P) wlan_scan_sta wlan_scan_ap wlan nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_TTL xt_MAi<br />
CPU: 0 Tainted: P (2.6.26.2 #3)<br />
pc : [<c01376b0>] lr : [<c002d4f8>] psr: 60000013<br />
sp : c3039d4c ip : c020630c fp : c3039d7c<br />
r10: c3e7815c r9 : c3e7a000 r8 : c3e7815c<br />
r7 : c300c680 r6 : c300c614 r5 : c300c5f8 r4 : c300c61e<br />
r3 : 00000000 r2 : 60000013 r1 : 00000001 r0 : 00000076<br />
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user<br />
Control: 000039ff Table: 03f1c000 DAC: 00000015<br />
Process wifi (pid: 2227, stack limit = 0xc3038260)<br />
Stack: (0xc3039d4c to 0xc303a000)<br />
9d40: c300c61e c300c5f8 c300c614 c300c680 c01dadb0 <br />
9d60: c300c61e c3e380c0 00000040 c3e78360 c3039d94 c3039d80 c0138548 c0137668 <br />
9d80: c3f903f0 c3e78360 c3039dc0 c3039d98 bf0ba140 c0138518 c3f903f0 c3e78360 <br />
9da0: c3e7a000 c3e380c0 c3f90360 00000000 00000000 c3039e08 c3039dc4 bf0ba804 <br />
9dc0: bf0b9fa8 c3e785a4 c3e7815c c3e7815c c3e7815c c3e7815c c3e785a4 c300c622 <br />
9de0: c3c3b000 00000000 c3e78360 c3f90494 c3e7815c 00000014 c3c1b700 c3039e48 <br />
9e00: c3039e0c bf0bfacc bf0ba6d8 bf0cc8d0 00000000 00000000 00000000 c3e785a4 <br />
9e20: 00000100 bf0bf98c c0219200 00000000 c3038000 c3eac5c0 c3c1b700 c3039e74 <br />
9e40: c3039e4c c003b13c bf0bf998 c3039e4c c3039e4c 00000081 c021900c 0000000a <br />
9e60: 00000000 00000011 c3039e90 c3039e78 c0036ff4 c003b000 00000005 c0207c8c <br />
9e80: 00000000 c3039ea0 c3039e94 c0037380 c0036fa4 c3039ebc c3039ea4 c0021048 <br />
9ea0: c0037348 ffffffff 0000001f 00000020 c3039f48 c3039ec0 c0021664 c002100c <br />
9ec0: c3eac5c0 00000004 000008cc 60000013 c3038000 c3e0d1e0 c3eac5c0 00000000 <br />
9ee0: 00000011 c3eac5c0 c3c1b700 c3039f48 000000fc c3039f08 00000000 c003122c <br />
9f00: 60000013 ffffffff c3eac5c0 c3039fb0 00000000 c3039fb0 be803308 00000000 <br />
9f20: 000a18c0 00000011 00000000 00000000 00000000 00000000 c3039fb0 c3039f8c <br />
9f40: c3039f4c c00315a4 c0030680 00000000 c3f0de80 c3039f60 c007c004 c0073e00 <br />
9f60: 00000000 000a18c0 0009a238 000abccc 00000002 c0021be4 c3038000 000af22f <br />
9f80: c3039fa4 c3039f90 c0024b84 c00314b4 00000000 00000000 00000000 c3039fa8 <br />
9fa0: c0021a40 c0024b5c 000a18c0 0009a238 000a18c0 000abccc 00000002 00000010 <br />
9fc0: 000a18c0 0009a238 000abccc 00000002 00000008 00000044 000af22f 000a18c0 <br />
9fe0: 000993f8 be803308 0002ecec 400630f8 60000010 000a18c0 00000000 00000000 <br />
Backtrace: <br />
Function entered at [<c013765c>] from [<c0138548>]<br />
r7:c3e78360 r6:00000040 r5:c3e380c0 r4:c300c61e<br />
Function entered at [<c013850c>] from [<bf0ba140>]<br />
r5:c3e78360 r4:c3f903f0<br />
Function entered at [<bf0b9f9c>] from [<bf0ba804>]<br />
Function entered at [<bf0ba6cc>] from [<bf0bfacc>]<br />
Function entered at [<bf0bf98c>] from [<c003b13c>]<br />
Function entered at [<c003aff4>] from [<c0036ff4>]<br />
r8:00000011 r7:00000000 r6:0000000a r5:c021900c r4:00000081<br />
Function entered at [<c0036f98>] from [<c0037380>]<br />
r6:00000000 r5:c0207c8c r4:00000005<br />
Function entered at [<c003733c>] from [<c0021048>]<br />
Function entered at [<c0021000>] from [<c0021664>]<br />
Exception stack(0xc3039ec0 to 0xc3039f08)<br />
9ec0: c3eac5c0 00000004 000008cc 60000013 c3038000 c3e0d1e0 c3eac5c0 00000000 <br />
9ee0: 00000011 c3eac5c0 c3c1b700 c3039f48 000000fc c3039f08 00000000 c003122c <br />
9f00: 60000013 ffffffff <br />
r6:00000020 r5:0000001f r4:ffffffff<br />
Function entered at [<c0030674>] from [<c00315a4>]<br />
Function entered at [<c00314a8>] from [<c0024b84>]<br />
Function entered at [<c0024b50>] from [<c0021a40>]<br />
Code: e88d00f0 e58dc010 ebfbee2d e3a03000 (e5833000) <br />
Kernel panic - not syncing: Fatal exception in interrupt<br />
<br />
Now recompiled the images, first without the madwidi drivers but then the wireless interfaces were not configurable. Then rebuilt the images with madwifi back in; and so far the kernel panic has not occurred. I will need to investigate further as to what causes the kernel panic.<br />
====Current configuration of the board at startup====<br />
1) Switch off the firewall<br />
root@OpenWrt:~# chmod 666 /etc/init.d/firewall<br />
2) Configuration of the interfaces '''/etc/config/network'''<br />
# Copyright (C) 2006 OpenWrt.org<br />
<br />
config interface loopback<br />
option ifname lo<br />
option proto static<br />
option ipaddr 127.0.0.1<br />
option netmask 255.0.0.0<br />
<br />
config interface lan<br />
option ifname eth0<br />
# option type bridge<br />
option proto static<br />
option ipaddr 192.168.1.1<br />
option netmask 255.255.255.0<br />
<br />
config interface eth1<br />
option ifname eth1<br />
option proto dhcp<br />
<br />
<br />
config interface ath0<br />
option ifname ath0<br />
option proto static<br />
option ipaddr 172.16.1.1<br />
option netmask 255.255.255.0<br />
2) Configguration of the wireless devices '''/etc/config/wireless'''<br />
config wifi-device wifi0<br />
option disabled 0<br />
option type atheros<br />
option channel 149<br />
option agmode 11a<br />
option country za<br />
<br />
config wifi-iface <br />
option device wifi0 <br />
option mode adhoc <br />
option ssid apex_wifi0 <br />
<br />
config wifi-device wifi1 <br />
option disabled 0 <br />
option type atheros <br />
option channel 157 <br />
option agmode 11a <br />
option country za<br />
<br />
config wifi-iface <br />
option device wifi1 <br />
option mode adhoc<br />
option ssid apex_wifi1<br />
<br />
config wifi-device wifi2 <br />
option disabled 0 <br />
option type atheros <br />
option channel 11 <br />
option agmode 11bg <br />
option country za<br />
<br />
config wifi-iface <br />
option device wifi2 <br />
option network lan <br />
option mode ap <br />
option ssid apex_hotspot <br />
option encryption none <br />
<br />
3) Web server configuration <br />
<br />
Either by hand or within the startup script of udhcpd, do this:<br />
mkdir -p /var/lib/misc<br />
touch /var/lib/misc/udhcpd.leases<br />
Otherwise udhcpd will fail to start.<br />
root@OpenWrt:/# udhcpd -f /etc/udhcpd.conf <br />
<br />
udhcpd (v1.8.2) started<br />
udhcpd: can't open '/var/lib/misc/udhcpd.leases': No such file or directory<br />
udhcpd: bind: Address already in use<br />
<br />
If you see this error message <br />
udhcpd (v1.8.2) started<br />
udhcpd: bind: Address already in use<br />
Then do this <br />
root@OpenWrt:/etc# netstat -l<br />
and if it shows <br />
udp 0 0 0.0.0.0:67 0.0.0.0:* <br />
Then most likely you need to stop dnsmasq<br />
root@OpenWrt:/etc/rc.d# sh S60dnsmasq stop<br />
Here's the configuration file '''/etc/udhcpd.conf''' stub<br />
# replace these with your own ip address range as appropriate<br />
<br />
start 192.168.1.2<br />
end 192.168.1.250<br />
<br />
interface eth0 # replace this if your network runs on eth1, eth2, ath0, etc.<br />
# Make sure the IP address specified in "start" and "end"<br />
# match the IP address of the interface specified here<br />
<br />
# these options are for bootp.. PXE uses this to figure out which server to<br />
# go to for tftp. This will be the ip address of your dhcp/tftp server<br />
#siaddr 10.1.1.254<br />
#sname dhcp_server_name # the name of your dhcp server<br />
#boot_file /tftpboot/pxelinux.0<br />
<br />
#set up dns, routes and other info<br />
opt dns 192.168.1.1 # (replace with your DNS servers)<br />
opt subnet 255.255.255.0 # replace with your subnet if it's different<br />
opt router 192.168.1.1 # replace with your gateway<br />
option domain local<br />
option lease 864000 # 10 days of seconds<br />
#opt tftp 10.1.1.254 # the IP address of your tftp/dhcp server<br />
<br />
4) Wireless interfaces auto configuration at startup '''/etc/init.d/netinit'''<br />
<br />
Note this script is included in the firmware at build time. See section '''Customizing firmware'''<br />
#!/bin/sh /etc/rc.common<br />
# Copyright (C) 2008<br />
<br />
START=39<br />
<br />
<br />
#<br />
# This scheme of calculating IP addresses is based on two observed patterns:<br />
# 1. The Ethernet addresses for first Ethernet port(eth0) of the Avila boards differ on the 6th byte.<br />
# 2. The Ethernet addresses for Atheros cards (we have, so far) differ on the 6th byte<br />
#<br />
# So, for the IPv4 IP address,A.B.C.D,<br />
#<br />
# A -- is fixed, currently set to 10<br />
# B -- is the 6th byte of eth0's MAC address<br />
# C -- is the lowest nibble of the 6th byte of eth0's MAC address, for interface eth0 only<br />
# -- is the 6th byte of the wifi card's MAC address, for wifi interfaces only<br />
# D -- is fixed to 1<br />
#<br />
# E.g. For eth0 with MAC address 00:D0:12:03:24:67,<br />
# Interface ath0(wifi) with MAC address 00:80:48:4F:24:DA<br />
# Therefore,<br />
# the 6th byte is '67'<br />
# Implies;<br />
# eth0's IP address is 10.103.3.1<br />
# ath0's IP address is 10.103.218.1<br />
#<br />
#<br />
<br />
<br />
#<br />
# Returns A (which is always fixed) in IP address A.B.C.D<br />
#<br />
get_a_class()<br />
{<br />
a_class=10;<br />
echo "$a_class"<br />
}<br />
<br />
#<br />
# Returns B in IP address A.B.C.D<br />
#<br />
get_b_class()<br />
{<br />
b_class=$(ifconfig eth0 | grep HW | sed 's/^.*HWaddr //' | awk ' {split($1,e,":"); \<br />
b = "0x" e[6]; \<br />
printf("%01d\n", b); }')<br />
echo $b_class<br />
}<br />
<br />
#<br />
# Input : interface name<br />
# Returns : C in IP address A.B.C.D<br />
#<br />
get_c_class()<br />
{<br />
case $1 in<br />
# wifi*) c_class=$(ifconfig $1 | grep HW | sed 's/^.*HWaddr //' | awk ' {split($1,e,"-"); \<br />
# c = "0x" e[6]; \<br />
#<br />
# printf("%01d\n", c); }')<br />
wifi0) c_class=0<br />
;;<br />
wifi1) c_class=1<br />
;;<br />
wifi2) c_class=2<br />
;;<br />
<br />
eth*) c_class=$(ifconfig $1 | grep HW | sed 's/^.*HWaddr //' | awk ' {split($1,e,":"); \<br />
c = "0x" e[6]; c = and (c,0x0f); \<br />
printf("%01d\n", c); }')<br />
;;<br />
*) c_class=10<br />
;;<br />
esac<br />
<br />
echo $c_class<br />
}<br />
<br />
<br />
#<br />
# Input : Ethernet interface name<br />
# Output : A.B.C.D<br />
#<br />
get_ipaddr()<br />
{<br />
cc=$1<br />
echo $(get_a_class).$(get_b_class).$(get_c_class $1).1<br />
}<br />
<br />
<br />
create_dnsmasq_conf()<br />
{<br />
cat >/etc/dnsmasq.conf <<-EOF<br />
# filter what we send upstream<br />
domain-needed<br />
#<br />
bogus-priv<br />
filterwin2k<br />
localise-queries<br />
#<br />
# allow /etc/hosts and dhcp lookups via *.lan<br />
local=/lan/<br />
domain=lan<br />
expand-hosts<br />
no-negcache<br />
resolv-file=/etc/resolv.conf<br />
#<br />
# enable dhcp (start,end,netmask,leasetime)<br />
dhcp-authoritative<br />
dhcp-range=eth0,$(get_a_class).$(get_b_class).$(get_c_class eth0).100,$(get_a_class).$(get_b_class).$(get_c_class eth0).150,255.255.255.0,12h<br />
dhcp-range=ath2,$(get_a_class).$(get_b_class).$(get_c_class ath2).100,$(get_a_class).$(get_b_class).$(get_c_class ath2).150,255.255.255.0,12h<br />
dhcp-leasefile=/tmp/dhcp.leases<br />
#<br />
# use /etc/ethers for static hosts; same format as --dhcp-host<br />
# <hwaddr> <ipaddr><br />
read-ethers<br />
#<br />
# other useful options:<br />
# default route(s): dhcp-option=3,192.168.1.1,192.168.1.2<br />
# dns server(s): dhcp-option=6,192.168.1.1,192.168.1.2<br />
dhcp-option=15,"cids.org.za meraka.csir.co.za"<br />
EOF<br />
}<br />
<br />
create_network()<br />
{<br />
cat >/etc/config/network <<-EOF<br />
# Copyright 2008<br />
<br />
config interface loopback<br />
option ifname lo<br />
option proto static<br />
option ipaddr 127.0.0.1<br />
option netmask 255.0.0.0<br />
<br />
config interface eth0<br />
option ifname eth0<br />
option proto static<br />
option ipaddr $(get_ipaddr eth0)<br />
option netmask 255.255.255.0<br />
<br />
config interface eth1<br />
option ifname eth1<br />
option proto dhcp<br />
<br />
config interface ath0<br />
option ifname ath0<br />
option proto static<br />
option ipaddr $(get_ipaddr wifi0)<br />
option netmask 255.255.255.0<br />
<br />
config interface ath1<br />
option ifname ath1<br />
option proto static<br />
option ipaddr $(get_ipaddr wifi1)<br />
option netmask 255.255.255.0<br />
<br />
config interface ath2<br />
option ifname ath2<br />
option proto static<br />
option ipaddr $(get_ipaddr wifi2)<br />
option netmask 255.255.255.0<br />
EOF<br />
}<br />
<br />
create_wireless()<br />
{<br />
cat >/etc/config/wireless <<-EOF<br />
# Copyright 2008<br />
<br />
config wifi-device wifi0<br />
option disabled 0<br />
option type atheros<br />
option channel 110<br />
option agmode 11a<br />
<br />
config wifi-iface<br />
option device wifi0<br />
option mode adhoc<br />
option ssid avila_batman_backhaul0<br />
option encryption none<br />
<br />
config wifi-device wifi1<br />
option disabled 0<br />
option type atheros<br />
option channel 111<br />
option agmode 11a<br />
<br />
config wifi-iface<br />
option device wifi1<br />
option mode adhoc<br />
option ssid availa_batman_backhaul1<br />
option encryption none<br />
<br />
config wifi-device wifi2<br />
option disabled 0<br />
option type atheros<br />
option channel 11<br />
option agmode 11bg<br />
<br />
config wifi-iface<br />
option device wifi2<br />
option mode ap<br />
option ssid avila_batman_hotspot<br />
option encryption none<br />
<br />
EOF<br />
}<br />
<br />
start() {<br />
setup_switch() { return 0; }<br />
<br />
include /lib/network<br />
setup_switch<br />
[ -s /etc/config/wireless ] || \<br />
/sbin/wifi detect > /etc/config/wireless<br />
/sbin/wifi up<br />
chmod -x /etc/init.d/firewall<br />
sleep 1<br />
create_wireless<br />
create_dnsmasq_conf<br />
create_network<br />
/sbin/wifi up<br />
ifup -a<br />
### main logic ###<br />
#case "$1" in<br />
# start)<br />
# start<br />
# ;;<br />
#esac<br />
<br />
===Booting from Compact Flash===<br />
Kamikaze doesn't support Compact flash. So I got the latest source code branch (8.09) from Openwrt:<br />
svn co https://svn.openwrt.org/openwrt/branches/8.09<br />
<br />
I've created (using cfdisk /dev/sdb) four partitions on the 128MB of 32MB each. <br />
cfdisk /dev/sdb<br />
Then I created I ext2 file systems for all the the paritions using (mke2fs /dev/sdb1,2,3,4).<br />
mke2fs /dev/sdb1<br />
I copied the Linux kernel into the first partition (cp linux /dev/sdb1) and copied the root file system into the second partions (cp rootfs /dev/sdb2)<br />
$cp linux /dev/sdb1<br />
$cp rootfs /dev/sdb2<br />
<br />
Redboot script used so far:<br />
<br />
>> load -r -m disk -b 0x01600000 hda1:linux<br />
>> load -r -m disk -b 0x00800000 hda2:rootfs<br />
>> exec -c "rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit" 0x01600000<br />
<br />
Default kernel command as set in kamikaze (make kenerl_menuconfig) is:<br />
root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit<br />
<br />
<br />
DEFAULT BOOT SCRIPT ON AVILA BOARD<br />
RedBoot> fconfig<br />
Run script at boot: true<br />
Boot script: <br />
.. fis load ramdisk<br />
.. fis load zimage<br />
.. exec<br />
<br />
<br />
USING RAMDISK<br />
RedBoot> load -r -m disk -b 0x01600000 hda1:linux<br />
Raw file loaded 0x01600000-0x018f662f, assumed entry at 0x01600000<br />
RedBoot> exec -c "rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit" 0x01600000<br />
<br />
===Things to do===<br />
* Find out how the kernel scans for Mini-PCI slots. That is, how does it determine which slot to name/assign interface '''ath0''', '''ath1''', etc.<br />
* Configure udhcpd. '''Done!!!!'''<br />
* Ensure '''eth0''' does not accept DHCP-offered addresses when plugged to a network. At the moment it accepts IPv6 address.<br />
* Ensure '''eth1''' doesn't respond to DHCP requests. Although '''udhcpd.conf''' should do this!!!<br />
* Submit to OpenWRT that<br />
root@OpenWrt:~# hostid <br />
Segmentation fault<br />
*Create startup scripts for all services needed, batman, udhcpd, etc.<br />
*Find out if dnsmasq is needed, if so then resolve conflict with udhcpd.They both seem to use port 67!!!<br />
<br />
===NOTES===<br />
====Identifying the Mini-PCI slots to interface names====<br />
With the board facing up and the Ethernet ports facing away from you, the slot on your left (Top Left) is scanned first, followed by the slot on the right (Top Right), followed by the slot below the first slot (Bottom Left) and lastly the slot below the second one (Bottom Right).<br />
<br />
So if all slots are filled with cards you will have:<br />
<br />
Slot 1 (Top Left) -- ath0<br />
Slot 2 (Top Right) -- ath1<br />
Slot 3 (Bottom left) -- ath2<br />
Slot 4 (Bottom right) -- ath3<br />
<br />
However, please note that the assignment of interface names ( i.e ath0, 1, 2,...) depends on which device is found/detected first. I.e. if slot 1 is empty, then ath0 will be on slot 2, ath1 on slot 3, etc.<br />
<br />
==Features of the High Performance Node (HPN)==<br />
===Network configuration===<br />
====Ethernet Network====<br />
*'''eth0'''<br />
**Identification: This is the port closest to the power injector. <br />
**Function(s) : It provides power over Ethernet. It is used to respond to DHCP requests. <br />
**IP address : IP address is fixed.<br />
*'''eth1'''<br />
**Identification: It is the second port on the board<br />
**Function(s) : It receives DHCP offered IP addresses when plugged to a network<br />
**IP address : It has no fixed IP address. (Apropos!!)<br />
<br />
====Wireless network====<br />
*'''ath0'''<br />
**Identification: It's connected to a first 5GHz antenna<br />
**Function(s) : Provides backhaul<br />
**IP address : IP address is fixed and is determined/calculated based on the MAC address of the interface.<br />
**Channel : TBD<br />
**SSID : TBD<br />
**Mode : Ad-Hoc, 11a<br />
**Security : None(??)<br />
*'''ath1'''<br />
**Identification: It's connected to a second 5GHz antenna<br />
**Function(s) : Provides backhaul<br />
**IP address : IP address is fixed and is determined/calculated based on the MAC address of the interface.<br />
**Channel : TBD<br />
**SSID : TBD<br />
**Mode : Ad-Hoc, 11a<br />
**Security : None(??)<br />
*'''ath2'''<br />
**Identification: It's connected to a 2.4GHz antenna<br />
**Function(s) : Provides hotspot<br />
**IP address : IP address is fixed and is determined/calculated based on the MAC address of the interface.<br />
**Channel : TBD<br />
**SSID : TBD<br />
**Mode : Ad-Hoc, 11b/g<br />
**Security : None(??)<br />
**Other : .<br />
<br />
===Services running on the HPN===<br />
*DHCP server - udhcpd<br />
*Routing protocol - Batman(batmand)<br />
*Web server - mini_httpd<br />
*Web security - HTTPS and authentication<br />
<br />
==Misc==<br />
===Compiling user applications for mips/LinkSys===<br />
Go to the top directory of your openwrt tree and run: <br />
make menuconfig<br />
Select Broadcom for the "Target System"<br />
<br />
Select LinkSys for the "Target Profile"<br />
<br />
Then run<br />
make<br />
<br />
Then to compile the helllo.c use<br />
staging_dir_mipsel/mipsel-linux-uclibc/bin/gcc -static -o hello hello.c<br />
Note "-static" is VERY important!!!<br />
<br />
=Linksys Development=<br />
==Upgrading LinkSys to Mesh Node==<br />
Using your novell account logon to '''tera2'''; go to directory '''/home/lmboweni/''' and copy file '''freifunk-ipv6-en-1.6.22-11March2009.bin''' and upgrade your Linksys.<br />
<br />
Features in this version of the firmware:<br />
--Router will only work in an IPv6 backbone(d) network.<br />
--Peer-to-peer applications are handled by an 4over6 application<br />
--OLSR running is set to version 6<br />
<br />
===Making changes to the running system===<br />
<br />
Changes to the running system can be made through '''nvram''' settings or directing editing of the configuration files.<br />
<br />
'''Switching off the 4-over-6 application'''<br />
$vi /etc/olsrd.conf.temp<br />
remove or comment out the line '''''@@hna6ip46address@@'''''<br />
$cd /etc/init.d<br />
$sh -x S74over6<br />
$reboot</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=WISP-in-a-box_Way_Forward&diff=3832
WISP-in-a-box Way Forward
2008-08-04T19:55:55Z
<p>Kroux: </p>
<hr />
<div>This document remains very much a draft, but is the evolving specification for the WISP-in-a-box project.<br />
<br />
=== Overview ===<br />
<br />
[[Image:Grafic_(Modified).png|thumb|400px]]<br />
<br />
[[Image:Grafic-telco_(Modified).png|thumb|400px|Icon sources: http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]<br />
<br />
The entire WISP-in-a-box system consists of:<br />
<br />
* A central dashboard, running on the gateway server, from which: <br />
** the network can be monitored and all nodes can be configured <br />
** prepaid vouchers can be administered <br />
** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered<br />
** all functionality will work without upstream Internet access<br />
* Mesh nodes which:<br />
** receive configuration updates from the central dashboard<br />
** run a captive portal that interacts with clients and authenticates against the gateway server<br />
** run intra-mesh QoS software<br />
** route themselves intelligently using BATMAN<br />
<br />
=== Component Diagram ===<br />
<br />
The basic setup looks like the digram to the right. For the Village Telco project, many components are the same. There is some additional functionality that's desired, however, that can reside on top of the base WISP-in-a-box system.<br />
<br />
This document is going to mainly focus on specifying the needs of the mesh & networking side of things, with an eye towards exactly how voice-related services will be integrated (but not an elaborate discussion of the technologies themselves).<br />
<br />
=== Dashboard & Server ===<br />
==== Existing Dashboard Projects ====<br />
The OrangeMesh and Open-Mesh dashboards provide almost exactly the functionality we require. However, they have a number of problems: <br />
<br />
* Both dashboards require the nodes to be running ROBIN firmware to receive configuration updates. ROBIN, as it is now, only runs on Atheros-based devices, not Broadcom devices (like the Linksys WRT). Some semi-serious hacking will be required to add support for Broadcom devices into ROBIN, since right now it assumes the use of the Atheros-only MadWifi drivers.<br />
* With an eye towards localization & modularity, the OrangeMesh sources aren't quite what we'd like them to be.<br />
<br />
Because of these limitations, we may not want to use the OrangeMesh/Open-Mesh dashboard. We still want to imitate the same basic style of system, however, while adding some functionality to meet the additional needs of our dashboard (e.g. ability to administer vouchers and server services, things that the OrangeMesh/Open-Mesh dashboards don't cover).<br />
<br />
==== Our Approach ====<br />
We will start essentially from scratch on the dashboard, with the OrangeMesh dashboard as an example to work off of and borrow heavily from.<br />
<br />
The dashboard we will design will be highly modular, with a high-level menu in which the user can select a module to work with. A module might be an existing software component or a new one we've written. In the case of Network Status and Network Configuration, we can use the Orangemesh-Openmesh/ROBIN setup as a reference, and where appropriate can adapt their code to suit our needs. Other tools to borrow from include Zeroshell for network QoS configuration. Essential modules include:<br />
<br />
* Server Administration -- brings up Webmin<br />
** 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.<br />
* Vouchers -- brings up phpMyPrepaid, our data billing control system<br />
** 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<br />
** 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.<br />
* Network Status -- new custom dashboard component with following features:<br />
** A semi-detailed list of all the nodes in the mesh, including:<br />
*** the node's IP and MAC addresses<br />
*** the node's current status (simple up or down)<br />
*** when they were last heard from (when an update from that node was last received)<br />
*** how many hops and/or what route the node currently has to the gateway<br />
** Basic network usage statistics, data taken from RADIUS:<br />
*** Total bandwidth going out of the gateway in the last X amount of time<br />
*** Heaviest users of the network to monitor abuse (further information on individual users is available already in phpMyPrepaid)<br />
** Ability to test network throughput, either through:<br />
*** Simple interface to run iperf between any two nodes, or:<br />
*** Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools<br />
<br />
* Mesh Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):<br />
** Change SSID of mesh network<br />
** Change channel of mesh network<br />
** Other features? Open to discussion.<br />
** 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.<br />
* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:<br />
** On the server, for outgoing traffic going to the upstream connection<br />
** On the various nodes in the mesh, for intra-mesh network bandwidth management.<br />
* AP-only node configuration – new custom dashboard component that configures node that are only AP's, not part of the mesh. Configures:<br />
** SSID of AP<br />
** Channel of AP<br />
** Any kind of WPA authentication a user might want to run on the AP<br />
<br />
Possible other voice-related modules include Asterisk and A2billing modules or pages.<br />
<br />
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. <br />
<br />
All of the components of the larger dashboard will be skinned in a unified CSS style, with the potential for branding built in.<br />
<br />
=== Mesh Nodes ===<br />
The mesh nodes themselves will run OpenWRT. Node software includes:<br />
<br />
* Batman for routing<br />
* CoovaChilli as a local captive portal<br />
* Intra-mesh QoS software, configurable from the dashboard. Uncertain as to what tools exactly to use here, however borrowing from Zeroshell it may be possible to simply use netfilter/iptables & l7-filter. Using an existing tool here would be very nice, as this is a complex task.<br />
* A client daemon modeled on the ROBIN scripts that receives updates from the dashboard and sends any necessary information back to the dashboard. The client daemon will have to be co-developed with the dashboard.<br />
* Stripped-down Webmin server component so we can run remote Webmin commands on the node through the server's Webmin installation.<br />
* In addition to configuration through the dashboard, we will include a minimal web interface for configuring each individual node. This interface will run on the nodes, and can be a stripped-down version of X-WRT's webif^2 or FFLuCI. It would be useful if the interface could be designed such that it would run on any device regardless of that device's platform. This may be easy to do with existing abstractions in OpenWRT, but an alternative method would be for this interface to change the configuration of the local node via the update API, which is guaranteed to be fully abstracted, and let the update client for that device take care of making the actual changes.<br />
<br />
=== AP-only Nodes ===<br />
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:<br />
<br />
* CoovaChilli<br />
* Dashboard Client with:<br />
** AP-only node configuration module<br />
** CoovaChilli configuration module<br />
<br />
=== Task Breakdown ===<br />
Once the specification is agreed upon work can begin. At that time further task breakdowns may be useful, but at a high level the expectation currently is as follows (refer to above for details on what individual software piece entail):<br />
<br />
# Dashboard & first client development: Meraka<br />
## Further examination of ROBIN to see which parts of it can be modified for our purposes<br />
## Adaptation of Webmin's cluster tools for use on the mesh<br />
## Determine appropriate tools for QoS [starting point: Zeroshell]<br />
## Update API design & specification<br />
## Dashboard framework design and implementation<br />
## Mesh update client framework design and implementation<br />
## Dashboard module implementation<br />
### Network Monitoring<br />
### Network Configuration – basics (Channel, SSID, etc)<br />
### Network Configuration – QoS settings<br />
### Network Configuration – AP-only settings<br />
### Adapt phpMyPrepaid's CoovaChilli configuration to send out updates via standardized API rather than only changing local configuration file.<br />
## 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).<br />
## CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).<br />
<br />
# Minimal interface development for starter devices (at least the WRT, Mesh Potato, and Ubiquity nodes): Inveneo<br />
# Porting of mesh client to Ubiquity and Mesh Potato (most modules should be identical, but basic network configuration settings may be device-specific): Inveneo<br />
<br />
[[Category:WISP in a box]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=IP04&diff=3750
IP04
2008-07-28T20:56:13Z
<p>Kroux: </p>
<hr />
<div>= IP04 - Four Port IP-PBX =<br />
Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html<br />
= Assumptions = <br />
The IP04 can be configured with a combination of four FXO and/or FXS ports. This page describes how I started using one with 3 FXS (handset) and 1 FXO (linked to our corporate PABX). Assuming the IP04 is also linked on the local LAN.<br />
= Setup procedure =<br />
# Set IP address of your PC host ethernet interface temporarily to 192.168.1.99 (or anything you think think is available on 192.168.1.xx subnet, not 192.168.1.30).<br />
## myPC> ifconfig eth0 192.168.1.99/24<br />
# Check that the address 192.168.1.30 is not used<br />
## myPC> Ping 192.168.1.30 ... no replies. This is the factory default IP address of the IP04.<br />
# Unpack IPO4, plug into the LAN, telephone plug, and add 3 x telephone handsets<br />
## Check if IP04 work by dialing 6001, 6002, 6003 or 6004 on any one of the handsets<br />
# myPC> Telnet 192.168.1.30<br />
# Change network parameters to valid settings for your lan in /etc/rc.d/S10network-static<br />
## root~> vi /etc/rc.d/S10network-static<br />
## ... set the parameters and save<br />
## root~> reboot<br />
# Remember to set the IP address on your PC host back to the default for use on your lan<br />
<br />
== Try SIP to client ==<br />
# In SIP client (e.g. Ekiga), set SIP account with Registrar=IP address of IP04, user=sipguest, passwd=sipguest<br />
<br />
== Remove defunct public AIX demo account ==<br />
# Comment out [trunk_2] section of /etc/asterisk/users.conf as iaxtel.com is not accepting connections.<br />
<br />
== View configuration ==<br />
# asterisk -r<br />
# ip04*CLI> zap show channels<br />
# ip04*CLI> zap show channel 1<br />
For FXS modules (taking handsets), zaptel will show FXO, and for FXO modules (connect to exchange), zaptel will show FXS<br />
<br />
== Configure location ==<br />
For setting the appropriate frequency and pause set the region code in /etc/zaptel.conf<br />
# <br />
A list of tone specifications is available at: http://www.itu.int/ITUT/inr/forms/files/tones0203.pdf</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=IP04&diff=3749
IP04
2008-07-28T19:27:22Z
<p>Kroux: /* Remove defunct public SIP demo account */</p>
<hr />
<div>= IP04 - Four Port IP-PBX =<br />
Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html<br />
= Assumptions = <br />
The IP04 can be configured with a combination of four FXO and/or FXS ports. This page describes how I started using one with 3 FXS (handset) and 1 FXO (linked to our corporate PABX). Assuming the IP04 is also linked on the local LAN.<br />
= Setup procedure =<br />
# Set IP address of your PC host ethernet interface temporarily to 192.168.1.99 (or anything you think think is available on 192.168.1.xx subnet, not 192.168.1.30).<br />
## myPC> ifconfig eth0 192.168.1.99/24<br />
# Check that the address 192.168.1.30 is not used<br />
## myPC> Ping 192.168.1.30 ... no replies. This is the factory default IP address of the IP04.<br />
# Unpack IPO4, plug into the LAN, telephone plug, and add 3 x telephone handsets<br />
## Check if IP04 work by dialing 6001, 6002, 6003 or 6004 on any one of the handsets<br />
# myPC> Telnet 192.168.1.30<br />
# Change network parameters to valid settings for your lan in /etc/rc.d/S10network-static<br />
## root~> vi /etc/rc.d/S10network-static<br />
## ... set the parameters and save<br />
## root~> reboot<br />
# Remember to set the IP address on your PC host back to the default for use on your lan<br />
== Try SIP to client ==<br />
# In SIP client (e.g. Ekiga), set SIP account with Registrar=IP address of IP04, user=sipguest, passwd=sipguest<br />
== Remove defunct public AIX demo account ==<br />
// * In /etc/asterisk/aix.conf, uncomment [demo] section:<br />
// ** #[demo]<br />
// ** ;type=peer <br />
// ** ;username=asterisk <br />
// ** ;secret=supersecret <br />
// ** ;host=216.207.245.47<br />
<br />
Comment out [trunk_2] section of /etc/asterisk/users.conf as iaxtel.com is not accepting connections.</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=IP04&diff=3747
IP04
2008-07-25T22:12:35Z
<p>Kroux: /* Remove defunct public SIP demo account */</p>
<hr />
<div>= IP04 - Four Port IP-PBX =<br />
Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html<br />
= Assumptions = <br />
The IP04 can be configured with a combination of four FXO and/or FXS ports. This page describes how I started using one with 3 FXS (handset) and 1 FXO (linked to our corporate PABX). Assuming the IP04 is also linked on the local LAN.<br />
= Setup procedure =<br />
# Set IP address of your PC host ethernet interface temporarily to 192.168.1.99 (or anything you think think is available on 192.168.1.xx subnet, not 192.168.1.30).<br />
## myPC> ifconfig eth0 192.168.1.99/24<br />
# Check that the address 192.168.1.30 is not used<br />
## myPC> Ping 192.168.1.30 ... no replies. This is the factory default IP address of the IP04.<br />
# Unpack IPO4, plug into the LAN, telephone plug, and add 3 x telephone handsets<br />
## Check if IP04 work by dialing 6001, 6002, 6003 or 6004 on any one of the handsets<br />
# myPC> Telnet 192.168.1.30<br />
# Change network parameters to valid settings for your lan in /etc/rc.d/S10network-static<br />
## root~> vi /etc/rc.d/S10network-static<br />
## ... set the parameters and save<br />
## root~> reboot<br />
# Remember to set the IP address on your PC host back to the default for use on your lan<br />
== Try SIP to client ==<br />
# In SIP client (e.g. Ekiga), set SIP account with Registrar=IP address of IP04, user=sipguest, passwd=sipguest<br />
== Remove defunct public SIP demo account ==<br />
* In /etc/asterisk/aix.conf, uncomment [demo] section:<br />
** #[demo]<br />
** ;type=peer <br />
** ;username=asterisk <br />
** ;secret=supersecret <br />
** ;host=216.207.245.47</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=IP04&diff=3746
IP04
2008-07-25T22:12:11Z
<p>Kroux: </p>
<hr />
<div>= IP04 - Four Port IP-PBX =<br />
Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html<br />
= Assumptions = <br />
The IP04 can be configured with a combination of four FXO and/or FXS ports. This page describes how I started using one with 3 FXS (handset) and 1 FXO (linked to our corporate PABX). Assuming the IP04 is also linked on the local LAN.<br />
= Setup procedure =<br />
# Set IP address of your PC host ethernet interface temporarily to 192.168.1.99 (or anything you think think is available on 192.168.1.xx subnet, not 192.168.1.30).<br />
## myPC> ifconfig eth0 192.168.1.99/24<br />
# Check that the address 192.168.1.30 is not used<br />
## myPC> Ping 192.168.1.30 ... no replies. This is the factory default IP address of the IP04.<br />
# Unpack IPO4, plug into the LAN, telephone plug, and add 3 x telephone handsets<br />
## Check if IP04 work by dialing 6001, 6002, 6003 or 6004 on any one of the handsets<br />
# myPC> Telnet 192.168.1.30<br />
# Change network parameters to valid settings for your lan in /etc/rc.d/S10network-static<br />
## root~> vi /etc/rc.d/S10network-static<br />
## ... set the parameters and save<br />
## root~> reboot<br />
# Remember to set the IP address on your PC host back to the default for use on your lan<br />
== Try SIP to client ==<br />
# In SIP client (e.g. Ekiga), set SIP account with Registrar=IP address of IP04, user=sipguest, passwd=sipguest<br />
== Remove defunct public SIP demo account ==<br />
# In /etc/asterisk/aix.conf, uncomment [demo] section:<br />
## #[demo]<br />
## ;type=peer <br />
## ;username=asterisk <br />
## ;secret=supersecret <br />
## ;host=216.207.245.47</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=IP04&diff=3745
IP04
2008-07-25T20:40:30Z
<p>Kroux: New page: = IP04 - Four Port IP-PBX = Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html = Assumptions = The IP04 can be configured with a combination...</p>
<hr />
<div>= IP04 - Four Port IP-PBX =<br />
Collaborating with David Rowe on deploying the IP04 - http://www.rowetel.com/ucasterisk/ip04.html<br />
= Assumptions = <br />
The IP04 can be configured with a combination of four FXO and/or FXS ports. This page describes how I started using one with 3 FXS (handset) and 1 FXO (linked to our corporate PABX). Assuming the IP04 is also linked on the local LAN.<br />
= Setup procedure =<br />
# Set IP address of your PC host ethernet interface temporarily to 192.168.1.99 (or anything you think think is available on 192.168.1.xx subnet, not 192.168.1.30).<br />
## myPC> ifconfig eth0 192.168.1.99/24<br />
# Check that the address 192.168.1.30 is not used<br />
## myPC> Ping 192.168.1.30 ... no replies. This is the factory default IP address of the IP04.<br />
# Unpack IPO4, plug into the LAN, telephone plug, and add 3 x telephone handsets<br />
## Check if IP04 work by dialing 6001, 6002, 6003 or 6004 on any one of the handsets<br />
# myPC> Telnet 192.168.1.30<br />
# Change network parameters to valid settings for your lan in /etc/rc.d/S10network-static<br />
## root~> vi /etc/rc.d/S10network-static<br />
## ... set the parameters and save<br />
## root~> reboot<br />
# Remember to set the IP address on your PC host back to the default for use on your lan<br />
== Try SIP to client ==<br />
# In SIP client (e.g. Ekiga), set SIP account with Registrar=IP address of IP04, user=sipguest, passwd=sipguest</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=User:Kroux&diff=3744
User:Kroux
2008-07-25T18:08:45Z
<p>Kroux: </p>
<hr />
<div>My profile can be found on http://linkedin.com/in/kobusroux<br />
<br />
Busy with researching large community wireless networks:<br />
Wireless Africa<br />
www.wireless-africa.org<br />
<br />
Playing with technology<br />
[[IP04]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=User:Kroux&diff=3743
User:Kroux
2008-07-25T18:08:14Z
<p>Kroux: </p>
<hr />
<div>My profile can be found on http://linkedin.com/in/kobusroux<br />
<br />
Busy with researching large community wireless networks:<br />
Wireless Africa<br />
www.wireless-africa.org<br />
<br />
Playing with technology<br />
[IP04]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=WISP-in-a-box_Way_Forward&diff=3732
WISP-in-a-box Way Forward
2008-07-23T21:38:55Z
<p>Kroux: </p>
<hr />
<div>This document remains very much a draft, but is the evolving specification for the WISP-in-a-box project.<br />
<br />
=== Overview ===<br />
<br />
[[Image:Grafic_(Modified).png|thumb|400px]]<br />
<br />
[[Image:Grafic-telco_(Modified).png|thumb|400px|Icon sources: http://villagetelco.org/, http://www.ubnt.com/products/ns2.php]]<br />
<br />
The entire WISP-in-a-box system consists of:<br />
<br />
* A central dashboard, running on the gateway server, from which: <br />
** the network can be monitored and all nodes can be configured <br />
** prepaid vouchers can be administered <br />
** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered <br />
** all functionality will work without upstream Internet access<br />
* Mesh nodes which: <br />
** receive configuration updates from the central dashboard <br />
** run a captive portal that interacts with clients and authenticates against the gateway server <br />
** run intra-mesh QoS software <br />
** route themselves intelligently using BATMAN <br />
<br />
=== Component Diagram ===<br />
<br />
The basic setup looks like the digram to the right. For the Village Telco project, many components are the same. There is some additional functionality that's desired, however, that can reside on top of the base WISP-in-a-box system.<br />
<br />
This document is going to mainly focus on specifying the needs of the mesh & networking side of things, with an eye towards exactly how voice-related services will be integrated (but not an elaborate discussion of the technologies themselves).<br />
<br />
=== Dashboard & Server ===<br />
==== Existing Dashboard Projects ====<br />
The OrangeMesh and Open-Mesh dashboards provide almost exactly the functionality we require. However, they have a number of problems: <br />
<br />
* Both dashboards require the nodes to be running ROBIN firmware to receive configuration updates. ROBIN, as it is now, only runs on Atheros-based devices, not Broadcom devices (like the Linksys WRT). Some semi-serious hacking will be required to add support for Broadcom devices into ROBIN, since right now it assumes the use of the Atheros-only MadWifi drivers.<br />
* With an eye towards localization & modularity, the OrangeMesh sources aren't quite what we'd like them to be.<br />
<br />
Because of these limitations, we may not want to use the OrangeMesh/Open-Mesh dashboard. We still want to imitate the same basic style of system, however, while adding some functionality to meet the additional needs of our dashboard (e.g. ability to administer vouchers and server services, things that the OrangeMesh/Open-Mesh dashboards don't cover).<br />
<br />
==== Our Approach ====<br />
We will start essentially from scratch on the dashboard, with the OrangeMesh dashboard as an example to work off of and borrow heavily from.<br />
<br />
The dashboard we will design will be highly modular, with a high-level menu in which the user can select a module to work with. A module might be an existing software component or a new one we've written. In the case of Network Status and Network Configuration, we can use the Orangemesh-Openmesh/ROBIN setup as a reference, and where appropriate can adapt their code to suit our needs. Other tools to borrow from include Zeroshell for network QoS configuration. Essential modules include:<br />
<br />
* Server Administration -- brings up Webmin<br />
** 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.<br />
* Vouchers -- brings up phpMyPrepaid, our data billing control system<br />
** 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<br />
** 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.<br />
* Network Status -- new custom dashboard component with following features:<br />
** A semi-detailed list of all the nodes in the mesh, including: <br />
*** the node's IP and MAC addresses <br />
*** the node's current status (simple up or down) <br />
*** when they were last heard from (when an update from that node was last received)<br />
*** how many hops and/or what route the node currently has to the gateway<br />
** Basic network usage statistics, data taken from RADIUS:<br />
*** Total bandwidth going out of the gateway in the last X amount of time<br />
*** Heaviest users of the network to monitor abuse (further information on individual users is available already in phpMyPrepaid)<br />
** Ability to test network throughput, either through:<br />
*** Simple interface to run iperf between any two nodes, or:<br />
*** Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools<br />
<br />
* Mesh Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):<br />
** Change SSID of mesh network<br />
** Change channel of mesh network<br />
** Other features? Open to discussion.<br />
* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:<br />
** On the server, for outgoing traffic going to the upstream connection<br />
** On the various nodes in the mesh, for intra-mesh network bandwidth management.<br />
* AP-only node configuration – new custom dashboard component that configures node that are only AP's, not part of the mesh. Configures:<br />
** SSID of AP<br />
** Channel of AP<br />
** Any kind of WPA authentication a user might want to run on the AP<br />
<br />
Possible other voice-related modules include Asterisk and A2billing modules or pages.<br />
<br />
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. <br />
<br />
All of the components of the larger dashboard will be skinned in a unified CSS style, with the potential for branding built in.<br />
<br />
=== Mesh Nodes ===<br />
The mesh nodes themselves will run OpenWRT. Node software includes:<br />
<br />
* Batman for routing<br />
* CoovaChilli as a local captive portal<br />
* Intra-mesh QoS software, configurable from the dashboard. Uncertain as to what tools exactly to use here, however borrowing from Zeroshell it may be possible to simply use netfilter/iptables & l7-filter. Using an existing tool here would be very nice, as this is a complex task.<br />
* A client daemon modeled on the ROBIN scripts that receives updates from the dashboard and sends any necessary information back to the dashboard. The client daemon will have to be co-developed with the dashboard.<br />
* Stripped-down Webmin server component so we can run remote Webmin commands on the node through the server's Webmin installation.<br />
* In addition to configuration through the dashboard, we will include a minimal web interface for configuring each individual node. This interface will run on the nodes, and can be a stripped-down version of X-WRT's webif^2 or FFLuCI. It would be useful if the interface could be designed such that it would run on any device regardless of that device's platform. This may be easy to do with existing abstractions in OpenWRT, but an alternative method would be for this interface to change the configuration of the local node via the update API, which is guaranteed to be fully abstracted, and let the update client for that device take care of making the actual changes.<br />
<br />
=== AP-only Nodes ===<br />
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:<br />
<br />
* CoovaChilli<br />
* Dashboard Client with:<br />
** AP-only node configuration module<br />
** CoovaChilli configuration module<br />
<br />
=== Task Breakdown ===<br />
Once the specification is agreed upon work can begin. At that time further task breakdowns may be useful, but at a high level the expectation currently is as follows (refer to above for details on what individual software piece entail):<br />
<br />
# Dashboard & first client development: Meraka<br />
## Further examination of ROBIN to see which parts of it can be modified for our purposes<br />
## Adaptation of Webmin's cluster tools for use on the mesh<br />
## Determine appropriate tools for QoS [starting point: Zeroshell]<br />
## Update API design & specification<br />
## Dashboard framework design and implementation<br />
## Mesh update client framework design and implementation<br />
## Dashboard module implementation<br />
### Network Monitoring<br />
### Network Configuration – basics (Channel, SSID, etc)<br />
### Network Configuration – QoS settings<br />
### Network Configuration – AP-only settings<br />
### Adapt phpMyPrepaid's CoovaChilli configuration to send out updates via standardized API rather than only changing local configuration file.<br />
## 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).<br />
## CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).<br />
<br />
# Minimal interface development for starter devices (at least the WRT, Mesh Potato, and Ubiquity nodes): Inveneo<br />
# Porting of mesh client to Ubiquity and Mesh Potato (most modules should be identical, but basic network configuration settings may be device-specific): Inveneo<br />
<br />
[[Category:WISP in a box]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=WISP-in-a-box_Way_Forward&diff=3723
WISP-in-a-box Way Forward
2008-07-23T09:29:21Z
<p>Kroux: </p>
<hr />
<div>This document remains very much a draft, but is the evolving specification for the WISP-in-a-box project.<br />
<br />
=== Overview ===<br />
<br />
[[Image:Grafic_(Modified).png|thumb|400px]]<br />
<br />
[[Image:Grafic-telco_(Modified).png|thumb|400px]]<br />
<br />
The entire WISP-in-a-box system consists of: <br />
<br />
* A central dashboard, running on the gateway server, from which: <br />
** the network can be monitored and all nodes can be configured <br />
** prepaid vouchers can be administered <br />
** software running on the server (web & mail services, upstream connection QoS software, etc) can be administered <br />
** all functionality will work without upstream Internet access<br />
* Mesh nodes which: <br />
** receive configuration updates from the central dashboard <br />
** run a captive portal that interacts with clients and authenticates against the gateway server<br />
** run intra-mesh QoS software<br />
** route themselves intelligently using BATMAN<br />
<br />
=== Component Diagram ===<br />
<br />
The basic setup looks like the digram to the right. For the Village Telco project, many components are the same. There is some additional functionality that's desired, however, that can reside on top of the base WISP-in-a-box system.<br />
<br />
This document is going to mainly focus on specifying the needs of the mesh & networking side of things, with an eye towards exactly how voice-related services will be integrated (but not an elaborate discussion of the technologies themselves).<br />
<br />
=== Dashboard & Server ===<br />
==== Existing Dashboard Projects ====<br />
The OrangeMesh and Open-Mesh dashboards provide almost exactly the functionality we require. However, they have a number of problems: <br />
<br />
* Both dashboards require the nodes to be running ROBIN firmware to receive configuration updates. ROBIN, as it is now, only runs on Atheros-based devices, not Broadcom devices (like the Linksys WRT). Some semi-serious hacking will be required to add support for Broadcom devices into ROBIN, since right now it assumes the use of the Atheros-only MadWifi drivers.<br />
* With an eye towards localization & modularity, the OrangeMesh sources aren't quite what we'd like them to be.<br />
<br />
Because of these limitations, we may not want to use the OrangeMesh/Open-Mesh dashboard. We still want to imitate the same basic style of system, however, while adding some functionality to meet the additional needs of our dashboard (e.g. ability to administer vouchers and server services, things that the OrangeMesh/Open-Mesh dashboards don't cover).<br />
<br />
==== Our Approach ====<br />
We will start essentially from scratch on the dashboard, with the OrangeMesh dashboard as an example to work off of and borrow heavily from.<br />
<br />
The dashboard we will design will be highly modular, with a high-level menu in which the user can select a module to work with. A module might be an existing software component or a new one we've written. In the case of Network Status and Network Configuration, we can use the Orangemesh-Openmesh/ROBIN setup as a reference, and where appropriate can adapt their code to suit our needs. Other tools to borrow from include Zeroshell for network QoS configuration. Essential modules include:<br />
<br />
* Server Administration -- brings up Webmin<br />
** 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.<br />
* Vouchers -- brings up phpMyPrepaid, our data billing control system<br />
** 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<br />
** 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.<br />
* Network Status -- new custom dashboard component with following features:<br />
** A semi-detailed list of all the nodes in the mesh, including: <br />
*** the node's IP and MAC addresses <br />
*** the node's current status (simple up or down) <br />
*** when they were last heard from (when an update from that node was last received)<br />
*** how many hops and/or what route the node currently has to the gateway<br />
** Basic network usage statistics, data taken from RADIUS:<br />
*** Total bandwidth going out of the gateway in the last X amount of time<br />
*** Heaviest users of the network to monitor abuse (further information on individual users is available already in phpMyPrepaid)<br />
** Ability to test network throughput, either through:<br />
*** Simple interface to run iperf between any two nodes, or:<br />
*** Visual display of metrics & signal strengths of every link, data reported from clients' BATMAN daemons and network tools<br />
<br />
* Backbone Network Configuration -- new custom dashboard component with following features (note this is designed to be minimal for ease of use):<br />
** Change SSID of mesh backhaul<br />
** Change channel of mesh backhaul<br />
** Other features? Open to discussion.<br />
* QoS Network Configuration – new custom dashboard component for adjusting QoS settings both:<br />
** On the server, for outgoing traffic going to the upstream connection<br />
** On the various nodes in the mesh, for intra-mesh network bandwidth management.<br />
* AP-only node configuration – new custom dashboard component that configures node that are only AP's, not part of the mesh. Configures:<br />
** SSID of AP<br />
** Channel of AP<br />
** Any kind of WPA authentication a user might want to run on the AP<br />
<br />
Possible other voice-related modules include Asterisk and A2billing pages.<br />
<br />
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. <br />
<br />
All of the components of the larger dashboard will be skinned in a unified CSS style, with the potential for branding built in.<br />
<br />
=== Mesh Nodes ===<br />
The mesh nodes themselves will run OpenWRT. Node software includes:<br />
<br />
* Batman for routing<br />
* CoovaChilli as a local captive portal<br />
* Intra-mesh QoS software, configurable from the dashboard. Uncertain as to what tools exactly to use here, however borrowing from Zeroshell it may be possible to simply use netfilter/iptables & l7-filter. Using an existing tool here would be very nice, as this is a complex task.<br />
* A client daemon modeled on the ROBIN scripts that receives updates from the dashboard and sends any necessary information back to the dashboard. The client daemon will have to be co-developed with the dashboard.<br />
* Stripped-down Webmin server component so we can run remote Webmin commands on the node through the server's Webmin installation.<br />
* In addition to configuration through the dashboard, we will include a minimal web interface for configuring each individual node. This interface will run on the nodes, and can be a stripped-down version of X-WRT's webif^2 or FFLuCI. It would be useful if the interface could be designed such that it would run on any device regardless of that device's platform. This may be easy to do with existing abstractions in OpenWRT, but an alternative method would be for this interface to change the configuration of the local node via the update API, which is guaranteed to be fully abstracted, and let the update client for that device take care of making the actual changes.<br />
<br />
=== AP-only Nodes ===<br />
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.<br />
<br />
* 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).<br />
* 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.<br />
<br />
=== Task Breakdown ===<br />
Once the specification is agreed upon work can begin. At that time further task breakdowns may be useful, but at a high level the expectation currently is as follows (refer to above for details on what individual software piece entail):<br />
<br />
# Dashboard & first client development: Meraka<br />
## Further examination of ROBIN to see which parts of it can be modified for our purposes<br />
## Adaptation of Webmin's cluster tools for use on the mesh<br />
## Update API design & specification<br />
## Dashboard framework design and implementation<br />
## Mesh update client framework design and implementation<br />
## Dashboard module implementation<br />
### Network Monitoring<br />
### Network Configuration – basics (Channel, SSID, etc)<br />
### Network Configuration – QoS settings<br />
### Network Configuration – AP-only settings<br />
### Adapt phpMyPrepaid's CoovaChilli configuration to send out updates via standardized API rather than only changing local configuration file.<br />
## 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).<br />
## CSS skinning for all dashboard components (including pre-existing ones such as Webmin and phpMyPrepaid).<br />
<br />
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.<br />
<br />
# Minimal interface development for starter devices (at least the WRT, Mesh Potato, and Ubiquity nodes): Inveneo<br />
# Porting of mesh client to Ubiquity and Mesh Potato (most modules should be identical, but basic network configuration settings may be device-specific): Inveneo<br />
<br />
[[Category:WISP in a box]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=User:Kroux&diff=3503
User:Kroux
2008-06-28T10:30:56Z
<p>Kroux: New page: My profile can be found on http://linkedin.com/in/kobusroux I'm currently working on a proposal for a national broadband for all initiative. Presentation:</p>
<hr />
<div>My profile can be found on http://linkedin.com/in/kobusroux<br />
<br />
I'm currently working on a proposal for a national broadband for all initiative. Presentation:</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=WISPiab_specifications&diff=3020
WISPiab specifications
2008-04-20T19:23:36Z
<p>Kroux: /* Minimum requirements */</p>
<hr />
<div>[[Category: WISP in a box]]<br />
<br />
=Introduction=<br />
<br />
<br />
The following is our work copy of a specification / feature wish list for the WISP-in-a-box product.<br />
<br />
It is meant to be commented and refined.<br />
<br />
<br />
=Business Models / Use cases=<br />
<br />
It is essential that the specifications be based on business model needs and real life use cases.<br />
<br />
<br />
While these need to be refined and studied further (e.g. in the Wireless Africa II project),<br />
we list some main examples and key words here.<br />
<br />
==Basic access models: Centralized and Mesh==<br />
<br />
'''The entrepreneur wants to offer both centralized (aka infrastructure, hot spot, access point) and mesh models'''<br />
<br />
==> We need to implement both Access Point Management and Mesh protocols<br />
<br />
<br />
===Networks models in detail===<br />
<br />
In particular, we need to take into account the following 3 network models, and the hybrid models between them.<br />
<br />
In the following pictures, <br />
<br />
* red stands for business / entrepreneur owned and operated nodes, <br />
* blue stands for clients / users. <br />
<br />
The line between the two may be transparent.<br />
<br />
<br />
====Centralized model====<br />
<br />
[[Image:WISPiab models 1 centralized.png|thumb|left|Centralized model]]<br />
<br />
* The business/entrepreneur acts as a central access point.<br />
* The central business/entrepreneur node supplies an internet uplink (optional).<br />
* Clients connect to this central point, e.g. with PCs, laptops, client nodes or VoIP phones.<br />
<br />
====Inframesh model====<br />
<br />
[[Image:WISPiab models 2 inframesh with clients.png|thumb|left|Inframesh model]]<br />
<br />
* The business/entrepreneur operates an infrastructure mesh.<br />
* The business/entrepreneur node supplies internet uplink(s) at one or more of these nodes (optional).<br />
* Clients connect one or more of these nodes, as clients, e.g. with PCs, laptops, client nodes or VoIP phones.<br />
<br />
====Full mesh model====<br />
<br />
[[Image:WISPiab models 3 fullmesh.png|thumb|left|Full mesh model]]<br />
<br />
* The business/entrepreneur operates one or many mesh nodes.<br />
* The business/entrepreneur node supplies internet uplink(s) at one or more of these nodes (optional).<br />
* Clients fully particpate in that mesh, typically on dedicated node hardware, less likely with PC/laptop, and even less with VoIP phones. Clients may supply internet uplinks (optional).<br />
<br />
Especially in this model, the line between business and client operated nodes might become transparent.<br />
<br />
<br />
<br />
==Network Management==<br />
<br />
<br />
'''The entrepreneur needs to be able to monitor, manage, troubleshoot the network'''<br />
<br />
==> We need network management SW plus interfaces, e.g. Nagios, Cactus, Webmin, ...<br />
<br />
==Voice Services==<br />
<br />
'''The entrepreneur wants to offerVoice services'''<br />
<br />
==> We need to implement Asterisk, OpenSER or similar, plus additional management tools for these, if idnetified as needed<br />
<br />
==Billing==<br />
<br />
'''The entrepreneur wants to offer a variety of billing options, e.g. monthly subscription, time/voucher (airtime) based, free access'''<br />
<br />
==> We need to implement billing and accomodate the various models on the box, in parallel (e.g. parallel free and closed segments, etc)<br />
<br />
<br />
=High level architecture=<br />
<br />
Our currently suggested architecture splits the WISPiab hardware package into two components plus an option:<br />
<br />
#Front Access Node<br />
##<br />
# Back end server (with or without screen, depending on existing ...)<br />
##<br />
#(Sub)Laptop as GUI admin (optional)<br />
<br />
<br />
This seems appropriate based on the analysis of the SW specs in detail.<br />
<br />
However, if test implementations seem to suggest reuniting the two tiers on one box, this is an open option, which might bring manageability benefits.<br />
<br />
<br />
[[Image:WISPiab elements horizontal with net small.png|thumb|left]]<br />
<br />
=Software Specification / Feature list for the WISP-in-a-box product=<br />
<br />
<br />
<br />
==Shared functionality==<br />
<br />
* All configuration etc to be accessible via browser based GUI<br />
* ssh access<br />
<br />
<br />
* Routing Protocols<br />
** OLSR<br />
** b.a.t.m.a.n.<br />
<br />
<br />
<br />
<br />
==Front access node==<br />
<br />
* CoovaAP<br />
** Authentication potentially with 2 options<br />
*** Against itself / on acces node<br />
*** Against back end server Radius<br />
<br />
CoovaAP will bring most of the following mandatory features for the front access node.<br />
<br />
<br />
* OpenSER<br />
<br />
==Back end server==<br />
<br />
<br />
* apache<br />
* php<br />
* mediawiki<br />
* mysql<br />
<br />
* ispconfig<br />
** webmin?<br />
<br />
* DNS server (DDNS, DynDNS)<br />
<br />
* Proxy / Cache <br />
** Squid<br />
<br />
===Mail===<br />
<br />
* Postfix / Courier<br />
* Webmail: squirrelmail<br />
* gmail syncing desirable<br />
* Google server local? (--> talk to gmail, Kobus)<br />
<br />
* Spam/Virus control<br />
** amavis<br />
** spamassassin<br />
<br />
<br />
===Network management===<br />
<br />
* Nagios<br />
* Cacti<br />
<br />
<br />
* Statistics<br />
** awstats or similar<br />
<br />
<br />
===Auth, Access, Security, Billing===<br />
<br />
* Radius<br />
**FreeRadius<br />
* OpenLDAP<br />
* OpenID<br />
<br />
* OpenVPN<br />
* GnuPG<br />
<br />
<br />
===QoS===<br />
<br />
* QoS - details of this not clear yet - what layer? what tools?<br />
** iproute2<br />
** MasterShaper?<br />
** Wondershaper<br />
<br />
<br />
<br />
===Storage, FS===<br />
<br />
<br />
* NAS – iSCSI<br />
<br />
* File servers<br />
** SMB<br />
** NFS<br />
** rsyncing cron'd<br />
<br />
* Redundancy - to be psecified in more detail<br />
** Would liek to build distributed storage - “graded distributed system” <br />
<br />
<br />
<br />
<br />
===Voice over IP===<br />
<br />
* Asterisk<br />
* OpenSER<br />
* billing integration<br />
** a2billing<br />
<br />
<br />
===Miscellaneous===<br />
<br />
* Local Library of SW<br />
** Documentation<br />
** Integrated Skilling / Education<br />
* patch management<br />
* IpCOP<br />
* wikipedia local copy<br />
<br />
* Content filtering ? - discussion!<br />
<br />
* Virtualization (XenSource)<br />
** to be discussed - not deemed mandatory<br />
<br />
=Hardware Specification / Feature list for the WISP-in-a-box product=<br />
<br />
<br />
To be spec'ed after completion of SW specs.<br />
<br />
<br />
<br />
==Minimum requirements==<br />
<br />
<br />
===General requirements for all elements===<br />
<br />
* Input: 12 V_dc<br />
* Fanless<br />
* Low power (< 8 W)<br />
<br />
===Front access node===<br />
<br />
Network interfaces<br />
2 minimum, maybe more<br />
<br />
<br />
===Back end server===<br />
external switch<br />
<br />
==Hardware candidates==<br />
<br />
<br />
{| rules="rows" frame="hsides" align="left" width="100%" cellpadding=10<br />
|- align="left" valign="top"<br />
!'''Table 1''': Table title<br />
|- bgcolor="lightgrey" align="left" valign="top"<br />
! Name !! candidate for !! CPU Memory Storage !! Power !! Wireless !! Cost !! Comments<br />
<br />
<br />
<br />
|- align="left" valign="top"<br />
| ASUS EEE PC || server? ||<br />
ASUS® EEE PC 700-W - Intel® 900Mhz Pentium®M ULV, 512MB DDR2 Memory, Internal 2GB SSD Based Hard Drive, Intel® 910GML Chipset, 7" 800x480 LCD, 10/100 LAN, WiFi b/g, SD Card Slot, 3xUSB 2.0 / ASUS EEE PC 4g with 4 GB SSD / ASUS EEE 900 with 1 GB RAM, 12 GB SSD<br />
|| power: ? ||- || ? || comments<br />
<br />
|- align="left" valign="top"<br />
| dataevolution.com decTOP etc || server? ||<br />
Memory<br />
128MB SDRAM<br />
10GB HDD <br />
|| power: ? ||- || ? || comments<br />
<br />
<br />
|- align="left" valign="top"<br />
| FON(ERA) || access node ||<br />
CPU: MIPS 180 MHz <br />
Memory: 16 MB ram <br />
|| power || wireless || EUR 40 || comments<br />
<br />
<br />
<br />
|- align="left" valign="top"<br />
| Inveneo Outdoor WiFi Access Point|| access node, server (?) || ??? ask Inveneo || power || 802.11 b/g<br />
Athenos chipset<br />
Peak power: +24dBm (250mW) || Single Radio: $469 USD* Dual Radio: $659 USD* || incl antennas, install kits, outdoor ready<br />
<br />
|- align="left" valign="top"<br />
| Inveneo Hub server|| server || <br />
1.2GHz VIA C7 nanoBGA2 Fanless<br />
VIA CN700 North Bridge<br />
VIA VT8237RP High-bandwidth Vlink Client South Bridge<br />
51MB standard, 1GB optional<br />
One RS-232C serial port (DB-9)<br />
Four USB 2.0 ports (two in front, two in back)<br />
|| < 20 W || -|| Price: starting at $$785 USD* || incl many things, see site :)<br />
<br />
|- align="left" valign="top"<br />
| Linksys WRT54G(L) || access node || cpu memory storage etc || power || wireless || USD 45 || comments<br />
<br />
<br />
<br />
|- align="left" valign="top"<br />
| Meraki outdoor || access node || <br />
Bootloader: RedBoot<br />
CPU: Atheros AR2315<br />
CPU Speed: 180 Mhz<br />
Flash size: 8 MB<br />
RAM: 32 MB <br />
|| Power consumption: 12W max; 3W typical || <br />
* 200 mW (23dBm) peak transmission power*<br />
* Enhanced receive sensitivity<br />
* External RP-SMA connector<br />
* 802.11 b/g (1-54 Mbps)<br />
* 2dBi omni directional antenna included<br />
|| USD 49/99 || note EULA issues!<br />
<br />
http://www.mini-itx.com/<br />
<br />
|- align="left" valign="top"<br />
| Mini-ITX / VIA / LEX / Jetway etc || access node, server || varies || power || wireless || cost || see [http://www.mini-itx.com/ http://www.mini-itx.com/] [http://www.via.com.tw/en/products/mainboards/ http://www.via.com.tw/en/products/mainboards/]<br />
<br />
<br />
|- align="left" valign="top"<br />
| Soekris boards || access node, server (?) || cpu memory storage etc || power || wireless || cost || comments<br />
<br />
<br />
<br />
|- align="left" valign="top"<br />
| Ultra Mobile PCs / sub laptops || becoming a valid candidate as ''Backend/server'' component? || <br />
many candidates with differing specs, need to check out and test:<br />
<br />
* OLPC<br />
* eMate 300<br />
* Classmate PC<br />
* Linutop, Geode LX -based computer<br />
* Longmeng or Dragon Dream, China<br />
* Tianhua GX-1C, Sinomanic in China<br />
* VIA pc-1 Initiative, VIA Technologies digital divide program.<br />
* Zonbu, a low-cost desktop computer<br />
* Eee PC, ASUS and Intel - watch!<br />
* Clio NXT.<br />
* InkMedia MC, another low-cost subnotebook<br />
* Elonex_ONE, subnotebook, expected to be £99<br />
<br />
<br />
|| ??? - typically low, 3 Watts for OLPC-X01 || typically built in <br />
<br />
|| <br />
<br />
EUR 250 - 400 <br />
<br />
* OLPC<br />
* eMate 300<br />
* Classmate PC<br />
* Linutop, Geode LX -based computer EUR 280<br />
* Longmeng or Dragon Dream, China<br />
* Tianhua GX-1C, Sinomanic in China<br />
* VIA pc-1 Initiative, VIA Technologies digital divide program.<br />
* Zonbu, a low-cost desktop computer<br />
* Eee PC, model900 = EUR 400, model 4g = EUR 300<br />
* Acer, Q2 2008, approx EUR 250 ?<br />
* Clio NXT.<br />
* InkMedia MC, another low-cost subnotebook<br />
* Elonex_ONE, subnotebook, expected to be £99<br />
<br />
<br />
|| needs testing and verification as candidates<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
|- align="left" valign="top"<br />
| WRAP boards || access node, server (?) || cpu memory storage etc || power || wireless || cost || comments<br />
<br />
|}<br />
<br />
----<br />
<br />
==Solar part==<br />
<br />
Solar Kit to be spe'ed after HW power is known</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Contact&diff=2938
Contact
2008-03-24T12:36:39Z
<p>Kroux: </p>
<hr />
<div>Email: wa-admin@meraka.org.za<br />
<br />
Tel.: +27 12 841 3028</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Charles_Perkins_visit&diff=2336
Charles Perkins visit
2006-10-03T10:04:50Z
<p>Kroux: </p>
<hr />
<div>==Colloquium: Research in mesh networks and other ad-hoc networks - Charles Perkins==<br />
<br />
Charles Perkins, “the father of mobile IP technology” and Nokia Fellow, visited the Meraka Institute on the 11th of September to present on research in mesh networking and other ad-hoc networks. The aim of the presentation was to:<br />
# To present recent areas of research on ad hoc wireless networks.<br />
# Generate interest in Wireless Africa's access and mesh networking research <br />
<br />
About 40 persons from the telecommunications industry and around 10 people from academia attended the conference. One person even drove all the way from Eastern Cape just to attend the presentation. His presentation is an excellent summary of current research issues in ad-hoc and mesh networking protocols. Interesting linkages with social networking were also highlighted.<br />
<br />
The presentation is available here<br />
[[Media:perkins.pdf|Research in mesh networks and other ad-hoc networks - Charles Perkins]]<br />
<br />
<br />
----<br />
<br />
<br />
<br />
'''Brief CV: Charles Perkins'''<br />
<br />
Charles E. Perkins is a Nokia Fellow in the Network Technology Laboratory at Nokia Research<br />
Center, investigating mobile wireless networking and dynamic configuration protocols. Prior to<br />
this he worked at Sun Microsystems and IBM.<br />
He serves as document editor for the mobile-IP working group of the Internet Engineering Task<br />
Force (IETF), and is author or co-author of standards-track documents in the mip4, mip6,<br />
manet, dhc, mipshop, seamoby (Seamless Mobility) and autoconf working groups. Charles has<br />
served as program committee co-chair for MobiHoc 2004, on the Internet Architecture Board<br />
(IAB) of the IETF and on various committees for the National Research Council.<br />
More recently he has served as Program Chair for the IEEE Vehicular Technology conference<br />
networking track. He currently serves as General Chair for IEEE Mobile Ad hoc and Sensor<br />
Systems conference (MASS 2006). He is also associate editor for Mobile Communications and<br />
Computing Review, the official publication of ACM SIGMOBILE, and has served on the editorial<br />
staff for IEEE Internet Computing magazine.<br />
Charles has authored and edited books on Mobile IP and Ad Hoc Networking. He has published<br />
a number of papers and award winning articles in the areas of mobile networking, ad-hoc<br />
networking, route optimization for mobile networking, resource discovery, and automatic<br />
configuration for mobile computers.<br />
Charles holds a B.A. in mathematics and a M.E.E. degree from Rice University, and a M.A. in<br />
Mathematics from Columbia University, has nine patents and five pending patent applications.<br />
He won several IBM Invention Achievement Awards and a Service Award for contributions to the<br />
Internet Architectural Board.<br />
More information: http://research.nokia.com/people/charles_perkins/index.html</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=WirelessAfrica:Community_Portal&diff=1584
WirelessAfrica:Community Portal
2005-11-20T22:02:14Z
<p>Kroux: </p>
<hr />
<div>=Meraka COIN Team Members=<br />
Kobus roux a.k.a [[User:Kroux]]<br />
<br />
David Johnson a.k.a [[User:Kingdavid]]<br />
<br />
Yusuf Kaka a.k.a [[User:Yusufk]]<br />
<br />
John Hay a.k.a [[User:Jhay]]<br />
<br />
Johann Hugo a.k.a [[User:]]<br />
<br />
Madelein Van Den Berg a.k.a [[User:]]<br />
<br />
Anita Van De Merwe a.k.a [[User:]]<br />
<br />
Lawrence Mboweni a.k.a [User:]]<br />
<br />
=Honourary Members ;)=<br />
Andrew, the Android Smith [[User:]]<br />
<br />
=Contributors=</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Community_Media_%26_Technology_Conference&diff=1581
Community Media & Technology Conference
2005-11-20T18:33:14Z
<p>Kroux: </p>
<hr />
<div>Open Society Foundation for SA <br />
<br />
Workshop - Community Media & Technology <br />
<br />
November 21-22, 2005 <br />
<br />
<br />
PROGRAMME<br />
<br />
Monday Nov 21<br />
<br />
8.00 – 8.45am Registration<br />
<br />
8.45 – 9.00am Welcome<br />
<br />
09.00 -10.00am Setting the context of telecommunications in South Africa. <br />
CONSOLE TLEANE, Freedom of Expression Institute<br />
<br />
10.00 - 10.30am A view from Government<br />
ZOLISILE MSHUNQANA, Department of Communications<br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00 – 12.00 noon Introduction to Open Source Software <br />
NHLANHLA MABASO, CSIR<br />
<br />
12.00- 12.30pm Introduction to TUCS labs<br />
HILTON THEUNISSEN, Shuttleworth Foundation<br />
<br />
12.30 - 1.30pm LUNCH<br />
<br />
1.30 - 2.30pm Connectivity Options<br />
KOBUS ROUX & SHERRIN ISAAC, Meraka Institute, CSIR<br />
<br />
2.30 - 3.30pm Introduction to Live Support – what it offers <br />
DOUG ARELLANES, Media Development Loan Fund<br />
<br />
3.30 - 4pm TEA<br />
<br />
4-5.30pm Learning the basics about loading software & using it<br />
Hands-On session<br />
<br />
<br />
<br />
Tuesday November 22<br />
<br />
8.30 – 9.30am MPCCs and Community Radio – opportunities & partnerships KAREN THORNE, AMAC<br />
<br />
9.30 – 10.30am Data bases and IT tools for newsrooms and marketing <br />
JUSTIN ARENSTEIN, Africa Eye News Service <br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00-11.30am State-funded support<br />
SAM GULUBE, Universal Service Agency <br />
<br />
11.30 - 12.30pm Conclusion & Way Forward<br />
ASHRAF PATEL, Open Society Institute of Southern Africa<br />
<br />
12.30 – 1.30pm LUNCH<br />
<br />
1.30pm-2.30pm More hands-on practice – using databases and Open Source Software [Optional]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Community_Media_%26_Technology_Conference&diff=1580
Community Media & Technology Conference
2005-11-20T18:32:38Z
<p>Kroux: </p>
<hr />
<div>Open Society Foundation for SA <br />
<br />
Workshop - Community Media & Technology <br />
<br />
November 21-22, 2005 <br />
<br />
<br />
PROGRAMME<br />
<br />
Monday Nov 21<br />
<br />
8.00 – 8.45am Registration<br />
<br />
8.45 – 9.00am Welcome<br />
<br />
09.00 -10.00am Setting the context of telecommunications in South Africa. <br />
<br />
CONSOLE TLEANE, Freedom of Expression Institute<br />
<br />
10.00 - 10.30am A view from Government<br />
ZOLISILE MSHUNQANA, Department of Communications<br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00 – 12.00 noon Introduction to Open Source Software <br />
NHLANHLA MABASO, CSIR<br />
<br />
12.00- 12.30pm Introduction to TUCS labs<br />
HILTON THEUNISSEN, Shuttleworth Foundation<br />
<br />
12.30 - 1.30pm LUNCH<br />
<br />
1.30 - 2.30pm Connectivity Options<br />
KOBUS ROUX & SHERRIN ISAAC, Meraka Institute, CSIR<br />
<br />
2.30 - 3.30pm Introduction to Live Support – what it offers <br />
DOUG ARELLANES, Media Development Loan Fund<br />
<br />
3.30 - 4pm TEA<br />
<br />
<br />
4-5.30pm Learning the basics about loading software & using it<br />
Hands-On session<br />
<br />
<br />
<br />
Tuesday November 22<br />
<br />
8.30 – 9.30am MPCCs and Community Radio – opportunities & partnerships KAREN THORNE, AMAC<br />
<br />
9.30 – 10.30am Data bases and IT tools for newsrooms and marketing <br />
JUSTIN ARENSTEIN, Africa Eye News Service <br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00-11.30am State-funded support<br />
SAM GULUBE, Universal Service Agency <br />
<br />
11.30 - 12.30pm Conclusion & Way Forward<br />
ASHRAF PATEL, Open Society Institute of Southern Africa<br />
<br />
12.30 – 1.30pm LUNCH<br />
<br />
1.30pm-2.30pm More hands-on practice – using databases and Open Source Software [Optional]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Community_Media_%26_Technology_Conference&diff=1579
Community Media & Technology Conference
2005-11-20T18:31:53Z
<p>Kroux: </p>
<hr />
<div>Open Society Foundation for SA <br />
Workshop - Community Media & Technology <br />
November 21-22, 2005 <br />
<br />
PROGRAMME<br />
<br />
Monday Nov 21<br />
<br />
8.00 – 8.45am Registration<br />
8.45 – 9.00am Welcome<br />
09.00 -10.00am Setting the context of telecommunications in South Africa. <br />
CONSOLE TLEANE, Freedom of Expression Institute<br />
<br />
10.00 - 10.30am A view from Government<br />
ZOLISILE MSHUNQANA, Department of Communications<br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00 – 12.00 noon Introduction to Open Source Software <br />
NHLANHLA MABASO, CSIR<br />
<br />
12.00- 12.30pm Introduction to TUCS labs<br />
HILTON THEUNISSEN, Shuttleworth Foundation<br />
<br />
12.30 - 1.30pm LUNCH<br />
<br />
1.30 - 2.30pm Connectivity Options<br />
KOBUS ROUX & SHERRIN ISAAC, Meraka Institute, CSIR<br />
<br />
2.30 - 3.30pm Introduction to Live Support – what it offers <br />
DOUG ARELLANES, Media Development Loan Fund<br />
<br />
3.30 - 4pm TEA<br />
<br />
<br />
4-5.30pm Learning the basics about loading software & using it<br />
Hands-On session<br />
<br />
<br />
<br />
Tuesday November 22<br />
<br />
8.30 – 9.30am MPCCs and Community Radio – opportunities & partnerships KAREN THORNE, AMAC<br />
<br />
9.30 – 10.30am Data bases and IT tools for newsrooms and marketing <br />
JUSTIN ARENSTEIN, Africa Eye News Service <br />
<br />
10.30 – 11.00am TEA<br />
<br />
11.00-11.30am State-funded support<br />
SAM GULUBE, Universal Service Agency <br />
<br />
11.30 - 12.30pm Conclusion & Way Forward<br />
ASHRAF PATEL, Open Society Institute of Southern Africa<br />
<br />
12.30 – 1.30pm LUNCH<br />
<br />
1.30pm-2.30pm More hands-on practice – using databases and Open Source Software [Optional]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Current_events&diff=1578
Current events
2005-11-20T18:30:17Z
<p>Kroux: </p>
<hr />
<div>==Current Activities==<br />
===Research===<br />
[[Port HSLS]] to Linux and FreeBSD<br />
<br />
[[Monitor Wifi Activity]]<br />
<br />
[[Protocol Shoot-out]]<br />
<br />
[[Protocol QoS Shoot-out]]<br />
<br />
===Implementation===<br />
Populate Wiki!<br />
<br />
Build and test some [[Home-Brew Antennae]]<br />
<br />
Implement/test VoIP on [[49-node Indoor Mesh]]<br />
<br />
Expand the [[Rural Mesh Networks]]<br />
<br />
Expand the [[Pretoria Mesh]] <br />
<br />
Link to [http://www.meraka.org.za/digitalDoorway.htm Digital Doorway]<br />
<br />
==Upcoming Events==<br />
[[CuWIN Visit]]<br />
<br />
[[Community Media & Technology Conference]]</div>
Kroux
http://wirelessafrica.meraka.org.za/wiki/index.php?title=Current_events&diff=1577
Current events
2005-11-20T18:29:59Z
<p>Kroux: </p>
<hr />
<div>==Current Activities==<br />
===Research===<br />
[[Port HSLS]] to Linux and FreeBSD<br />
<br />
[[Monitor Wifi Activity]]<br />
<br />
[[Protocol Shoot-out]]<br />
<br />
[[Protocol QoS Shoot-out]]<br />
<br />
===Implementation===<br />
Populate Wiki!<br />
<br />
Build and test some [[Home-Brew Antennae]]<br />
<br />
Implement/test VoIP on [[49-node Indoor Mesh]]<br />
<br />
Expand the [[Rural Mesh Networks]]<br />
<br />
Expand the [[Pretoria Mesh]] <br />
<br />
Link to [http://www.meraka.org.za/digitalDoorway.htm Digital Doorway]<br />
<br />
==Upcoming Events==<br />
[[CuWIN Visit]]<br />
[[Community Media & Technology Conference]]</div>
Kroux