So far the best chepaest solution is again from our friends at Linksys
The WVC54G
The Linksys Wireless-G Internet Video Camera sends live video with sound through the Internet to a web. it contains its own web server, so it can connect directly to a network, either over Wireless-G (802.11g) networking, or over 10/100 Ethernet cable. MPEG-4 video compression produces a high-quality, high-framerate, up to 640x480 audio/video stream.
Quick price search on Froogle revealed price range from: $180 to $200, a Froogle price search on our WRT54G gave a price range of $70 to $85.
With the current price of the Linksys WRT54G at R700, my estimate is that we will get this wireless web enabled camera for around R1800 in South Africa - still checking with BuillionIT and Westcon.
I searched Eagles web site for similar products and they range from R5500 to R10000.
And guess what: I downloaded the source for the wireless camera - looks like linksys are sticking to their GPL ethic for all their products - this is a huge advantage - it means we can play with compressions ratios, the web interface, the camera settings - basically turn the box into anything we want
Welcome to the CSIR Meraka Institute's "COIN" Blog
Saturday, November 20, 2004
Tuesday, November 09, 2004
Wednesday, November 03, 2004
linksys: adding files to the code.bin firmware
Community I developed a script to add custom files into the Linksys filesystem. This was needed, for example, to add ripd.conf and zebra.conf to /usr/local/etc for the zebra routing daemon.
This is how it works ($LINKSYS_SRC is the directory of your linksys source code eg. /home/djohnson/downloads/linksys/sveasoft/Alchemy-2.3.4/)
1. Copy the script (makeimage.sh) to $LINKSYS_SRC/src/router
2. Copy files that you need to the $LINKSYS_SRC/src/router/mipsel-uclibc/target directory (you can make directories and add/delete files in here)
3. Execute the makeimage.sh script from the $LINKSYS_SRC/src/router directory
4. A new code.bin will be built which can be uploaded to the linksys box
The makeimage.sh script looks as follows:
#$include .config
#iLINUIXDIR=(shell pwd)
#echo $LINUXDIR
#export LINUXDIR
#export PLATFORMDIR := $(TOP)/$(PLATFORM)
#export INSTALLDIR := $(PLATFORMDIR)/install
#export TARGETDIR := $(PLATFORMDIR)/target
../linux/linux/scripts/squashfs/mksquashfs mipsel-uclibc/target mipsel-uclibc/target.squashfs -noappend
cp ../linux/linux/arch/mips/brcm-boards/bcm947xx/compressed/vmlinuz mipsel-uclibc
../../tools/trx -o mipsel-uclibc/linux.trx mipsel-uclibc/vmlinuz mipsel-uclibc/target.squashfs
cp ../linux/linux/arch/mips/brcm-boards/bcm947xx/compressed/zImage mipsel-uclibc
dd conv=sync bs=64k < mipsel-uclibc/zImage > mipsel-uclibc/linux.bin
cat mipsel-uclibc/target.squashfs >> mipsel-uclibc/linux.bin
cp mipsel-uclibc/linux.trx ../../image/linux.trx
cp ../../image/linux.trx ../../image/code.bin
This is how it works ($LINKSYS_SRC is the directory of your linksys source code eg. /home/djohnson/downloads/linksys/sveasoft/Alchemy-2.3.4/)
1. Copy the script (makeimage.sh) to $LINKSYS_SRC/src/router
2. Copy files that you need to the $LINKSYS_SRC/src/router/mipsel-uclibc/target directory (you can make directories and add/delete files in here)
3. Execute the makeimage.sh script from the $LINKSYS_SRC/src/router directory
4. A new code.bin will be built which can be uploaded to the linksys box
The makeimage.sh script looks as follows:
#$include .config
#iLINUIXDIR=(shell pwd)
#echo $LINUXDIR
#export LINUXDIR
#export PLATFORMDIR := $(TOP)/$(PLATFORM)
#export INSTALLDIR := $(PLATFORMDIR)/install
#export TARGETDIR := $(PLATFORMDIR)/target
../linux/linux/scripts/squashfs/mksquashfs mipsel-uclibc/target mipsel-uclibc/target.squashfs -noappend
cp ../linux/linux/arch/mips/brcm-boards/bcm947xx/compressed/vmlinuz mipsel-uclibc
../../tools/trx -o mipsel-uclibc/linux.trx mipsel-uclibc/vmlinuz mipsel-uclibc/target.squashfs
cp ../linux/linux/arch/mips/brcm-boards/bcm947xx/compressed/zImage mipsel-uclibc
dd conv=sync bs=64k < mipsel-uclibc/zImage > mipsel-uclibc/linux.bin
cat mipsel-uclibc/target.squashfs >> mipsel-uclibc/linux.bin
cp mipsel-uclibc/linux.trx ../../image/linux.trx
cp ../../image/linux.trx ../../image/code.bin
De-bricking Linksys WRT54G
Thanks Andrew for the help on this one
1. Enter directory with code.bin
2. Start tftp
3. >connect 192.168.1.1
4. >binary
5. >trace
6. >rexmt 1
7. >status
Should display
Connect to 192.168.1.1
Mode: octet Verbose: on Tracing: on
Rexmt-interval: 1 seconds, Max-timout: 25 seconds
8. put code.bin
9. Power cycle the Linksys - Hopefully it should upload the new firmware
10. Hold down the reset button until power light flashes
1. Enter directory with code.bin
2. Start tftp
3. >connect 192.168.1.1
4. >binary
5. >trace
6. >rexmt 1
7. >status
Should display
Connect to 192.168.1.1
Mode: octet Verbose: on Tracing: on
Rexmt-interval: 1 seconds, Max-timout: 25 seconds
8. put code.bin
9. Power cycle the Linksys - Hopefully it should upload the new firmware
10. Hold down the reset button until power light flashes
Linksys WRT54G specs summary
Specs
Ports:
* WAN: One 10/100 RJ-45 port for WAN connectivity
* LAN: Four 10/100 RJ-45 Auto-MDI(X) switched ports
* WLAN: 54mbps 802.11g on a MiniPCI card (1.0)/built-in (1.1) with dual external RP-TNC antenna ports
LED Indicators (1.0):
* Power, DMZ, Diag
* WLAN: Act, Link
* LAN: Link/Act, Full/Col, 100
* Internet: Link/Act, Full/Col, 100
Channels: 1-11 (USA)
System requirements: One PC (200MHz or Faster Processor) with: 64MB RAM, Internet Explorer 4.0 or Netscape Navigator 4.7 or Higher for Web-based Configuration, CD-ROM Drive, Microsoft Windows 98, Me, 2000, or XP, a 802.11g or 802.11b Wireless Adapter with TCP/IP Protocol Installed or Network Adapter with Category 5 Ethernet network cable and TCP/IP Protocol installed
In the box: Wireless-G Broadband Router, Power Adapter, Setup CD-ROM with User Guide, Ethernet Network Cable, Quick Installation guide, Registration Card
Device details:
* Width: 7.32 inches
* Height: 1.89 inches
* Depth: 6.89 inches
* Warranty, parts: 1-year limite
* Warranty, labor: 1-year limited
Transmit Power: 15 dBm (Can be increased to 20db/84mw) (FIX: 84mw=19.24db) Info: 15db=31mW 17db=50mW 20db=100mW
Receiver Sensitivity (unconfirmed):
* -65db for ofdm 802.11g 54 megs
* -80db for dsss 802.11b 11 megs
Power (1.0?): 5V @ 2.0A, center
Power (2.0): 12V @ 1.0A, center positive. (Regulated internally down to 3.3V by an AnaChip? 1501-33, so the unit should be very tolerant of input fluctuations from 5 to 40 volts. Get the polarity right and it'll make do with whatever you give it.)
To turn on ripd and zebra, go to Advanced -> Routing -> Dynamic Routing and click Apply."
Ports:
* WAN: One 10/100 RJ-45 port for WAN connectivity
* LAN: Four 10/100 RJ-45 Auto-MDI(X) switched ports
* WLAN: 54mbps 802.11g on a MiniPCI card (1.0)/built-in (1.1) with dual external RP-TNC antenna ports
LED Indicators (1.0):
* Power, DMZ, Diag
* WLAN: Act, Link
* LAN: Link/Act, Full/Col, 100
* Internet: Link/Act, Full/Col, 100
Channels: 1-11 (USA)
System requirements: One PC (200MHz or Faster Processor) with: 64MB RAM, Internet Explorer 4.0 or Netscape Navigator 4.7 or Higher for Web-based Configuration, CD-ROM Drive, Microsoft Windows 98, Me, 2000, or XP, a 802.11g or 802.11b Wireless Adapter with TCP/IP Protocol Installed or Network Adapter with Category 5 Ethernet network cable and TCP/IP Protocol installed
In the box: Wireless-G Broadband Router, Power Adapter, Setup CD-ROM with User Guide, Ethernet Network Cable, Quick Installation guide, Registration Card
Device details:
* Width: 7.32 inches
* Height: 1.89 inches
* Depth: 6.89 inches
* Warranty, parts: 1-year limite
* Warranty, labor: 1-year limited
Transmit Power: 15 dBm (Can be increased to 20db/84mw) (FIX: 84mw=19.24db) Info: 15db=31mW 17db=50mW 20db=100mW
Receiver Sensitivity (unconfirmed):
* -65db for ofdm 802.11g 54 megs
* -80db for dsss 802.11b 11 megs
Power (1.0?): 5V @ 2.0A, center
Power (2.0): 12V @ 1.0A, center positive. (Regulated internally down to 3.3V by an AnaChip? 1501-33, so the unit should be very tolerant of input fluctuations from 5 to 40 volts. Get the polarity right and it'll make do with whatever you give it.)
To turn on ripd and zebra, go to Advanced -> Routing -> Dynamic Routing and click Apply."
Thursday, October 28, 2004
How to set up Linksys as a RIP2 router with client mode
How to set up Linksys as a RIP2 router with client mode
1. Load Alchemy pre-release 5.2.3 onto the linksys
2. Set the Linksys Wireless interface to Client mode and set SSID to "pta-mesh"
Using the web interface select Wireless - Basic Settings
Wireless Mode : Client
SSID: pta-mesh
Select Save Settings - continue
3. Choose your IP addresses for the Wireless interface and the LAN interface
I chose the following
WAN interface: 10.50.1.13
LAN interface: 10.3.11.1
Using the Web interface select Setup - Basic Setup
Internet Connection Type: Static IP
Internet IP Address: 10.50.1.13
Subnet Mask: 255.255.255.0
Router Name: Something you like eg. david_home
Local IP Address: 10.3.11.1
Subnet Mask: 255.255.255.0
Select Save Settings - continue
4. Add router configuration files to the target directory
Enter the router directory ($LINKSYS/src/router)
# cd /mipsel-uclibc/target
# mkdir /usr/local
# mkdir /usr/local/etc
Download my RIP configuration files for linksys
ripd.conf
zebra.conf
Copy these files to $LINKSYS/src/router/mipsel-uclibc/target/usr/local/etc
Download my image making script which will build files in the code.bin image
makeimage.sh
Copy this script to $LINKSYS/src/router
Run the script
./makeimage.sh
You should now have a code.bin with the router config files in /usr/local/etc
Upload this new firmware to the linksys
5. Add commands to rc_startup to startup RIP, Flush iptables (so that RIP messages can arrive on RIP port) and remove NAT
zebra -d -f /usr/local/etc/zebra.conf
ripd -d -f /usr/local/etc/ripd.conf
iptables -F
iptables -F -t nat
8. You should now have a rip enabled linksys client - Try ping the network connected to the wireless interface from a machine connected to the LAN
Things to improve in this recipe
1. Don't flush all iptables - just enable the port for RIP routing
2. Find location in Makefile where the code.bin image is made - don't need my custom script
1. Load Alchemy pre-release 5.2.3 onto the linksys
2. Set the Linksys Wireless interface to Client mode and set SSID to "pta-mesh"
Using the web interface select Wireless - Basic Settings
Wireless Mode : Client
SSID: pta-mesh
Select Save Settings - continue
3. Choose your IP addresses for the Wireless interface and the LAN interface
I chose the following
WAN interface: 10.50.1.13
LAN interface: 10.3.11.1
Using the Web interface select Setup - Basic Setup
Internet Connection Type: Static IP
Internet IP Address: 10.50.1.13
Subnet Mask: 255.255.255.0
Router Name: Something you like eg. david_home
Local IP Address: 10.3.11.1
Subnet Mask: 255.255.255.0
Select Save Settings - continue
4. Add router configuration files to the target directory
Enter the router directory ($LINKSYS/src/router)
# cd /mipsel-uclibc/target
# mkdir /usr/local
# mkdir /usr/local/etc
Download my RIP configuration files for linksys
ripd.conf
zebra.conf
Copy these files to $LINKSYS/src/router/mipsel-uclibc/target/usr/local/etc
Download my image making script which will build files in the code.bin image
makeimage.sh
Copy this script to $LINKSYS/src/router
Run the script
./makeimage.sh
You should now have a code.bin with the router config files in /usr/local/etc
Upload this new firmware to the linksys
5. Add commands to rc_startup to startup RIP, Flush iptables (so that RIP messages can arrive on RIP port) and remove NAT
zebra -d -f /usr/local/etc/zebra.conf
ripd -d -f /usr/local/etc/ripd.conf
iptables -F
iptables -F -t nat
8. You should now have a rip enabled linksys client - Try ping the network connected to the wireless interface from a machine connected to the LAN
Things to improve in this recipe
1. Don't flush all iptables - just enable the port for RIP routing
2. Find location in Makefile where the code.bin image is made - don't need my custom script
Monday, October 25, 2004
Thursday, October 21, 2004
Compiling Satori 4.0 with latest tool chain
To compile using the latest toolchain:
1) Apply this patch (also fixes zebra):
http://www.greyskydesigns.com/~lonewolf/satori_fix.patch
Code:
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G$ patch -p1 --dry-run
patching file src/router/rc/writeimage.c
patching file src/router/zebra/Makefile
patching file src/router/zebra/lib/Makefile
patching file src/router/zebra/ospfd/Makefile
patching file src/router/zebra/ripd/Makefile
patching file src/router/zebra/zebra/Makefile
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G$ patch -p1
patching file src/router/rc/writeimage.c
patching file src/router/zebra/Makefile
patching file src/router/zebra/lib/Makefile
patching file src/router/zebra/ospfd/Makefile
patching file src/router/zebra/ripd/Makefile
patching file src/router/zebra/zebra/Makefile
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G.orig$
2) Run 'make'
3) When 'make' errors out, run 'for i in src/router/iproute2/lib/*.a; do mipsel-uclibc-ranlib $i; done'
4) Run make again
5) for i in src/router/iproute2/tc/*.a; do mipsel-uclibc-ranlib $i; done
6) make yet again
Check out here for the forum discussion at sveasoft on the topic
1) Apply this patch (also fixes zebra):
http://www.greyskydesigns.com/~lonewolf/satori_fix.patch
Code:
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G$ patch -p1 --dry-run
patching file src/router/rc/writeimage.c
patching file src/router/zebra/Makefile
patching file src/router/zebra/lib/Makefile
patching file src/router/zebra/ospfd/Makefile
patching file src/router/zebra/ripd/Makefile
patching file src/router/zebra/zebra/Makefile
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G$ patch -p1
patching file src/router/rc/writeimage.c
patching file src/router/zebra/Makefile
patching file src/router/zebra/lib/Makefile
patching file src/router/zebra/ospfd/Makefile
patching file src/router/zebra/ripd/Makefile
patching file src/router/zebra/zebra/Makefile
lonewolf@lonewolf:/data4/wrt54g/satori/WRT54G.orig$
2) Run 'make'
3) When 'make' errors out, run 'for i in src/router/iproute2/lib/*.a; do mipsel-uclibc-ranlib $i; done'
4) Run make again
5) for i in src/router/iproute2/tc/*.a; do mipsel-uclibc-ranlib $i; done
6) make yet again
Check out here for the forum discussion at sveasoft on the topic
Monday, October 18, 2004
Thursday, October 07, 2004
How to route between WLAN and LAN on the linksys box
Make sure you have installed Sveasoft Alchemy 5.2.4
Go to Administration - Diagnostics and enter the following into the command line
brctl delif br0 eth1
ifconfig eth1 down
ifconfig eth1 up
if addr add 192.168.2.1/24 dev eth1
Click on "save startup"
Reboot linksys
This will create a new subnet for the wireless side of the router on the 192.168.2.0 network
The LAN side of the router will remain on the 192.168.1.0 network
Go to Administration - Diagnostics and enter the following into the command line
brctl delif br0 eth1
ifconfig eth1 down
ifconfig eth1 up
if addr add 192.168.2.1/24 dev eth1
Click on "save startup"
Reboot linksys
This will create a new subnet for the wireless side of the router on the 192.168.2.0 network
The LAN side of the router will remain on the 192.168.1.0 network
Tuesday, September 28, 2004
The revolution has begun
Here is a list of all the people registered on www.nodedb.com in Johburg and Pretoria with wifi access points. Disorganised collection of people with all sorts of AP's - no one doing any meshing as yet. Question is - does the CSIR reveal their network to the general population - register on nodedb.com?? Security issues could prohibit and we have a different purpose - namely Removing the barriers to enable bottom-up creation of access infrastructure through use of wireless mesh netwirking - their purpose is similar to CB radio - just make a community network. It might be good though to involve a few of these nodes in Pta if the can help on linux/linksys coding side - we could isolate them from the csir network.
List of all active Pretoria nodes
List of all active Johannesburg nodes
Also thanks Albert for pointing our JAWUG (Johannesburg Area Wireless User Group)
JAWUG
The vision of JaWug is to create the largest Community run Wireless Network in the Johannesburg area.
JaWug is a not-for-profit effort to develop a wireless broadband community network in Johannesburg - a free, locally owned wireless backbone.
To get aroung any legal attacks they put a discalimer on their site: Please Note: We do NOT sell Internet connectivity!
There is also a lot of actiuvity and interest in Pretoria - apparently a network called FreeNet - can't find a URL - found this long discussion on the south african myadsl forum
Discussion about sharing ADSL through WiFi in Pta
List of all active Pretoria nodes
List of all active Johannesburg nodes
Also thanks Albert for pointing our JAWUG (Johannesburg Area Wireless User Group)
JAWUG
The vision of JaWug is to create the largest Community run Wireless Network in the Johannesburg area.
JaWug is a not-for-profit effort to develop a wireless broadband community network in Johannesburg - a free, locally owned wireless backbone.
To get aroung any legal attacks they put a discalimer on their site: Please Note: We do NOT sell Internet connectivity!
There is also a lot of actiuvity and interest in Pretoria - apparently a network called FreeNet - can't find a URL - found this long discussion on the south african myadsl forum
Discussion about sharing ADSL through WiFi in Pta
Wednesday, September 22, 2004
Here's an idea for assigning IP addresses to houses
Got this idea from CU wireless
"We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in 'reading order.' That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16. (We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.) The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24."
"We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in 'reading order.' That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16. (We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.) The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24."
Here's an idea for assigning IP addresses to houses
Got this idea from CU wireless
"We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in 'reading order.' That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16. (We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.) The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24."
"We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in 'reading order.' That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16. (We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.) The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24."
Monday, September 20, 2004
Wednesday, September 08, 2004
Got a c++ program compiled for linksys
The C++ environment is configured!
1.Download the linksys firmware source
2. Copy the brcm/ directory from/tools to /opt
3. add /opt/brcm/hndtools-mipsel-linux/bin to your path
4. add /opt/brcm/hndtools-mipsel-uclibc/bin to your path
Use mipsel-linux-g++ compiler to compile any c++ code
Don't use the mipsel-uclibc-g++ compiler - this was my mistake!
Now we can try compile mobile mesh for linksys
1.Download the linksys firmware source
2. Copy the brcm/ directory from
3. add /opt/brcm/hndtools-mipsel-linux/bin to your path
4. add /opt/brcm/hndtools-mipsel-uclibc/bin to your path
Use mipsel-linux-g++ compiler to compile any c++ code
Don't use the mipsel-uclibc-g++ compiler - this was my mistake!
Now we can try compile mobile mesh for linksys
Linksys box processor has memory management!
The Linksys processor is a 200MHz MIPS32 core which has a memory management unit with simple fixed mapping translation (FMT) - see this link for more details - so FreeBSD may be possible!
description of MIPS32 core
Reminder of other details:
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: Intel TE28F320 C3 flash 32Mbit chip (4MB)
CPU: Broadcom [WWW]BCM4712KPB, running at 200MHz
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
Wireless: On board; Broadcom BCM2050KWL
description of MIPS32 core
Reminder of other details:
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: Intel TE28F320 C3 flash 32Mbit chip (4MB)
CPU: Broadcom [WWW]BCM4712KPB, running at 200MHz
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
Wireless: On board; Broadcom BCM2050KWL
Tuesday, September 07, 2004
Message sent to Kevin Grace at MITRE
Dear Kevin Grace
The CSIR in South Africa is an organisation much like yours with a vision of using multidisciplinary engineering and scientific research in partnership with government to address issues of critical national importance - which in our case is addressing problems from the legacy of an apartheid government such as poverty, job creation, and addressing the lack of good health and education facilities in disadvantaged communities.
Some of the areas that we are addressing are the lack of telecommunications infrastructure - particularly in the rural areas of our country. We are busy exploring and researching the idea of communities building their own infrastructure using Wifi mesh networks as a basis on which mini community owned wireless networks will be built.
Mobile mesh naturally caught our interest and we have been experimenting with it on Linux PC environments. We have also made a port of mobile mesh which compiles on a FreeBSD machine which you might be interested in.
We have purchased some Linksys WRT54G wireless routers which have cuaused quite a storm due to their low cost - approximately $90 for a device which includes a 200MHz MIPs processor, 32M ram, 16M flash and built in 802.11b/g and it is packaged running a thinned out version of Linux. The entire source and build environemnt is also made available by Linksys under GPL - which creates exciting opportunities to add your own custom software such as mesh protocols and congestion control etc.
Our next task is to port mobile mesh to this MIPS based Linksys wireless router. Our first challenge is getting a c++ cross compile tool chain with stdlibc++. This has proved quite a challenge. Has any effort been made to move mobile mesh to pure ANSI C code or to cross compile it for an enviroment such as this.
We would also like to explore the possibility of collaboration with your organisation in the field of wireless networking - we have been working in this area for the past 10 years and their might be some good synergies and shared learning.
Best Regards
David Johnson
ICT for development Infrastructure
Information Society Technology Centre (ISTC)
Icomtek CSIR South Africa
Phone: +27 12 8414266
Fax: +27 12 8414829
Address: PO Box 395, Pretoria, 0001
The CSIR in South Africa is an organisation much like yours with a vision of using multidisciplinary engineering and scientific research in partnership with government to address issues of critical national importance - which in our case is addressing problems from the legacy of an apartheid government such as poverty, job creation, and addressing the lack of good health and education facilities in disadvantaged communities.
Some of the areas that we are addressing are the lack of telecommunications infrastructure - particularly in the rural areas of our country. We are busy exploring and researching the idea of communities building their own infrastructure using Wifi mesh networks as a basis on which mini community owned wireless networks will be built.
Mobile mesh naturally caught our interest and we have been experimenting with it on Linux PC environments. We have also made a port of mobile mesh which compiles on a FreeBSD machine which you might be interested in.
We have purchased some Linksys WRT54G wireless routers which have cuaused quite a storm due to their low cost - approximately $90 for a device which includes a 200MHz MIPs processor, 32M ram, 16M flash and built in 802.11b/g and it is packaged running a thinned out version of Linux. The entire source and build environemnt is also made available by Linksys under GPL - which creates exciting opportunities to add your own custom software such as mesh protocols and congestion control etc.
Our next task is to port mobile mesh to this MIPS based Linksys wireless router. Our first challenge is getting a c++ cross compile tool chain with stdlibc++. This has proved quite a challenge. Has any effort been made to move mobile mesh to pure ANSI C code or to cross compile it for an enviroment such as this.
We would also like to explore the possibility of collaboration with your organisation in the field of wireless networking - we have been working in this area for the past 10 years and their might be some good synergies and shared learning.
Best Regards
David Johnson
ICT for development Infrastructure
Information Society Technology Centre (ISTC)
Icomtek CSIR South Africa
Phone: +27 12 8414266
Fax: +27 12 8414829
Address: PO Box 395, Pretoria, 0001
Monday, September 06, 2004
mesh on linksys - comments from sveasoft
On Sat Jan 10, 2004 sveasoft placed the following poll on their forum: should we build a WRT54G mesh box?
How many folks would like to see a fully interconnected wireless mesh based on the WRT54G?
This would require dumping the WRT54G application source tree and starting anew with an AODV port and some tricky routing daemons built from scratch.
The result from the user base was 79% were for it and 20% were against it
Some highlights from the respondants
******************
Posted: Fri Jan 30, 2004 16:44
I would be *very* happy if that could be implemented. Why not using "mobile mesh" from http://www.mitre.org/work/tech_transfer/mobilemesh/ ?
I've only heard nice things about it (e.g. finds other nodes swiftly, uses wired links (via so called border gateways) to decrease the load on the wireless links if necessary etc.)
There are quite a few initiaves in several towns who want to build up free networks. Meshing is one of the things very much needing!
*****************
Posted: Wed Feb 04, 2004 22:23
I'd love to be able to setup my WRT54G as a mesh-capable box. I had looked into running the locust software a while ago, but my hardware (an older model laptop) wasn't up to the job. But perhaps more importantly, I didn't have anyone else to connect with! If a widely available box like the WRT54G supported meshing, there'd be a far greater chance that others in the area would spend the $80 (on the box) to join the network.
My fantasy world would have a few dozen meshing boxes around the city, all forming a private network. Other mesh servers could join the mesh without pre-coordination (though there would be protection against rogue-meshboxen trying to DOS or whatever). Clients could roam easily. If the box was connected to the Internet, you'd have the option of sharing it publicly to locally connected clients only, publicly to the whole mesh, or privately (through the mesh) via ipsec/pptp/whatever.
*****************
Posted: Wed Feb 04, 2004 23:05
I would absolutly LOVE to see mesh on this device. Locustworld would be nice
as it would allow already deployed networks to add this unit. IMO there needs to be a way to control what channel the mesh lives on. You do not want the entire mesh running on 1 channel. You want to beable to make sectors and have gateways that transport between the two. Locustworld is in the best position to develop such a item due to there central registration and configuration setup they have.
********************
Posted: Wed Feb 04, 2004 23:19
Posted by sveasoft again
We are looking at using IPv6 and incorporating the Ethernet MAC so we won't need to interact with IANA or any other central body.
At this point I think we will stick with BSS mode and use WDS for the links, depending on what limits we find while developing and testing.
This will mean the mesh build will support all 802.11b/g clients out of the box rather than requiring adhoc mode.
********************
Posted: Thu Feb 05, 2004 04:05
OK the thing about Mesh's and there best advantage is you don;t need to be with in the range of a AP only with in range of anothe rmesh use and you can hope through them to the AP hence you ned to keep this in Ad-Hoc mode other wise you are limiting the mesh to AP's only and there i sno way to have the mesh expand at large.
I am right now working on a mesh project and we loked at using the wrt54g but I could not get the wifi card to go into adhoc mode, if I could I woulsd be all over this in a heart beat.
We are doign this wiht out ham community to try and provide coms fo rthe hams (since we can use more power on the band) and this will greatly increase the range of the mesh, we are workgin with Mobile Mesh and IP Mesh Linuz and Windows Versions yes and they work well together.
**********************
Posted: Thu Feb 05, 2004 09:27
Posted by sveasoft again
Adhoc mode is supported in the Sveasoft firmware. But adhoc mode is not interoperable across all manufacturers.
With WDS we get the same peer-to-peer connectability as with adhoc mode but still remain completely compatible with the many 802.11b and 802.11g client products on the market.
Fom a mesh topolgy and routing viewpoint there is no difference in using adhoc versus WDS.
**********************
Posted: Thu Feb 05, 2004 20:06
But WDS means layer 2, meaning broadcasts over a whole town in certain situations. I think you should modulize the distro so that I can build my "mobile mesh" (pro-active protocol) whereas others can build there AODV (on-demand protocol) modul/package.
*********************
Posted: Fri Feb 06, 2004 17:19
I am workgi with a small group in my city now to get soem inital ground work and Nodes up and runign and then bring more members of our clud online.
Presently we are doing this on small linux boxes with PC cards or ethernet bridges.
We also want to keep the adverage user in mind that won't have a clue of linux and have a Windows client for them to work with. or a great sveasoft firmware to load on a WRT54G (that would work nicely)
Right now we are in the testin stages and can report back more feed back in a while.
But there is our inital thoughts on what a box needs to have in it.
-Linux
-full IP routing (zebra maybe)
-two interfaces (or more, WAN & Wireless more is local switch)
-Selectable AP or ADHOC mode
-iptables stateful firewall
-mobilemesh, olsr, aodv
-QoS
-dns (cache or proxy)
-dhcp (with Reservations)
-VPN for LAN-to-LAN & wifi Client to BOx
-Radius Client for Auth or differnet services
-SSH (no Telnet, maybe a Web is OK to keep)
-Maybe SNMP for monitoring with a Central host like OpenView or something
-WDS add on to help build backhaul links
************************
Posted: Mon Feb 16, 2004 16:27
For those interested in Mesh networking, It might be interesting to see if MIT's Roof Net could run on the box. As an aside, it brings back memories to see who's behind the project. Everyone remember Robert Morris?
Source is available on their site : MIT's Roof Net
************************
Posted: Thu Feb 19, 2004 11:19
what about the meshstuff used in roofnet. (DSDV + X )
Network Description: http://www.pdos.lcs.mit.edu/roofnet/index.php
Software http://sourceforge.net/projects/roofnet/
Thesis: http://www.pdos.lcs.mit.edu//papers/grid:bac-meng.pdf
gives anice overview about routing techniques
and experienced problems!
***************************
Posted: Sat Feb 21, 2004 08:31
there is alao a mash setup for pebble linux, maybe it would work for you:
http://www.nycwireless.net/pebble/
near the bottom
http://www.sown.org.uk/pebble-mesh.tar.gz
***************************
Posted: Wed Mar 03, 2004 13:37
roofnet software looks cool, dunno about thier approach to hidden nodes,
and wireless collisions, they seems to go for a complete mesh using
onmi's , rather than directional client/backbone setup which scales.... Using NAT at each node too, simplfies configuration, but it's just extra hassle to configure network applications, uses more resources at router level, and these days, I don't see what benefits NAT gives you over a normal software firewall for a small home user lan, so using a fully routed mesh without nat is the way to go.
I don't see how this will scale, if it's get busy, there's going to be so much interference from the onmi's the mesh will grind to a halt, but I guess there's other network design goal rather than speed, nah, I'm kidding myself......
Fast - Cheap - Reliable .... choose two..
I really think with wrt54g you can have two, and the reliablity is to use
multiple units for redundancy, because there cheap.... )
I think porting thier routing roofnet protcols to the wrt54g is a great Idea, wether or not thier just going to give away all the hard coding work and research material is another thing, no such thing as a free lunch.
***********************
Posted: Sat Mar 06, 2004 23:38
Which one is the question. Having spent many hours reading about varous mesh projects, I like the MIT roofnet project. It looks well designed. They are using SrcRR (see http://www.pdos.lcs.mit.edu/roofnet/design/).
Why? In my case I am in the early stages of building a network in hilly bush clad terrain. I want the meshing, not just for the redundancy, but to get around hills and trees. The redundancy is an added bonus. I wouldn't get very much meshing occuring though. Most housing can only see a small subset of others, if any at all. (http://www.burrowes.org/WiKarekare/ The picture at the top illustrates the problem )
Would I be interested in helping? Yes, I was going to look at this anyway. I bought the linksys boxes with this in mind, knowing that the source tree was available. I was going to start with a static mesh using OSPF and work up to a more adaptive one or a combination of static core and adaptive edges.
***************************
Posted: Sun Mar 07, 2004 16:32
Posted by sveasoft again
Hi Rob,
This was actually my inspiration for creating my own firmware builds in the first place. The weatherproof box in the Products section is also the result of living in a hilly, forested, wet area with no broadband in sight in Sweden.
I currently use OSPF with redundant WDS links to make this work. I can say that, though it works pretty well, it requires a LOT of tuning.
My goal has always been to start from a clean kernel and build a mesh on the Linksys hardware. My current design uses IPv6 for the internall mesh, DSTM for IPv4 support, and a custom routing program yet to be written that will route and balance based on a dynamic link strength and throughput metric.
My goal is to throw up a bunch of weatherproof nodes on the rooftops and tell a couple of them where to find the Internet. Any 802.11b/g client with the right security should be able to connect and each household can just plug into the hub.
Link to questions about mesh on linksys on sveasoft
****************************
Posted: Tue Mar 09, 2004 18:19
It's allready done
You can find it here: http://www.paris-sansfil.fr/~thus/wrt54g/firmware/code-kernel_aodv-adhoc-daemon.bin
Temporarly unavaillable...
If someone want it i can send a copy of the one i've downloaded some days ago by mail but i don't have the source code...
*************************
Posted: Wed Mar 10, 2004 09:15
here is the root on the above URL
http://www.paris-sansfil.fr/~thus/wrt54g/
***********************
Posted: Sun Mar 21, 2004 02:50
This is my goal as well. I'm envisioning the ability to extend that network rapidly during an emergency by putting up a few 10M masts with nodes on top. "User Gateways" would be a WRT/WAP54G loaded with the mesh firmware and a small local LAN connected via the wired Ethernet ports. While such a network would be very useful and convenient during normal oeprations it would really by during some type of emergency (I'm a ham radio operator) that it would be incredibly useful.
***********************
Posted: Mon Mar 22, 2004 02:14
I found a posting that indicated that the MIT people were working on a roofnet/wrt54g solution. I emailed them and got a response indicating that they have pre-alpha source, but need to strip the code down to fit on the wrt54g.
**********************
Posted: Wed Jun 09, 2004 22:19
The only thing that bothered me in reading the CBRP overview is that you seem to have to nominate "cluster heads" which would stop it being a true self configuire mesh like a community mesh should be. For that reason AODV or DSR might be a better bet.
Another interesting protocol is AODV6 which is AODV for IPv6, there is linux code out for it already.
**********************
Posted: Thu Jun 10, 2004 03:34
Guys Dont; forget about mobile mesh it already takes care of this.
the node advertises if it is a gateway or other route and then the clients all figure out which once is closest to them and uses that one, lets not reincent the wheel here.
Will
********************
Posted: Fri Jun 11, 2004 13:25
My vote is for roofnet. Only problem that they may have is that there are no AP's in their system, you have to be wired to an accesspoint, or that was my understanding last time I looked.
I would be thrilled with any decent wrt mesh though.
Think about it. Huge scalable networks built for the same price as a cable modem with no configuration. Add on a server to authenticate and you're done. You could build a WISP and have your users pay all of the infrastructure costs by simply purchasing an AP.
*******************
Posted: Sat Jun 12, 2004 22:18
Posted by sveasoft again
Adhoc is available in Satori. You do not need adhoc mode to create a self-configuring mesh (where do these urban legends come from?).
One popular version of AODV runs as a kernel module. You can patch the existing kernel and add it. Several other versions run in userspace. Routing runs just as well (actually it is much safer and easier to develop) in userspace as in the kernel. All routing software does as far as the kernel is concerned is update the kernel routing tables.
***********************
Posted: Wed Jun 16, 2004 12:28
I have been looking for a low cost meshbox solution for a community networking project and I am encouraged by the content of this thread.
I had considered the Locustworld meshbox, however this is a relatively expensive solution, that is 'locked in' to WIANA, as highlighted by previous posts.
At what stage is the development of the meshbox 'firmware', and is it possible to compare the functionality of the WRT54 meshbox to that of the Locust world meshbox?
It is highly probable that I would be using the WRT54GS as they appear to be the only models currently available.
Keep up the good work!
*****************
Posted: Fri Jun 18, 2004 13:58
I am not sure if this was mentioned earlier, since i just went through 6 months of posts in 6 minutes, but a Norwegian named Andreas Tønnesen is working on: Optimized Link State Routing protocol (OLSR). It seems to do just the trick.
Pls check: http://www.olsr.org/
I know www.amsterdam-wireless.nl is switching over from mobileMesh to OLSR.
P.S. I would love to see smart mesh routing happen on the WRT54G !
********************
Posted: Wed Jun 30, 2004 01:17
check out http://meshcube.org for another cool mesh routing device running MobileMesh and OLSR
*********************
Posted: Wed Jun 30, 2004 23:24
I whole heartedly agree with PatchesJ. The satori and alchemy distributions are excellent and supply the hotspot folks with wifi in a box but a mesh box would satisfy more of a community based market where users just want to plug in and go.
A beautiful arrangement would be alchemy as your gateway and mesh nodes for your clients or for broader cell coverage.
I'd love to see just a barebones mesh box!
*************************
See the following local link for all the posts to the forum
Sveasoft discussion on mesh
How many folks would like to see a fully interconnected wireless mesh based on the WRT54G?
This would require dumping the WRT54G application source tree and starting anew with an AODV port and some tricky routing daemons built from scratch.
The result from the user base was 79% were for it and 20% were against it
Some highlights from the respondants
******************
Posted: Fri Jan 30, 2004 16:44
I would be *very* happy if that could be implemented. Why not using "mobile mesh" from http://www.mitre.org/work/tech_transfer/mobilemesh/ ?
I've only heard nice things about it (e.g. finds other nodes swiftly, uses wired links (via so called border gateways) to decrease the load on the wireless links if necessary etc.)
There are quite a few initiaves in several towns who want to build up free networks. Meshing is one of the things very much needing!
*****************
Posted: Wed Feb 04, 2004 22:23
I'd love to be able to setup my WRT54G as a mesh-capable box. I had looked into running the locust software a while ago, but my hardware (an older model laptop) wasn't up to the job. But perhaps more importantly, I didn't have anyone else to connect with! If a widely available box like the WRT54G supported meshing, there'd be a far greater chance that others in the area would spend the $80 (on the box) to join the network.
My fantasy world would have a few dozen meshing boxes around the city, all forming a private network. Other mesh servers could join the mesh without pre-coordination (though there would be protection against rogue-meshboxen trying to DOS or whatever). Clients could roam easily. If the box was connected to the Internet, you'd have the option of sharing it publicly to locally connected clients only, publicly to the whole mesh, or privately (through the mesh) via ipsec/pptp/whatever.
*****************
Posted: Wed Feb 04, 2004 23:05
I would absolutly LOVE to see mesh on this device. Locustworld would be nice
as it would allow already deployed networks to add this unit. IMO there needs to be a way to control what channel the mesh lives on. You do not want the entire mesh running on 1 channel. You want to beable to make sectors and have gateways that transport between the two. Locustworld is in the best position to develop such a item due to there central registration and configuration setup they have.
********************
Posted: Wed Feb 04, 2004 23:19
Posted by sveasoft again
We are looking at using IPv6 and incorporating the Ethernet MAC so we won't need to interact with IANA or any other central body.
At this point I think we will stick with BSS mode and use WDS for the links, depending on what limits we find while developing and testing.
This will mean the mesh build will support all 802.11b/g clients out of the box rather than requiring adhoc mode.
********************
Posted: Thu Feb 05, 2004 04:05
OK the thing about Mesh's and there best advantage is you don;t need to be with in the range of a AP only with in range of anothe rmesh use and you can hope through them to the AP hence you ned to keep this in Ad-Hoc mode other wise you are limiting the mesh to AP's only and there i sno way to have the mesh expand at large.
I am right now working on a mesh project and we loked at using the wrt54g but I could not get the wifi card to go into adhoc mode, if I could I woulsd be all over this in a heart beat.
We are doign this wiht out ham community to try and provide coms fo rthe hams (since we can use more power on the band) and this will greatly increase the range of the mesh, we are workgin with Mobile Mesh and IP Mesh Linuz and Windows Versions yes and they work well together.
**********************
Posted: Thu Feb 05, 2004 09:27
Posted by sveasoft again
Adhoc mode is supported in the Sveasoft firmware. But adhoc mode is not interoperable across all manufacturers.
With WDS we get the same peer-to-peer connectability as with adhoc mode but still remain completely compatible with the many 802.11b and 802.11g client products on the market.
Fom a mesh topolgy and routing viewpoint there is no difference in using adhoc versus WDS.
**********************
Posted: Thu Feb 05, 2004 20:06
But WDS means layer 2, meaning broadcasts over a whole town in certain situations. I think you should modulize the distro so that I can build my "mobile mesh" (pro-active protocol) whereas others can build there AODV (on-demand protocol) modul/package.
*********************
Posted: Fri Feb 06, 2004 17:19
I am workgi with a small group in my city now to get soem inital ground work and Nodes up and runign and then bring more members of our clud online.
Presently we are doing this on small linux boxes with PC cards or ethernet bridges.
We also want to keep the adverage user in mind that won't have a clue of linux and have a Windows client for them to work with. or a great sveasoft firmware to load on a WRT54G (that would work nicely)
Right now we are in the testin stages and can report back more feed back in a while.
But there is our inital thoughts on what a box needs to have in it.
-Linux
-full IP routing (zebra maybe)
-two interfaces (or more, WAN & Wireless more is local switch)
-Selectable AP or ADHOC mode
-iptables stateful firewall
-mobilemesh, olsr, aodv
-QoS
-dns (cache or proxy)
-dhcp (with Reservations)
-VPN for LAN-to-LAN & wifi Client to BOx
-Radius Client for Auth or differnet services
-SSH (no Telnet, maybe a Web is OK to keep)
-Maybe SNMP for monitoring with a Central host like OpenView or something
-WDS add on to help build backhaul links
************************
Posted: Mon Feb 16, 2004 16:27
For those interested in Mesh networking, It might be interesting to see if MIT's Roof Net could run on the box. As an aside, it brings back memories to see who's behind the project. Everyone remember Robert Morris?
Source is available on their site : MIT's Roof Net
************************
Posted: Thu Feb 19, 2004 11:19
what about the meshstuff used in roofnet. (DSDV + X )
Network Description: http://www.pdos.lcs.mit.edu/roofnet/index.php
Software http://sourceforge.net/projects/roofnet/
Thesis: http://www.pdos.lcs.mit.edu//papers/grid:bac-meng.pdf
gives anice overview about routing techniques
and experienced problems!
***************************
Posted: Sat Feb 21, 2004 08:31
there is alao a mash setup for pebble linux, maybe it would work for you:
http://www.nycwireless.net/pebble/
near the bottom
http://www.sown.org.uk/pebble-mesh.tar.gz
***************************
Posted: Wed Mar 03, 2004 13:37
roofnet software looks cool, dunno about thier approach to hidden nodes,
and wireless collisions, they seems to go for a complete mesh using
onmi's , rather than directional client/backbone setup which scales.... Using NAT at each node too, simplfies configuration, but it's just extra hassle to configure network applications, uses more resources at router level, and these days, I don't see what benefits NAT gives you over a normal software firewall for a small home user lan, so using a fully routed mesh without nat is the way to go.
I don't see how this will scale, if it's get busy, there's going to be so much interference from the onmi's the mesh will grind to a halt, but I guess there's other network design goal rather than speed, nah, I'm kidding myself......
Fast - Cheap - Reliable .... choose two..
I really think with wrt54g you can have two, and the reliablity is to use
multiple units for redundancy, because there cheap.... )
I think porting thier routing roofnet protcols to the wrt54g is a great Idea, wether or not thier just going to give away all the hard coding work and research material is another thing, no such thing as a free lunch.
***********************
Posted: Sat Mar 06, 2004 23:38
Which one is the question. Having spent many hours reading about varous mesh projects, I like the MIT roofnet project. It looks well designed. They are using SrcRR (see http://www.pdos.lcs.mit.edu/roofnet/design/).
Why? In my case I am in the early stages of building a network in hilly bush clad terrain. I want the meshing, not just for the redundancy, but to get around hills and trees. The redundancy is an added bonus. I wouldn't get very much meshing occuring though. Most housing can only see a small subset of others, if any at all. (http://www.burrowes.org/WiKarekare/ The picture at the top illustrates the problem )
Would I be interested in helping? Yes, I was going to look at this anyway. I bought the linksys boxes with this in mind, knowing that the source tree was available. I was going to start with a static mesh using OSPF and work up to a more adaptive one or a combination of static core and adaptive edges.
***************************
Posted: Sun Mar 07, 2004 16:32
Posted by sveasoft again
Hi Rob,
This was actually my inspiration for creating my own firmware builds in the first place. The weatherproof box in the Products section is also the result of living in a hilly, forested, wet area with no broadband in sight in Sweden.
I currently use OSPF with redundant WDS links to make this work. I can say that, though it works pretty well, it requires a LOT of tuning.
My goal has always been to start from a clean kernel and build a mesh on the Linksys hardware. My current design uses IPv6 for the internall mesh, DSTM for IPv4 support, and a custom routing program yet to be written that will route and balance based on a dynamic link strength and throughput metric.
My goal is to throw up a bunch of weatherproof nodes on the rooftops and tell a couple of them where to find the Internet. Any 802.11b/g client with the right security should be able to connect and each household can just plug into the hub.
Link to questions about mesh on linksys on sveasoft
****************************
Posted: Tue Mar 09, 2004 18:19
It's allready done
You can find it here: http://www.paris-sansfil.fr/~thus/wrt54g/firmware/code-kernel_aodv-adhoc-daemon.bin
Temporarly unavaillable...
If someone want it i can send a copy of the one i've downloaded some days ago by mail but i don't have the source code...
*************************
Posted: Wed Mar 10, 2004 09:15
here is the root on the above URL
http://www.paris-sansfil.fr/~thus/wrt54g/
***********************
Posted: Sun Mar 21, 2004 02:50
This is my goal as well. I'm envisioning the ability to extend that network rapidly during an emergency by putting up a few 10M masts with nodes on top. "User Gateways" would be a WRT/WAP54G loaded with the mesh firmware and a small local LAN connected via the wired Ethernet ports. While such a network would be very useful and convenient during normal oeprations it would really by during some type of emergency (I'm a ham radio operator) that it would be incredibly useful.
***********************
Posted: Mon Mar 22, 2004 02:14
I found a posting that indicated that the MIT people were working on a roofnet/wrt54g solution. I emailed them and got a response indicating that they have pre-alpha source, but need to strip the code down to fit on the wrt54g.
**********************
Posted: Wed Jun 09, 2004 22:19
The only thing that bothered me in reading the CBRP overview is that you seem to have to nominate "cluster heads" which would stop it being a true self configuire mesh like a community mesh should be. For that reason AODV or DSR might be a better bet.
Another interesting protocol is AODV6 which is AODV for IPv6, there is linux code out for it already.
**********************
Posted: Thu Jun 10, 2004 03:34
Guys Dont; forget about mobile mesh it already takes care of this.
the node advertises if it is a gateway or other route and then the clients all figure out which once is closest to them and uses that one, lets not reincent the wheel here.
Will
********************
Posted: Fri Jun 11, 2004 13:25
My vote is for roofnet. Only problem that they may have is that there are no AP's in their system, you have to be wired to an accesspoint, or that was my understanding last time I looked.
I would be thrilled with any decent wrt mesh though.
Think about it. Huge scalable networks built for the same price as a cable modem with no configuration. Add on a server to authenticate and you're done. You could build a WISP and have your users pay all of the infrastructure costs by simply purchasing an AP.
*******************
Posted: Sat Jun 12, 2004 22:18
Posted by sveasoft again
Adhoc is available in Satori. You do not need adhoc mode to create a self-configuring mesh (where do these urban legends come from?).
One popular version of AODV runs as a kernel module. You can patch the existing kernel and add it. Several other versions run in userspace. Routing runs just as well (actually it is much safer and easier to develop) in userspace as in the kernel. All routing software does as far as the kernel is concerned is update the kernel routing tables.
***********************
Posted: Wed Jun 16, 2004 12:28
I have been looking for a low cost meshbox solution for a community networking project and I am encouraged by the content of this thread.
I had considered the Locustworld meshbox, however this is a relatively expensive solution, that is 'locked in' to WIANA, as highlighted by previous posts.
At what stage is the development of the meshbox 'firmware', and is it possible to compare the functionality of the WRT54 meshbox to that of the Locust world meshbox?
It is highly probable that I would be using the WRT54GS as they appear to be the only models currently available.
Keep up the good work!
*****************
Posted: Fri Jun 18, 2004 13:58
I am not sure if this was mentioned earlier, since i just went through 6 months of posts in 6 minutes, but a Norwegian named Andreas Tønnesen is working on: Optimized Link State Routing protocol (OLSR). It seems to do just the trick.
Pls check: http://www.olsr.org/
I know www.amsterdam-wireless.nl is switching over from mobileMesh to OLSR.
P.S. I would love to see smart mesh routing happen on the WRT54G !
********************
Posted: Wed Jun 30, 2004 01:17
check out http://meshcube.org for another cool mesh routing device running MobileMesh and OLSR
*********************
Posted: Wed Jun 30, 2004 23:24
I whole heartedly agree with PatchesJ. The satori and alchemy distributions are excellent and supply the hotspot folks with wifi in a box but a mesh box would satisfy more of a community based market where users just want to plug in and go.
A beautiful arrangement would be alchemy as your gateway and mesh nodes for your clients or for broader cell coverage.
I'd love to see just a barebones mesh box!
*************************
See the following local link for all the posts to the forum
Sveasoft discussion on mesh
seamless wifi VoIP handover
Picked this up on the Sveasoft forum
we have several hundred APs connected wirelessly covering an entire city with a seamless mobile network. These are all on the same SSID (non routed) and we can seamlessly roam everywhere up to about 55mph. We can do mobile VoIP with only a slight delay as the handoffs occur, but no calls are dropped.
more info on the city we covered is here: otawawireless
we have several hundred APs connected wirelessly covering an entire city with a seamless mobile network. These are all on the same SSID (non routed) and we can seamlessly roam everywhere up to about 55mph. We can do mobile VoIP with only a slight delay as the handoffs occur, but no calls are dropped.
more info on the city we covered is here: otawawireless
Wireless community networks around the world
Wireless community network - Wikipedia, the free encyclopedia
Now we just need to see an entry for Africa in there
Now we just need to see an entry for Africa in there
Sunday, September 05, 2004
Thursday, September 02, 2004
Wednesday, September 01, 2004
Community Owned Information Network
Good link if you want to do IP forwarding between a private network (10.x.x.x or 192.168.x.x) and the internet
How to setup a router on linux
How to setup a router on linux
Friday, August 27, 2004
Tuesday, August 17, 2004
My experience getting shell prompt on Linksys WRT54G
This amazing little cheap wireless router can be customized with a new version of linux or extra user applications by making use of a PING backdoor. The PING backdoor allows you to send commands to the box through a PING diagnostic command running from its httpd service.
Step 1:
Get the box connected your computer by plugging the supplied ethernet cable into a free network port on your PC and one of the 4 network ports on the Linksys (Not the port which is called internet)
Step 2:
Make sure the port you are using on your PC has DHCP enabled. Your machine will be given an IP address in the range 192.168.1.x. The Linksys is always 192.168.1.1 by default. Try to ping the Linksys box
#ping 192.168.1.1
Step 3:
Open a web browser (make sure your proxy is turned off or set a proxy exception for 192.168.1.1). Open the Linksys web administration page opening the following URL
http://192.168.1.1
Browse around here and check some its cool features.
Step 4:
Now it's time to test out the PING backdoor:
Go to the Administration - Diagnostic screen and click on PING
In the box "IP Address or Domain Name:", type
'ls>tmp/ping.log"
Wow - who would have thought you can execute commands on the box using PING - this backdoor will be exploited later to access the box and upload programs to it.
Step 5:
Download and configure the batbox installation
Batbox site (seems to be problem with dns at the moment)
Local site (alternative location)
Unzip this with
# gunzip < wrt54g-0.51.tar.gz.tar | tar xvf -
Look at the README file
Edit the script wrt54g.sh and make the following changes
PASSWORD=admin
If you have java installed you can leave the script as is If you don't have java but you do have wget installed uncomment the lines
# PROGRAM="wget --quiet ....
# EXTRA="" ....
if you don't have wget or java installed make sure you install these If you are using cygwin: MAke sure ttcp is installed and copy the ttcp program from /usr/bin to the current wrt54g directory
Step 6:
Execute the script # ./wrt54g.sh After the script executes, you should be able to telnet to the box # telnet 192.168.1.1
The script also installs a new page on the web server, access it by going to the following URL
http://192.168.1.1:8000/
Step 7:
Get the cross compiler tools for MIPS from
Batbox site
and start compiling and testing your own applications ...
soon to follow - instructions and transferring your own application - will be based on the batbox script
Step 1:
Get the box connected your computer by plugging the supplied ethernet cable into a free network port on your PC and one of the 4 network ports on the Linksys (Not the port which is called internet)
Step 2:
Make sure the port you are using on your PC has DHCP enabled. Your machine will be given an IP address in the range 192.168.1.x. The Linksys is always 192.168.1.1 by default. Try to ping the Linksys box
#ping 192.168.1.1
Step 3:
Open a web browser (make sure your proxy is turned off or set a proxy exception for 192.168.1.1). Open the Linksys web administration page opening the following URL
http://192.168.1.1
Browse around here and check some its cool features.
Step 4:
Now it's time to test out the PING backdoor:
Go to the Administration - Diagnostic screen and click on PING
In the box "IP Address or Domain Name:", type
'ls>tmp/ping.log"
Wow - who would have thought you can execute commands on the box using PING - this backdoor will be exploited later to access the box and upload programs to it.
Step 5:
Download and configure the batbox installation
Batbox site (seems to be problem with dns at the moment)
Local site (alternative location)
Unzip this with
# gunzip < wrt54g-0.51.tar.gz.tar | tar xvf -
Look at the README file
Edit the script wrt54g.sh and make the following changes
PASSWORD=admin
If you have java installed you can leave the script as is If you don't have java but you do have wget installed uncomment the lines
# PROGRAM="wget --quiet ....
# EXTRA="" ....
if you don't have wget or java installed make sure you install these If you are using cygwin: MAke sure ttcp is installed and copy the ttcp program from /usr/bin to the current wrt54g directory
Step 6:
Execute the script # ./wrt54g.sh After the script executes, you should be able to telnet to the box # telnet 192.168.1.1
The script also installs a new page on the web server, access it by going to the following URL
http://192.168.1.1:8000/
Step 7:
Get the cross compiler tools for MIPS from
Batbox site
and start compiling and testing your own applications ...
soon to follow - instructions and transferring your own application - will be based on the batbox script
Friday, August 13, 2004
Ad hoc protocol list - Wikipedia, the free encyclopedia
Full list of all ad-hoc protocols - scary if we need to work through all of these
Ad hoc protocol list - Wikipedia, the free encyclopedia
Ad hoc protocol list - Wikipedia, the free encyclopedia
Tuesday, August 10, 2004
DAKnet a wireless store and forward solution in India
Interesting way of getting access to rural areas without the use of fixed access points. Information is stored and forwarded when the mobile access point vehicle drives past.
Media Lab Asia -- Research
Media Lab Asia -- Research
Monday, August 09, 2004
Mesh, IP allocation and IP Routing
One of the ourstganding issues amongst the mesh gurus is the issue of IP allocation. The general approach is to assign each person in the mesh a staic Ip in the 10.x.x.x or 192.168.x.x range. The ideal is to give everyone a generic box - they install it, turn it on, and it automatically gets assigned an IP, updates it's routing table based on the mesh routing algorithm being used, gets a gateway and a dns (basically like DHCP)
Here is a discussion about handing out IP's between networked PC's with multiple hops
[BAWUG] Mesh, IP allocation and IP Routing
Here is a discussion about handing out IP's between networked PC's with multiple hops
[BAWUG] Mesh, IP allocation and IP Routing
Wireless community network - definition
Good definitition with complete list of wireless community network activities in North Ameria, Europe and Australia
Wireless community network - Wikipedia, the free encyclopedia
Wireless community network - Wikipedia, the free encyclopedia
MIT mesh networking home pages
This describes their grid project
The Grid Ad�Hoc Networking Project
This describes their outdoor rooftop network
MIT Rooftop
Let's download their software and test it
MIT software
The Grid Ad�Hoc Networking Project
This describes their outdoor rooftop network
MIT Rooftop
Let's download their software and test it
MIT software
Setting up a Linux machine to become an access point
1. Make sure you install dhcpd off the Mandrake disks
2. Put the Wireless card into access point mode with the following example script /etc/sysconfig/network-scripts/ifcfg-wifi0
DEVICE=wifi0
BOOTPROTO=static
IPADDR=192.168.0.1
ONBOOT=yes
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
DHCP_TIMEOUT=5
WIRELESS_MODE=Master
WIRELESS_ESSID=mesh
WIRELESS_CHANNEL=10
3. run ifup wifi0
4. copy /etc/dhcpd.conf.sample (this file only exisits the first time you install dhcpd) to dhcpd.conf ... Change the IP address allocations in this file to suite your needs
5. start dhcpd with /etc/rc.d/init.d/dhcpd
6. Check the /var/lib/dhcpd/dhcpd.leases to check which IP addresses are being assigned
2. Put the Wireless card into access point mode with the following example script /etc/sysconfig/network-scripts/ifcfg-wifi0
DEVICE=wifi0
BOOTPROTO=static
IPADDR=192.168.0.1
ONBOOT=yes
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
DHCP_TIMEOUT=5
WIRELESS_MODE=Master
WIRELESS_ESSID=mesh
WIRELESS_CHANNEL=10
3. run ifup wifi0
4. copy /etc/dhcpd.conf.sample (this file only exisits the first time you install dhcpd) to dhcpd.conf ... Change the IP address allocations in this file to suite your needs
5. start dhcpd with /etc/rc.d/init.d/dhcpd
6. Check the /var/lib/dhcpd/dhcpd.leases to check which IP addresses are being assigned
Sunday, August 08, 2004
Setting up the SANOA card in linux
1. Download the hostap driver from ftp://edna.icomtek.csir.co.za/pub/drivers ... This driver ensures that the SANOA card can run in Access point mode as well as Ad-Hoc and Infrastructure
2. Unzip using gunzip < hostap-driver-0.2.4.tar.gz | tar xvf -
3. Change Makefile to include KERNEL_PATH ... KERNEL_PATH=/usr/src/linux
4. Run 'make'
5. run 'make install'
6. Restart card manager using /etc/rc.d/init.d/pcmcia restart
If you are using the PCI to PCMCIA bridge card with the RLSC475 chipset follow these steps
1. Edit the file /etc/sysconfig/pcmcia to include these lines
PCMCIA=yes
PCIC=RLSC475
2. Run /etc/rc.d/init.d/pcmcia restart
2. Unzip using gunzip < hostap-driver-0.2.4.tar.gz | tar xvf -
3. Change Makefile to include KERNEL_PATH ... KERNEL_PATH=/usr/src/linux
4. Run 'make'
5. run 'make install'
6. Restart card manager using /etc/rc.d/init.d/pcmcia restart
If you are using the PCI to PCMCIA bridge card with the RLSC475 chipset follow these steps
1. Edit the file /etc/sysconfig/pcmcia to include these lines
PCMCIA=yes
PCIC=RLSC475
2. Run /etc/rc.d/init.d/pcmcia restart
Linux network configurations tips
Linux network configuration
1. Setting IP address and modes of interface
The file /etc/sysconfig/network-scripts/ifcfg-eth0 contains all the settingsfor interface eth0 including
IP allocation type (static or dynamic)
IP Address
Subnet mask
Broadcast address
Wireless mode
wireless channel
type
# man ifcfg
to see all the options for this config file
Use
# ifup eth0
to bring eth0 network interface up using the script ifcfg-eth0
#ifdown eth0
to pull the eth0 interface down
2. The DNS nameserver
The file /etc/resolve.conf contains the nameserver (dns) to use for the network
3. The gateway and other network routes
To see the current network routes type
# route
This will show you all the routes which the network is currently using
To add a new route for interface eth0 type
# route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0
This adds a route to the network 10.0.0.0 using device eth0
# route add default gw 10.0.0.8
Adds a default route which will be used if no other route matches.
There should be an existing route, in this case, to 10.0.0.8 through some interface.
1. Setting IP address and modes of interface
The file /etc/sysconfig/network-scripts/ifcfg-eth0 contains all the settingsfor interface eth0 including
IP allocation type (static or dynamic)
IP Address
Subnet mask
Broadcast address
Wireless mode
wireless channel
type
# man ifcfg
to see all the options for this config file
Use
# ifup eth0
to bring eth0 network interface up using the script ifcfg-eth0
#ifdown eth0
to pull the eth0 interface down
2. The DNS nameserver
The file /etc/resolve.conf contains the nameserver (dns) to use for the network
3. The gateway and other network routes
To see the current network routes type
# route
This will show you all the routes which the network is currently using
To add a new route for interface eth0 type
# route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0
This adds a route to the network 10.0.0.0 using device eth0
# route add default gw 10.0.0.8
Adds a default route which will be used if no other route matches.
There should be an existing route, in this case, to 10.0.0.8 through some interface.
Good wireless and networking to install off the Mandrake CD's - and some install tips
1. Kismet: An 802.11 network sniffer and network detecter
Common applications Kismet is useful for:
- Wardriving: Mobile detection of wireless networks, logging and mapping
of network location, WEP, etc.
- Site survey: Monitoring and graphing signal strength and location.
- Distributed IDS: Multiple Remote Drone sniffers distributed throughout
an installation monitored by a single server, possibly combined with a
layer3 IDS like Snort.
- Rogue AP Detection: Stationary or mobile sniffers to enforce site policy
against rogue access points.
Setup tips
Make sure you set up the following in /etc/kismet.conf or they may be in /usr/local/etc/kismet.conf
1. Setup the target suiduser: eg. suiduser=djohnson
2. Setup the capture sources using the 'source' directive: eg. source=hostap_prism2,wifi0,david (this works for the SANOA cards)
Change to root
run kismet_monitor to put the wifi card into monitor mode
run kismet
When you are finished using kismet
run kismet_unmonitor to put the wifi card back into it's previous mode
2. Ethereal: A network traffic analyser - this is used to view the network packet dumps produced by Kismet
3. Etherape: A graphical network viewer
Common applications Kismet is useful for:
- Wardriving: Mobile detection of wireless networks, logging and mapping
of network location, WEP, etc.
- Site survey: Monitoring and graphing signal strength and location.
- Distributed IDS: Multiple Remote Drone sniffers distributed throughout
an installation monitored by a single server, possibly combined with a
layer3 IDS like Snort.
- Rogue AP Detection: Stationary or mobile sniffers to enforce site policy
against rogue access points.
Setup tips
Make sure you set up the following in /etc/kismet.conf or they may be in /usr/local/etc/kismet.conf
1. Setup the target suiduser: eg. suiduser=djohnson
2. Setup the capture sources using the 'source' directive: eg. source=hostap_prism2,wifi0,david (this works for the SANOA cards)
Change to root
run kismet_monitor to put the wifi card into monitor mode
run kismet
When you are finished using kismet
run kismet_unmonitor to put the wifi card back into it's previous mode
2. Ethereal: A network traffic analyser - this is used to view the network packet dumps produced by Kismet
3. Etherape: A graphical network viewer
MeshDynamics--High Performance Mesh Networks for HotZones and Metro
This company claims that only their proprietry mesh network (Structured Mesh) can create useable city wide mesh networks.
MeshDynamics--High Performance Mesh Networks for HotZones and Metro
MeshDynamics--High Performance Mesh Networks for HotZones and Metro
Daily Wireless - Ugly truth about mesh networks
This is why it is so important to build a real experimental mesh network which will be tested under high usage situations
Read the first argument and the counter-arguments to get the whole picture in this article
Daily Wireless - Ugly truth about mesh networks
Read the first argument and the counter-arguments to get the whole picture in this article
Daily Wireless - Ugly truth about mesh networks
Wednesday, August 04, 2004
IP addresses for the office mesh
It appears that we need to use static IP addresses for the mobile mesh network. For Computers in Building 43 - here are the current IP address assignments
Anyone that wants to become part of the mesh must contact me for an IP address
10.0.0.2 - Lawrence: Free-BSD machine 1
10.0.0.3 - Lawrence: Mandrake Linux machine 2
10.0.0.4 - Andrew: Mandrake Linux machine
10.0.0.5 - David: Edna Mandrake Linux machine (can be used as a gateway)
10.0.0.6 - David: Mandrake Linux laptop
10.0.0.7 - Andrew/Kim: Debian Linux Digital doorway machine
10.0.0.3 - Lawrence: Mandrake Linux machine 2
10.0.0.4 - Andrew: Mandrake Linux machine
10.0.0.5 - David: Edna Mandrake Linux machine (can be used as a gateway)
10.0.0.6 - David: Mandrake Linux laptop
10.0.0.7 - Andrew/Kim: Debian Linux Digital doorway machine
10.0.0.8 - Albert: Laptop Windows machine
10.0.0.9 - David/Kim: Norbit Mandrake Linux machine
10.0.0.10 - Kim: Desktop Windows machine
10.0.0.11 - Ajay: Desktop windows machine
10.0.0.12 - Yusuf: Desktop windows machine
10.0.0.13 - Andrew: Desktop windows machine
10.0.0.9 - David/Kim: Norbit Mandrake Linux machine
10.0.0.10 - Kim: Desktop Windows machine
10.0.0.11 - Ajay: Desktop windows machine
10.0.0.12 - Yusuf: Desktop windows machine
10.0.0.13 - Andrew: Desktop windows machine
Anyone that wants to become part of the mesh must contact me for an IP address
Monday, August 02, 2004
Sunday, August 01, 2004
Radio theory and link planning for Wireless LAN (WLAN) - good summary
Radio theory and link planning for Wireless LAN (WLAN)
Everyone should know the free space loss equation in their head
Loss [ dB] = 32.44 + 20(Log(distance[km]) + Log(freq[MHz]))
Useful cable losses
RG58 = 1 dB/m
RG213 = -.6 dB/m
RG174 = 2 dB/m (often used in pigtails)
LMR-400 = 0.22 dB/m
Typical WiFi sensitivity for orinoco cards
11Mbps = -82dBm
5.5Mbps = -87dBm
2Mbps = -92dBm
1Mbps = -94dBm
Typical allowed signal to noise ratios for orinoco cards
11Mbps = 16dB
5.5Mbps = 11dB
2Mbps = 7dB
1Mbps = 4dB
Typical Noise level at 2.4GHz = -100dBm. Compute S/N level eg. at 11Mbps = -84dBm but sensitivity is -82dBm so sensitivity is the limiting factor.
Just worked out that with our 2 8dBi omnis, 2dB loss in the RF cable each side of the link and the 200mW SANOA cards it is possible to acheive a theoretical distance of 5km with a 3dB margin (margin probably a bit tight), 4km will give you a 5dB margin - probably more realistic.
Everyone should know the free space loss equation in their head
Loss [ dB] = 32.44 + 20(Log(distance[km]) + Log(freq[MHz]))
Useful cable losses
RG58 = 1 dB/m
RG213 = -.6 dB/m
RG174 = 2 dB/m (often used in pigtails)
LMR-400 = 0.22 dB/m
Typical WiFi sensitivity for orinoco cards
11Mbps = -82dBm
5.5Mbps = -87dBm
2Mbps = -92dBm
1Mbps = -94dBm
Typical allowed signal to noise ratios for orinoco cards
11Mbps = 16dB
5.5Mbps = 11dB
2Mbps = 7dB
1Mbps = 4dB
Typical Noise level at 2.4GHz = -100dBm. Compute S/N level eg. at 11Mbps = -84dBm but sensitivity is -82dBm so sensitivity is the limiting factor.
Just worked out that with our 2 8dBi omnis, 2dB loss in the RF cable each side of the link and the 200mW SANOA cards it is possible to acheive a theoretical distance of 5km with a 3dB margin (margin probably a bit tight), 4km will give you a 5dB margin - probably more realistic.
Tuesday, July 27, 2004
Mobile Ad-hoc Networks home page at the IETF
Mobile Ad-hoc Networks (manet) Charter
All COINers should study these protocols
Internet-Drafts:
The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)
Request For Comments:
Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (RFC 2501)
Ad Hoc On Demand Distance Vector (AODV) Routing (RFC 3561)
Optimized Link State Routing Protocol (OLSR) (RFC 3626)
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (RFC 3684)
All COINers should study these protocols
Internet-Drafts:
The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)
Request For Comments:
Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (RFC 2501)
Ad Hoc On Demand Distance Vector (AODV) Routing (RFC 3561)
Optimized Link State Routing Protocol (OLSR) (RFC 3626)
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (RFC 3684)
Detailed info on the Linksys Wrt54g
Info on LinksysWrt54g - SeattleWireless
Hardware onboard V 1.0
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: [WWW]AMD AM29LV320DB-90EI, a 32Mbit chip (4MB)
CPU: [WWW]Broadcom BCM4702KPB, with a 125MHz MIPS and two 10/100 Ethernet controllers
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
version 1.0: Mini PCI slot with Linksys/Broadcom radio FCC ID PKW-WM54G, dual Hirose antenna connectors
version 1.1: has the wireless integrated on the mainboard
Version 2.0:
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: Intel TE28F320 C3 flash 32Mbit chip (4MB)
CPU: Broadcom [WWW]BCM4712KPB, running at 200MHz
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
Wireless: On board; Broadcom BCM2050KWL
Some alternative operating systems available
OpenWrt
Batbox
Talk of installing this mesh protocol on OpenWrt
OLSR
Hardware onboard V 1.0
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: [WWW]AMD AM29LV320DB-90EI, a 32Mbit chip (4MB)
CPU: [WWW]Broadcom BCM4702KPB, with a 125MHz MIPS and two 10/100 Ethernet controllers
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
version 1.0: Mini PCI slot with Linksys/Broadcom radio FCC ID PKW-WM54G, dual Hirose antenna connectors
version 1.1: has the wireless integrated on the mainboard
Version 2.0:
RAM: 2 x IC42S16400, 64Mbit (4M X 16) RAM chips (16MB)
Flash: Intel TE28F320 C3 flash 32Mbit chip (4MB)
CPU: Broadcom [WWW]BCM4712KPB, running at 200MHz
Ethernet: [WWW]ADMtek ADM6996 5 port 10/100 switch
Wireless: On board; Broadcom BCM2050KWL
Some alternative operating systems available
OpenWrt
Batbox
Talk of installing this mesh protocol on OpenWrt
OLSR
Wednesday, July 21, 2004
Fwd: Patch Antenna?
This may be useful to COIN, not sure....
http://www.rc-cam.com/gp_patch.htm
- Kim
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
http://www.rc-cam.com/gp_patch.htm
- Kim
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
Tuesday, July 13, 2004
Good contact made with Champaign-Urbana community wireless network
Here's their home page
This organisation has also been funded by the IDRC and Johann has made contact with them
On Sat, 10 Jul 2004, Johann Hugo wrote:
> On Wednesday 07 July 2004 23:16, you wrote:
> > tell us something about your background and skillset.
>
> Hi Chase
>
> I am working for the CSIR in South Africa (www.csir.co.za). The CSIR is
> the premier technology and research organisation in Africa.
>
> My area of expertise is mainly in outdoor wifi networks and FreeBSD and
> I've been involved with it since 2000. Most of our projects are around
> bettering the lives of people in rural areas, using state of the art
> technologies. We've won a Stockholm award in both 2000 and 2004 for some of
> the work that we have done. Here are some links of the stuff I've been
> involved with: http://www.cda.co.za
> http://www.cda.co.za/Media%20Cache/2000/Technobrief%20June%202000/Technobri
>ef% 20June%202000.htm
> http://www.digitaldoorway.co.za
> http://www.challenge.stockholm.se/feature_index.asp
>
> Our unit started with wireless Lans in about 1998 using Lucent wireless
> cards and Karl Brug software. Later we started using FreeBSD (One of the
> group members are a FreeBSD developer and we are also a mirror site for
> FreeBSD in South Africa). Our current wifi systems are mostly green soekris
> boxes running FreeBSD (I think we were one of soekris first clients). We've
> set up a couple of wifi networks and we are running voice, video and data
> over these networks.
Excellent! It would appear our groups have much in common.
> One of our latest activities is to change our current network and to set up
> an experimental wifi mesh network with about 25 nodes in the Pretoria area.
> Once this is up and running there will be followups where we install mesh
> networks (+ training ) into some rural areas.
>
> Our group are currently looking at mobilemesh that runs on Linux. Some of
> members of the team are busy trying to port it to FreeBSD. See link to our
> blog spot (some of the team ony use our wifi):
> http://CSIRCOIN.BlogSpot.com/
Interesting. I'll make sure people on our team see this.
> I had a look on your website and are very interested in your system. I've
> downloaded your images and made a bootable CD + burnt a flash for a soekris
> box. I can boot the images, but I cannot log in as root and change
> settings.
>
> Some questions:
> May we know the root password for your images ?
From what I understand, the root password in the images on the website is
currently nothing which locks the system from root logins. If you
download the upgrade tarball you can take a look at the system image
itself.
At this time we recommend you set up a development environment and build
an ISO image if you wish to preconfigure it with a specific root password.
We plan to add some scripts which makes configuring aspects of an image
possible without a complete development environment.
I'll be happy to help you in setting up that development environment, as
well.
> Are your source code open source ?
Yes. Our code is covered by a BSD-variant license. You can find a sample
of that license at:
http://www.cuwireless.net/faq.html#software-license
> Are HSLS and ETX running on your current system ?
A three-part answer:
* Not in the images on the website taken on May 11, 2004.
* Yes in the images on our source code trunk, but HSLS and ETX are not
affecting the route tables, only running to measure that they are
working as expected.
* Yes in our next release, tentatively scheduled for the fourth week of
July, but, again not affecting the route tables.
Until HSLS and ETX are completely turned on, we are using OSPF.
> May we try to port your code to FreeBSD ?
> (We prefer FreeBSD to NetBSD because of our expertise with FreeBSD)
We welcome ports! I hear that a port to FreeBSD should be easy compared
to some other platforms.
> Do you plan a Linux port as well ?
> (Some of the group are Linux users)
Porting the software to run on Linux would probably take some work. We're
not certain if/when we'll get around to it. The biggest API differences
are, from what I understand, in the IPv4/IPv6 parts of the networking
system.
We think that the first step for CUWiN on Linux is to build the software
with NetBSD as the target platform. I, for one, am interested in doing
this as my main systems are all Linux. No ETA on when it will happen,
though. Of course, we'd welcome any assistance you or your team has to
offer.
We're very excited about the prospect of working together, especially in
light of the recent IDRC grants given to wireless groups in Africa.
Chase
This organisation has also been funded by the IDRC and Johann has made contact with them
On Sat, 10 Jul 2004, Johann Hugo wrote:
> On Wednesday 07 July 2004 23:16, you wrote:
> > tell us something about your background and skillset.
>
> Hi Chase
>
> I am working for the CSIR in South Africa (www.csir.co.za). The CSIR is
> the premier technology and research organisation in Africa.
>
> My area of expertise is mainly in outdoor wifi networks and FreeBSD and
> I've been involved with it since 2000. Most of our projects are around
> bettering the lives of people in rural areas, using state of the art
> technologies. We've won a Stockholm award in both 2000 and 2004 for some of
> the work that we have done. Here are some links of the stuff I've been
> involved with: http://www.cda.co.za
> http://www.cda.co.za/Media%20Cache/2000/Technobrief%20June%202000/Technobri
>ef% 20June%202000.htm
> http://www.digitaldoorway.co.za
> http://www.challenge.stockholm.se/feature_index.asp
>
> Our unit started with wireless Lans in about 1998 using Lucent wireless
> cards and Karl Brug software. Later we started using FreeBSD (One of the
> group members are a FreeBSD developer and we are also a mirror site for
> FreeBSD in South Africa). Our current wifi systems are mostly green soekris
> boxes running FreeBSD (I think we were one of soekris first clients). We've
> set up a couple of wifi networks and we are running voice, video and data
> over these networks.
Excellent! It would appear our groups have much in common.
> One of our latest activities is to change our current network and to set up
> an experimental wifi mesh network with about 25 nodes in the Pretoria area.
> Once this is up and running there will be followups where we install mesh
> networks (+ training ) into some rural areas.
>
> Our group are currently looking at mobilemesh that runs on Linux. Some of
> members of the team are busy trying to port it to FreeBSD. See link to our
> blog spot (some of the team ony use our wifi):
> http://CSIRCOIN.BlogSpot.com/
Interesting. I'll make sure people on our team see this.
> I had a look on your website and are very interested in your system. I've
> downloaded your images and made a bootable CD + burnt a flash for a soekris
> box. I can boot the images, but I cannot log in as root and change
> settings.
>
> Some questions:
> May we know the root password for your images ?
From what I understand, the root password in the images on the website is
currently nothing which locks the system from root logins. If you
download the upgrade tarball you can take a look at the system image
itself.
At this time we recommend you set up a development environment and build
an ISO image if you wish to preconfigure it with a specific root password.
We plan to add some scripts which makes configuring aspects of an image
possible without a complete development environment.
I'll be happy to help you in setting up that development environment, as
well.
> Are your source code open source ?
Yes. Our code is covered by a BSD-variant license. You can find a sample
of that license at:
http://www.cuwireless.net/faq.html#software-license
> Are HSLS and ETX running on your current system ?
A three-part answer:
* Not in the images on the website taken on May 11, 2004.
* Yes in the images on our source code trunk, but HSLS and ETX are not
affecting the route tables, only running to measure that they are
working as expected.
* Yes in our next release, tentatively scheduled for the fourth week of
July, but, again not affecting the route tables.
Until HSLS and ETX are completely turned on, we are using OSPF.
> May we try to port your code to FreeBSD ?
> (We prefer FreeBSD to NetBSD because of our expertise with FreeBSD)
We welcome ports! I hear that a port to FreeBSD should be easy compared
to some other platforms.
> Do you plan a Linux port as well ?
> (Some of the group are Linux users)
Porting the software to run on Linux would probably take some work. We're
not certain if/when we'll get around to it. The biggest API differences
are, from what I understand, in the IPv4/IPv6 parts of the networking
system.
We think that the first step for CUWiN on Linux is to build the software
with NetBSD as the target platform. I, for one, am interested in doing
this as my main systems are all Linux. No ETA on when it will happen,
though. Of course, we'd welcome any assistance you or your team has to
offer.
We're very excited about the prospect of working together, especially in
light of the recent IDRC grants given to wireless groups in Africa.
Chase
Some more useful mesh info
Complete list of mesh protocols - Wiki site
Desciprion of protcols being used at CU wireless
To sustain the scalability of its infrastructure, Community
Wireless Network needs software that implements an uncomplicated,
extensible routing protocol that will support a network of
hundreds of nodes, and a routing path metric that "prefers"
reliable, high-capacity routes to spotty, low-capacity routes.
Based on a review of the wireless networking literature, BBN
Technologies' Hazy Sighted Link State (HSLS) routing algorithm
will support growth to thousands of nodes, which will more than
meet our requirements. HSLS also admits a parsimonious
implementation that will be far easier for a grassroots project
to debug and extend than more complicated algorithms whose
scalability is comparatively poor. The Expected Transmission
Count (ETX) path metric is a simple, proven routing path metric
that favors high-capacity, reliable links. The Community
Wireless Network will develop a UNIX routing daemon implementing
HSLS and ETX. The major functional units of the daemon are
described below.
CWN will leverage existing open source software whenever that
is possible. For example, the Zebra routing software suite
will provide our Routing Information Base (RIB) and kernel
abstraction. Because we will re-use Zebra, we will save tens
of hours of development and debugging, we will gain some
inter-operating system portability (*BSD, Linux, Solaris), and
we will have the capability to extend our HSLS daemon to share
routes with other routing protocols (BGP, OSPF, and RIP) in
the future.
More detailed description of HSLS
More detailed descrtiption of ETX
Desciprion of protcols being used at CU wireless
To sustain the scalability of its infrastructure, Community
Wireless Network needs software that implements an uncomplicated,
extensible routing protocol that will support a network of
hundreds of nodes, and a routing path metric that "prefers"
reliable, high-capacity routes to spotty, low-capacity routes.
Based on a review of the wireless networking literature, BBN
Technologies' Hazy Sighted Link State (HSLS) routing algorithm
will support growth to thousands of nodes, which will more than
meet our requirements. HSLS also admits a parsimonious
implementation that will be far easier for a grassroots project
to debug and extend than more complicated algorithms whose
scalability is comparatively poor. The Expected Transmission
Count (ETX) path metric is a simple, proven routing path metric
that favors high-capacity, reliable links. The Community
Wireless Network will develop a UNIX routing daemon implementing
HSLS and ETX. The major functional units of the daemon are
described below.
CWN will leverage existing open source software whenever that
is possible. For example, the Zebra routing software suite
will provide our Routing Information Base (RIB) and kernel
abstraction. Because we will re-use Zebra, we will save tens
of hours of development and debugging, we will gain some
inter-operating system portability (*BSD, Linux, Solaris), and
we will have the capability to extend our HSLS daemon to share
routes with other routing protocols (BGP, OSPF, and RIP) in
the future.
More detailed description of HSLS
More detailed descrtiption of ETX
Monday, July 12, 2004
Fwd: ZDNet UK: Open-source Wi-Fi links remote communities
> Open-source Wi-Fi links remote communities
>
>
>
> Andrew Donoghue
>
>
>
>
>
> European wireless and open-source specialists have embarked on an
> international tour to spread the benefits of the technology to
> developing
> countries from Tajikistan to Ghana.
>
> The team, known as Informal, claims its wireless roadshow is an
> attempt to
> empower non-governmental organisations (NGOs) in the developing world
> to own,
> operate and grow their own Internet infrastructure using wireless
> technology
> such as mesh networking. The aim is to allow remote communities in
> developing
> countries without traditional telecoms infrastructure to communicate
> more
> effectively.
>
> "We support these kinds of activities because we believe that the
> benefits of
> the Internet should be available globally," said Informal lead team
> member
> Simon Crab.
>
> While a lot of attention has been focused on bridging the digital
> divide and
> providing Internet access to remote areas, Informal claims to be
more
> concerned with allowing local communities to exchange information
with
> each
> other -- spreading local knowledge. "In each country, we will work
> primarily
> with local NGOs to assist them in building, maintaining and extending
> their
> own networks in areas that are under-served by telecommunication
> infrastructure," said Crab.
>
> The Informal team recently arrived in Tajikistan where it will remain
> for
> next three months before moving onto Ghana, Nepal, the Philippines,
> China and
> finally India.
>
> Existing examples of wireless technology projects in the developing
> world
> include DakNet and First Mile Solutions in Cambodia and the Jhai
> Foundation's
> Remote IT Village Project in Laos.
>
> Informal plans to use emerging wireless mesh technology to create
> cheap,
> robust connections in remote areas that do not have an established
> telecoms
> infrastructure. Each device on a mesh network receives and transmits
> its own
> traffic, while acting as a router for other devices; intelligence in
> each
> device allows it to automatically configure an efficient network, and
> to
> adjust if, for example, a node becomes overloaded or unavailable.
The
> advantages include ease of set-up, the ability to spread wireless
> access over
> a wide area from a single central wired connection, and the inherent
> toughness of such networks.
>
> Key to the Informal project is the development of a blueprint for a
> low-cost,
> wireless, rugged computing device which Informal will encourage the
> NGOs to
> develop and build. The so-called Autonokit will essentially be a
> low-cost
> computer that can work on non-standard power sources such as solar,
> wind,
> micro-hydro or even bicycle power.
>
> The Autonokit will run an open-source Linux or BSD distribution
> optimised for
> networking and auto configuration. It will be equipped with a 12V
> battery in
> case of power cuts, low wind or a fuel shortage.
>
> In an article written for CNET, UN secretary-general Kofi Annan
> spelled out
> the potential benefits that wireless and other technologies could
> bring to
> the developing world.
>
> "We need to think of ways to bring wireless fidelity (Wi-Fi)
> applications to
> the developing world, so as to make use of unlicensed radio spectrum
to
> deliver cheap and fast Internet access," he said.
>
> While providing developing communities with access to information is
> one of
> the main motivations behind the road-show, Crab -- whose
day
> job is
> at digital consultancy Lateral -- claims Informal's
> motivations are
> not purely altruistic. "A side effect of these projects is that it
> keeps us
> in touch with technical and creative developments in areas most
> companies
> don't look at, it keeps our roots in the real world," he said.
>
> Crab admitted that providing open access to information in some
> countries
> could be politically sensitive but he claimed that there is a lot of
> misleading information circulated about some countries approach
> controlling
> Internet access. "You have to be very careful about how you approach
> it but
> there are a lot of myths about countries such as China -- they
> actually have
> very free access compared to some places," he said.
>
> China has been heavily criticised by organisations such as Amnesty
> International for its attempts to censor Internet traffic and
> imprisoning
> several individuals for Internet-related crimes.
>
>
>
>
-----------------------------------------------------------------------
> -
>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
Wednesday, July 07, 2004
I sent this using an email address...
You can too, by going to www.blogger.com , selecting Community Owned...,
going to the settings...emails and entering an email address for u to
use for your posts!
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
going to the settings...emails and entering an email address for u to
use for your posts!
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
Wednesday, June 30, 2004
The Meshcube
Here is another piece of hardware to add to our list
Advantages: Packaged mesh product
Disadvantages: Price - 1 Unit costs 199 Euros, more than double the Linksys box
FrontPage - The Mesh(cube) Wiki
For picture and specs
meshcube.org - the meshing community website
For prices
PDF with prices of kits and bits and pieces
Advantages: Packaged mesh product
Disadvantages: Price - 1 Unit costs 199 Euros, more than double the Linksys box
FrontPage - The Mesh(cube) Wiki
For picture and specs
meshcube.org - the meshing community website
For prices
PDF with prices of kits and bits and pieces
Friday, June 25, 2004
Setting up mobile mesh on Mandrake Linux
1. Download the source code and read documentation
This can be found here
Mobile mesh information
You need to download iproute2, GraphViz and MobileMesh
You can also find a local copy at
edna ftp server
2. Make sure that you are using g++ 2.96 compiler and libraries
Remove with RpmDrake
libstdc++5-devel-3.2.2-3mdk
gcc-c++-3.2.2-3mdk
Install using RpmDrake
libstdc++2.10-devel-2.96-0.82mdk
gcc2.96-c++-2.96-0.82mdk
3. Unzip, compile and install graphviz, iproute2 and mobilemesh
eg. for mobile mesh
gunzip < mobilemesh-1.0.tar.gz | tar xvf -
cd mobilemesh-1.0
make depends
make
su to root
make install
4. Read the documentation for mobile mesh to learn how to use it
mmdiscover
mmrp
mmborder
mmrpvizr
This can be found here
Mobile mesh information
You need to download iproute2, GraphViz and MobileMesh
You can also find a local copy at
edna ftp server
2. Make sure that you are using g++ 2.96 compiler and libraries
Remove with RpmDrake
libstdc++5-devel-3.2.2-3mdk
gcc-c++-3.2.2-3mdk
Install using RpmDrake
libstdc++2.10-devel-2.96-0.82mdk
gcc2.96-c++-2.96-0.82mdk
3. Unzip, compile and install graphviz, iproute2 and mobilemesh
eg. for mobile mesh
gunzip < mobilemesh-1.0.tar.gz | tar xvf -
cd mobilemesh-1.0
make depends
make
su to root
make install
4. Read the documentation for mobile mesh to learn how to use it
mmdiscover
mmrp
mmborder
mmrpvizr
Wednesday, June 23, 2004
The African WiFi Summit 2004
This is an important summit on WiFi in south Africa
The African WiFi Summit 2004 - Registration
The African WiFi Summit 2004 - Registration
Wednesday, June 16, 2004
A possible way to legalise WiFi access
South Africa has a telecommunications act which specifically covers the use of amateur radio and includes the frequencies being used for wifi: 2 300-2 450 MHz and 5 650-5 850 MHz. Amateur radio is essentially a community owned network which is operated by licenced amateur radio operators. There might be a way to justify a community wireless LAN network as part of an amateur radio network. There are certain rules such as not using the network for business purposes, charging for the service or transmitting music. You also need to a basic proficiency exam, which includes writing morse code at 12 words a minute (ouch!), to become an amateur radio operator.
If you want more details on Amateur Radio regulation in South Africa
ICASA telecommunications act for amateur radio
And more about the National Association for Amateur Radio in South Africa
South African Radio League Home Page
If you want to write the exam
South African Radio League Exam
If you want more details on Amateur Radio regulation in South Africa
ICASA telecommunications act for amateur radio
And more about the National Association for Amateur Radio in South Africa
South African Radio League Home Page
If you want to write the exam
South African Radio League Exam
Tuesday, June 15, 2004
Good references for mesh networking protocols
Nice list of popular mesh protocols currently in use Daily Wireless
Pulbications on mesh/ad-hoc networks
The IETF manet (mobile ad-hoc networks) working group
Someone please try to find the complete archive of all RFC's submitted to the IETF MANET working group
Windows version of the mobile mesh protocol for Linux
Pulbications on mesh/ad-hoc networks
The IETF manet (mobile ad-hoc networks) working group
Someone please try to find the complete archive of all RFC's submitted to the IETF MANET working group
Windows version of the mobile mesh protocol for Linux
The story of Philemon part I
It is twilight on a cold winters evening in Mamelodi east, Philemon has just climbed out of the Taxi in Mandela street when his eye catches a large crowd gathering outside the community hall. A smartly dressed man is holding up all sort of strange gadgets and gesturing to the crowd. Philemon is curious and begins walk closer, on further investigation, he sees that the man is talking about a computer that only costs R300 called the Biko I. He is also waving around some strange thing that looks like a drain pipe which he says will help you to connect to a digital community network called ubuntu-digital. With this, he claims, you can help your children with their schoolwork, look for jobs, Talk to other people in the network for free – no more expensive “pay as you go” cards, get legal advice, send letters to friends and relatives who also have a computers – he says the sky is the limit – you can even think up your own ways of using it to create new business. Philemon takes one of the pamphlets the man is handing out and begins reading it as he walks back to his small RDP house in block E of an area called Sundown valley. He sees that the computer plugs into a normal TV screen – he begins to imagine his children fighting to use the Biko I while he wants to watch the 7PM news, maybe he should pay the extra R200 for a separate colour monitor. He reads over a section on installing the ubuntu-digital network which costs R250 for the equipment and is pleased to see that there will be training every Tuesday at the community centre for people who need help installing it – apparently to bring down the cost you can make your own aerial out of a pringle can. It says that if you can see the community centre mast then you can connect to the network, if you can’t you need to get a neighbour involved who you can see and who can see the community centre mast. He begins to walk quicker now, as the excitement builds and he pictures telling his wife Florrie and 3 children about this exciting new device. He has already started calculating in his head that if he saved R100 a month he could buy the Biko I in 3 months and install the Ubuntu-digital network after 6 months.
What we've got to do to make this happen
Task 1: Build a web site to share information on mesh networking and community owned networks
Outcome: Quick information dissemination amongst interested parties in the FMFI project, CSIR staff and other external interested parties.
Task 2: Build a simulation of a mesh network to test out various routing protocols and congestion control meshanisms
Outcome: A document showing theoretical estimates of how a mesh network will perform under changing load conditions
Task 3: Build home made WiFi antennas - omni-directional and directional and check their performance using tools from Poynting
Outcome: Omni-directional antenna and directional antenna with enough gain for a city wide mesh network
Task 4: Carry out a literature survey on existing mesh networking protocols that can be used in a Linux, FreeBSD environment and Windows environment.
Outcome: A document outlining all the information on protocols and recipes for setting up mesh nodes on Linux, FreeBSD and Windows (not that Windows would be my OS of choice).
Task 5: Test existing mesh protocols such as Locust mesh between 5 or more PC’s running on Linux, FreeBSD and possibly Windows in an office environment.
Outcome: A working indoor mesh network
Task 6: Create a Pretoria mesh network as a testbed for networking in other community networks. This testbed will be used to carry out experiments in the mesh and test the reliability of various protocols.
Outcome: A working city wide mesh network
Task 7: Use a web based GIS system for CSIR staff to become part of the Pretoria mesh and to pinpoint the position of their house and have a link prediction carried out to check line of sight to the next available node.
Outcome: An easy way for staff to check if they can become part of the community mesh
network
Task 8: Research the cheapest method of creating a WiFi access point and build a low cost WiFi AP.
Outcome: A document outlining all the components required to build a low cost WiFi and a working low cost WiFi AP
Task 9: Research low cost PC’s for poor communities and build a prototype based on research.
Outcome: A working low cost PC prototype. A document outlining all the components required to build a low cost PC.
Task 10: Test various existing mesh routing protocols and establish their strengths and weaknesses.
Outcome: Access points or PC’s with a menu which allows a user to select between different mesh protocols. A document describing all the meshing protocols available.
Task 11: Test out various application on the mesh – check their performance versus the number of hops between two hosts. Test performance versus the number of simultaneous running applications e.g. After how many simultaneous VoIP calls does it become unusable.
Peer to peer applications such as Skype
Video streaming with different levels of compression
Standard internet applications such as web browsing and email through the CSIR gateway
Outcome: Document describing the performance of various applications running over the mesh network
Task 12: Connect the mesh network to the Tshwane backbone.
Outcome: test the feasibility of Tshwane building out community mesh networks from their fibre backbone.
Task 13: Create computer based training material which will explain how to set up a mesh network in a community – everything from involving the community, installing an antenna to setting up their operating system.
Outcome: A CD/website with a user manual describing how to build community mesh networks and access points.
Outcome: Quick information dissemination amongst interested parties in the FMFI project, CSIR staff and other external interested parties.
Task 2: Build a simulation of a mesh network to test out various routing protocols and congestion control meshanisms
Outcome: A document showing theoretical estimates of how a mesh network will perform under changing load conditions
Task 3: Build home made WiFi antennas - omni-directional and directional and check their performance using tools from Poynting
Outcome: Omni-directional antenna and directional antenna with enough gain for a city wide mesh network
Task 4: Carry out a literature survey on existing mesh networking protocols that can be used in a Linux, FreeBSD environment and Windows environment.
Outcome: A document outlining all the information on protocols and recipes for setting up mesh nodes on Linux, FreeBSD and Windows (not that Windows would be my OS of choice).
Task 5: Test existing mesh protocols such as Locust mesh between 5 or more PC’s running on Linux, FreeBSD and possibly Windows in an office environment.
Outcome: A working indoor mesh network
Task 6: Create a Pretoria mesh network as a testbed for networking in other community networks. This testbed will be used to carry out experiments in the mesh and test the reliability of various protocols.
Outcome: A working city wide mesh network
Task 7: Use a web based GIS system for CSIR staff to become part of the Pretoria mesh and to pinpoint the position of their house and have a link prediction carried out to check line of sight to the next available node.
Outcome: An easy way for staff to check if they can become part of the community mesh
network
Task 8: Research the cheapest method of creating a WiFi access point and build a low cost WiFi AP.
Outcome: A document outlining all the components required to build a low cost WiFi and a working low cost WiFi AP
Task 9: Research low cost PC’s for poor communities and build a prototype based on research.
Outcome: A working low cost PC prototype. A document outlining all the components required to build a low cost PC.
Task 10: Test various existing mesh routing protocols and establish their strengths and weaknesses.
Outcome: Access points or PC’s with a menu which allows a user to select between different mesh protocols. A document describing all the meshing protocols available.
Task 11: Test out various application on the mesh – check their performance versus the number of hops between two hosts. Test performance versus the number of simultaneous running applications e.g. After how many simultaneous VoIP calls does it become unusable.
Peer to peer applications such as Skype
Video streaming with different levels of compression
Standard internet applications such as web browsing and email through the CSIR gateway
Outcome: Document describing the performance of various applications running over the mesh network
Task 12: Connect the mesh network to the Tshwane backbone.
Outcome: test the feasibility of Tshwane building out community mesh networks from their fibre backbone.
Task 13: Create computer based training material which will explain how to set up a mesh network in a community – everything from involving the community, installing an antenna to setting up their operating system.
Outcome: A CD/website with a user manual describing how to build community mesh networks and access points.
Champaign-Urbana Community Wireless Network
Champaign-Urbana Community Wireless NetworkDownloadable Linux/BSD compatible Mesh bootcd, link supplied by Johan Hugo
Monday, June 07, 2004
Home-Brew Omni-Directional Antennae
Here are some directions for building home-brew Omni Directional Antennae, which seem perfect for COIN
802.11 2.4Ghz Low-Power 5dBi Vertical Collinear Antenna
802.11 2.4Ghz Vertical Collinear Antenna
802.11 2.4Ghz Low-Power 5dBi Vertical Collinear Antenna
Gnet Gateway
Guerrilla.net
An underground alternative to the wired Internet
Nice portal for Wifi Community owned network information. Info on antennae, software, mesh etc.
An underground alternative to the wired Internet
Nice portal for Wifi Community owned network information. Info on antennae, software, mesh etc.
Tuesday, June 01, 2004
FreeNetworks.ORG || Community Networks
FreeNetworks.ORG || Community Networks FreeNetworks.org is a voluntary cooperative association dedicated to education, collaboration, and advocacy of the creation of free digital network infrastructures
Monday, May 31, 2004
Mesh Routing Protocol software
Multi-platform mesh routing software available for
Linux: Mobile Mesh
Windows: IPMesh
Lets give it a try!
Linux: Mobile Mesh
Windows: IPMesh
Lets give it a try!
Subscribe to:
Posts (Atom)