Thanks for all the contributions so far, please feel free to move your Blog postings over to the wiki: http://wirelessafrica.meraka.org.za/wiki/
Ciao!
Tuesday, November 22, 2005
Wednesday, November 16, 2005
New home for CSIR COIN Blog
The information on this Blog is currently being moved to a new home, which will hopefully allow for more interactivity and organisation. A link to the new home will be made available on http://wirelessafrica.meraka.org.za/ when sufficiently populated.
Thursday, October 13, 2005
Best collection of links I've seen for ad hoc networking
http://www.antd.nist.gov/wctg/manet/adhoclinks.html
Wednesday, October 12, 2005
wistron CM9 Altheros MiniPCI card info
Wiki on the Wistron CM9
http://melbourne.wireless.org.au/wiki/?CM9
Latest windows drivers
http://www.phoenixnetworks.net/atheros.php
Product information
http://www.wneweb.com/wireless/products/cm9.htm
http://melbourne.wireless.org.au/wiki/?CM9
Latest windows drivers
http://www.phoenixnetworks.net/atheros.php
Product information
http://www.wneweb.com/wireless/products/cm9.htm
Tuesday, October 11, 2005
Engineering News Article
Its amazing how a simple idea like the cantenna has grabbed the attention of the media. So far I've been interviewed on SABC Africa and by Engineering News (Tin-can bridge to digital society). One would have thought that the technical, innovative stuff we're doing with ad-hoc networking in the larger project would have more interest. I suppose that its easier to grasp the imagination with simplicity.
Sunday, October 02, 2005
Making sense of LQ ILQ and ETX in OLSR
You will see a table like this in the OLSR status screen on Freifunk
LQ = The percentage of packets that are succesfully sent from youself to the neighbour
ILQ = The percentage of packets that succesfully are sent from your neighbour to yourself also often called NLQ
ETX = Expected Trasnmission count = How many trasnmission attempts are required to get packets through = 1 / (LQ*ILQ)
Topology entries
| Destination IP | Last hop IP | LQ | ILQ | ETX |
|---|---|---|---|---|
| 10.51.1.13 | 10.51.1.10 | 1.00 | 1.00 | 1.00 |
| 10.51.1.20 | 10.51.1.10 | 1.00 | 1.00 | 1.00 |
| 10.51.1.1 | 10.51.1.13 | 0.90 | 1.00 | 1.11 |
| 10.51.1.10 | 10.51.1.13 | 1.00 | 1.00 | 1.00 |
| 10.51.1.12 | 10.51.1.13 | 1.00 | 0.90 | 1.11 |
| 10.51.1.14 | 10.51.1.13 | 0.90 | 1.00 | 1.11 |
| 10.51.1.20 | 10.51.1.13 | 1.00 | 1.00 | 1.00 |
| 10.51.1.13 | 10.51.1.14 | 1.00 | 0.90 | 1.11 |
| 10.51.1.1 | 10.51.1.20 | 0.90 | 0.75 | 1.49 |
| 10.51.1.10 | 10.51.1.20 | 1.00 | 1.00 | 1.00 |
| 10.51.1.12 | 10.51.1.20 | 1.00 | 1.00 | 1.00 |
| 10.51.1.13 | 10.51.1.20 | 1.00 | 1.00 | 1.00 |
LQ = The percentage of packets that are succesfully sent from youself to the neighbour
ILQ = The percentage of packets that succesfully are sent from your neighbour to yourself also often called NLQETX = Expected Trasnmission count = How many trasnmission attempts are required to get packets through = 1 / (LQ*ILQ)
Saturday, October 01, 2005
Getting an OpenWRT Freifunk mesh stable
After a lot of tweaking OLSR running on Linksys has had no "ping down" messages for about 5 days now. Some of the tips to getting OLSR on OpenWRT stable.
1. Lock all the nodes to 802.11B don't let it auto sense
2. If there are any v2.2 hardware devices, change the clock speed to 216MHz with the following commands1
# nvram set clkfreq=216
# nvram commit
# reboot
3. Lock the RX and TX antenna to the one you connected your external antenna too, don't use AUTO. TAKE NOTE!!! On Version 2.0 hardware Antenna A is on the left looking from the front of the linksys and and on Version 2.,2 hardware Antenna A is on the right looking from the fron of the linksys. This caught me out a few times.
1. Lock all the nodes to 802.11B don't let it auto sense
2. If there are any v2.2 hardware devices, change the clock speed to 216MHz with the following commands1
# nvram set clkfreq=216
# nvram commit
# reboot
3. Lock the RX and TX antenna to the one you connected your external antenna too, don't use AUTO. TAKE NOTE!!! On Version 2.0 hardware Antenna A is on the left looking from the front of the linksys and and on Version 2.,2 hardware Antenna A is on the right looking from the fron of the linksys. This caught me out a few times.
Monday, September 19, 2005
International Wireless Summit 2005
International Wireless Summit 2005, Aalborg, Denmark
The international wireless summit has just kicked off and I have the privilege of being amongst some of the greatest think-tanks in the wireless arena.
The aim of the IWS is to offer a platform for establishing exchanges of information between universities, industry and science parks. The next summit will be in 2008 in Helsinki, Finland.
International Wireless Symposium aims to exchange research information. 450 papers to be presented on “hot topics”.
Prof. Ramjee Prasad giving introductory speech.
Prof. Ramjee Prasad predicts that the future of wireless comms will be based on single layer technology, not quite sure what is meant by this though.
“Personal Networks are going to be of major importance in future business…”
The international wireless summit has just kicked off and I have the privilege of being amongst some of the greatest think-tanks in the wireless arena.
The aim of the IWS is to offer a platform for establishing exchanges of information between universities, industry and science parks. The next summit will be in 2008 in Helsinki, Finland.
International Wireless Symposium aims to exchange research information. 450 papers to be presented on “hot topics”.
Prof. Ramjee Prasad giving introductory speech.
Prof. Ramjee Prasad predicts that the future of wireless comms will be based on single layer technology, not quite sure what is meant by this though.
“Personal Networks are going to be of major importance in future business…”
Friday, September 09, 2005
Network stats on Freifunk
See: http://wiki.freifunk-leipzig.public-ip.org/index.php/LinksysNetzwerkStatisik for info on how to install web interface packages for network stats.
p.s. hows your german?
Thursday, September 08, 2005
How to stop dhcp client over-writing resolv.conf
Finally I found out how to do it
Edit the /etc/dhcp3/dhclient.conf file
Find the line that says request
Comment out the line that requests for domain-name, domain-name-servers and host-name
request subnet-mask, broadcast-address, time-offset, routers,
# domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope;
Edit the /etc/dhcp3/dhclient.conf file
Find the line that says request
Comment out the line that requests for domain-name, domain-name-servers and host-name
request subnet-mask, broadcast-address, time-offset, routers,
# domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope;
Setting up different networking scenarios on a laptop
I have always wanted to write some good scripts that configure my laptop for home and work wireless/ethernet automatically in ubuntu and so I set about building up a set of scripts that I can call.
I have four scenarios:
1. use laptop at home with wireless access point
2. use laptop at home with ethernet
3. use laptop at work with wireless access point
4. use laptop at work with ethernet
I created two files in /etc/network: interfaces.work and interfaces.home with all the ethernet and wireless settings for home and work in this file
/etc/network/interfaces.home
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
iface eth0 inet static
address 10.3.13.102
netmask 255.255.255.0
gateway 10.3.13.1
#The wireless network interface
iface eth1 inet dhcp
wireless-essid pta-mesh
wireless-mode Ad-Hoc
wireless-channel 1
wireless-key off
/etc/network/interfaces.work
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
iface eth0 inet dhcp
# The wireless network interface
iface eth1 inet dhcp
wireless-essid icomtek
wireless_mode Managed
wireless-key off
I also created two files with my dns and domain settings for home and work in /etc/ called resolv.home and resolv.work
resolv.home
search icomtek.csir.co.za elarduspark.org.za cids.org.za
nameserver 146.64.28.1 10.3.13.1
resolv.work
search icomtek.csir.co.za cids.org.za
nameserver 146.64.28.1
Here are my scripts that configure my interfaces based on the above files
1. Setup for wireless networking at home
/usr/local/bin/homenet-wireless
#!/bin/bash
echo Setting up network for home wireless network
sudo cp /etc/network/interfaces.home /etc/network/interfaces
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth1
sudo cp /etc/resolv.home /etc/resolv.conf
2. Setup for ethernet networking at home
/usr/local/bin/homenet-fixed
#!/bin/bash
echo Setting up network for home ethernet
sudo cp /etc/network/interfaces.home /etc/network/interfaces
sudo cp /etc/resolv.home /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth0
3. Setup for wireless at work
/usr/local/bin/worknet-wireless
#!/bin/bash
echo Setting up network for work wireless network
sudo cp /etc/network/interfaces.work /etc/network/interfaces
sudo cp /etc/resolv.work /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth1
4. Setup for ethernet at work
/usr/local/bin/worknet-fixed
#!/bin/bash
echo Setting up network for work ethernet
sudo cp /etc/network/interfaces.work /etc/network/interfaces
sudo cp /etc/resolv.work /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth0
I have four scenarios:
1. use laptop at home with wireless access point
2. use laptop at home with ethernet
3. use laptop at work with wireless access point
4. use laptop at work with ethernet
I created two files in /etc/network: interfaces.work and interfaces.home with all the ethernet and wireless settings for home and work in this file
/etc/network/interfaces.home
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
iface eth0 inet static
address 10.3.13.102
netmask 255.255.255.0
gateway 10.3.13.1
#The wireless network interface
iface eth1 inet dhcp
wireless-essid pta-mesh
wireless-mode Ad-Hoc
wireless-channel 1
wireless-key off
/etc/network/interfaces.work
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
iface eth0 inet dhcp
# The wireless network interface
iface eth1 inet dhcp
wireless-essid icomtek
wireless_mode Managed
wireless-key off
I also created two files with my dns and domain settings for home and work in /etc/ called resolv.home and resolv.work
resolv.home
search icomtek.csir.co.za elarduspark.org.za cids.org.za
nameserver 146.64.28.1 10.3.13.1
resolv.work
search icomtek.csir.co.za cids.org.za
nameserver 146.64.28.1
Here are my scripts that configure my interfaces based on the above files
1. Setup for wireless networking at home
/usr/local/bin/homenet-wireless
#!/bin/bash
echo Setting up network for home wireless network
sudo cp /etc/network/interfaces.home /etc/network/interfaces
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth1
sudo cp /etc/resolv.home /etc/resolv.conf
2. Setup for ethernet networking at home
/usr/local/bin/homenet-fixed
#!/bin/bash
echo Setting up network for home ethernet
sudo cp /etc/network/interfaces.home /etc/network/interfaces
sudo cp /etc/resolv.home /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth0
3. Setup for wireless at work
/usr/local/bin/worknet-wireless
#!/bin/bash
echo Setting up network for work wireless network
sudo cp /etc/network/interfaces.work /etc/network/interfaces
sudo cp /etc/resolv.work /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth1
4. Setup for ethernet at work
/usr/local/bin/worknet-fixed
#!/bin/bash
echo Setting up network for work ethernet
sudo cp /etc/network/interfaces.work /etc/network/interfaces
sudo cp /etc/resolv.work /etc/resolv.conf
eth0_status=`ifconfig | grep eth0`
eth1_status=`ifconfig | grep eth1`
if [ -n "$eth0_status" ]; then
sudo ifdown eth0
fi
if [ -n "$eth1_status" ]; then
sudo ifdown eth1
fi
sudo ifup eth0
Thursday, August 11, 2005
Setting up DHCP with OLSR
There have been so many misleading postings on this - I will finally set the record straight.
You will need to reserve a block of IP's for non OLSR wireless clients that want to connect onto the mesh network such as a laptop. Here is an example setup:
Wireless router 1:
Wireless IP: 10.51.1.13
LAN IP: 10.3.13.1
Subnet for Wireless DHCP clients: 10.51.1.64/28 (This would mean that 16 machines could potentially connect to this wireless router. The IP leases will be in the range from 10.51.1.64 to 10.51.1.79)
Wireless router 2:
Wireless IP: 10.51.1.14
LAN IP: 10.3.14.1
Subnet for Wireless DHCP clients : 10.51.1.80/28 (IP leases will be in the range from 10.51.1.80 to 10.51.1.93)
To set this up On Friefunk firmware
Wireless Router 1:
OLSR:
OLSR DHCP: 10.51.1.64/28
Wireless Router 2:
OLSR:
OLSR DHCP: 10.51.1.80/28
Most people gave strange values for OLSR DHCP in their postings the most common one was:
OLSR DHCP: 10.51.1.80/28, 255.255.255.240
The subnet mask after the comma (255.255.255.240) is an alternative to the slash format /28. Why does everyone have this reduntant subnet mask on their postings???
You will need to reserve a block of IP's for non OLSR wireless clients that want to connect onto the mesh network such as a laptop. Here is an example setup:
Wireless router 1:
Wireless IP: 10.51.1.13
LAN IP: 10.3.13.1
Subnet for Wireless DHCP clients: 10.51.1.64/28 (This would mean that 16 machines could potentially connect to this wireless router. The IP leases will be in the range from 10.51.1.64 to 10.51.1.79)
Wireless router 2:
Wireless IP: 10.51.1.14
LAN IP: 10.3.14.1
Subnet for Wireless DHCP clients : 10.51.1.80/28 (IP leases will be in the range from 10.51.1.80 to 10.51.1.93)
To set this up On Friefunk firmware
Wireless Router 1:
OLSR:
OLSR DHCP: 10.51.1.64/28
Wireless Router 2:
OLSR:
OLSR DHCP: 10.51.1.80/28
Most people gave strange values for OLSR DHCP in their postings the most common one was:
OLSR DHCP: 10.51.1.80/28, 255.255.255.240
The subnet mask after the comma (255.255.255.240) is an alternative to the slash format /28. Why does everyone have this reduntant subnet mask on their postings???
Monday, August 08, 2005
good info on checking linksys hardware version
Finally some good info about finding the version number from outside markings and using NVRAM settings - info from www.openwrt.org
Linksys WRT54G
1. Hardware versions
There are currently seven versions of the WRT54G (v1.0, v1.1, v2.0, v2.2, v3.0, v3.1, v4.00). With the exception of v4.00 devices (it is currently marked as untested for White Russian RC1), the WRT54G units are supported by OpenWrt 1.0 (White Russian) and later. boot_wait is off by default on these routers, so you should turn it on. The version number is found on the label on the bottom of the front part of the case below the Linksys logo.
1.0.1. Identification by S/N
Useful for identifying shrinkwrapped units. The S/N can be found on the box, below the UPC barcode.
| | OpenWRT | ||
| Model | S/N | CVS | EXP |
| WRT54G v1.1 | CDF20xxxxxxx | | |
| CDF30xxxxxxx | |||
| WRT54G v2 | CDF50xxxxxxx | | |
| WRT54G v2.2 | CDF70xxxxxxx | | |
| WRT54G v3 | CDF80xxxxxxx | | |
| WRT54G v3.1 (AU?) | CDF90xxxxxxx | | |
Please contribute to this list. 
1.1. WRT54G v1.0
The WRT54G v1.0 is based on the Broadcom 4710 board. It has a 125MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is a mini-PCI card. The switch is an ADM6996.
1.2. WRT54G v1.1
The WRT54G v1.1 is based on the Broadcom 4710 board. It has a 125MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is soldered to the board. The switch is an ADM6996.
Hardware informations (nvram) :
boardtype=bcm94710dev
1.3. WRT54G v2.0
The WRT54G v2.0 is based on the Broadcom 4712 board. It has a 200MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is integrated to the board. The switch is an ADM6996.
Hardware informations (nvram) :
boardtype=0x0101
boardflags=0x0188
1.4. WRT54G v2.2
The WRT54G v2.2 is based on the Broadcom 4712 board. It has a 200MHz CPU, 4Mb flash and 16Mb DDR-SDRAM. The wireless NIC is integrated to the board. The switch is a BCM5325.
Hardware informations (nvram) :
boardtype=0x0708
boardflags=0x0118
1.5. WRT54G v3.0 & WRT54G v3.1
This unit is just like the V2.2 Except it has an extra reboot button on the left front panel behind a Cisco logo.
1.6. WRT54G v4.00
Please add information for this revision.
Hardware informations (nvram) :
boardrev=0x10
boardtype=0x0708
boardflags2=0
boardflags=0x0118
boardnum=42
2. Table summary
how to get info :
* board info: nvram show | grep board | sort
* cpu model: cat /proc/cpuinfo | grep cpu
| Model | boardrev | boardtype | boardflags | boardflags2 | boardnum | wl0_corerev | cpu model |
| WRT54G v1.1 | - | bcm94710dev | - | - | 42 | 5 | BCM4710 V0.0 |
| WRT54G v2.0 | - | 0x0101 | 0x0188 | - | - | - | BCM3302 V0.7 |
| WRT54G v2.2 | - | 0x0708 | 0x0118 | - | - | 7 | - |
| WRT54G v3.0 | 0x10 | 0x0708 | 0x0118 | 0 | 42 | 7 | BCM3302 V0.7 |
| WRT54G v3.1 (AU?) | 0x10 | 0x0708 | 0x0118 | 0 | 42 | 7 | BCM3302 V0.7 |
| WRT54G v4.0 | 0x10 | 0x0708 | 0x0118 | 0 | 42 | 7 | BCM3302 V0.7 |
| WRT54GS v1.0 | 0x10 | 0x0101 | 0x0388 | 0 | 42 | 7 | BCM3302 V0.7 |
| WRT54GS v1.1 | 0x10 | 0x0708 | 0x0318 | 0 | 42 | - | - |
| Buffalo WBR-54G | 0x10 | bcm94710ap | 0x0188 | 2 | 42 | - | - |
| Toshiba WRC1000 | - | bcm94710r4 | - | - | 100 | - | - |
| Buffalo WBR2-G54S | 0x10 | 0x0101 | 0x0188 | 0 | 00 | - | - |
| Asus WL-500G Deluxe | 0x10 | bcm95365r | - | - | 45 | 5 | BCM3302 V0.7 |
*other variables (nvram) of interest : boot_ver, pmon_ver, firmware_version, os_version
please complete this table. Look at this thread : ![[WWW]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_u6iupQkv71qemubTeLmApVO2hGCFmYhY5qneOsmjhRZuu0yuZWQqhjjDIMz6LiwCNwny8QikqF37vNxQsTgaRFGdZBWMjinmQrPpoX2d1B2HJVxXeg2uW4=s0-d){kind=small}
3. Hardware hacking
There are revision XH units of the WRT54G v2.0. These units have 32Mb of memory, but they are locked to 16Mb. You can unlock the remaining memory with changing some of the variables. Afterburner (aka. Speedbooster) mode can be enabled with some variables, too.
Thursday, July 14, 2005
Running Kismet-Drone on a Linksys WRT54G
Install either the kismet or kismet_drone package. Then edit /etc/kismet_drone.conf and change the source from wrt54g,eth1,wrt45g to wrt54g,prism0,wrt54g.
Then run kismet from your host, pc and off u go!
Then run kismet from your host, pc and off u go!
Monday, July 04, 2005
a few tips with olsr on openwrt freifunk
I had this problem with the OLSR web interface on the Freifunk openwrt implementation. If entered the following for the HNA4 field
HNA4: 10.3.13.1 255.255.255.0
Which should advertise the whole 10.3.13.x net it would advertise the 10.0.0.0 net. I discovered that it needs the subnet mask in this format instead
HNA4: 10.3.13.1/24
A few other things I learnt
1. NVRAM variable ff_hna4 stores the HNA4 setting
2. /etc/olsr.conf is ignored by freifunk
3. /rom/etc/olsrd.conf stores a permanent copy of the olsrd setup
4. /var/etc/olsrd.conf is a symbolic link to /tmp/etc/olsrd.conf ... this file is copied from /rom/etc/olsrd.conf into RAM (ramfs filesystem) and is the one called by olsrd.
ps -A will reveal that olsrd is called as follows
olsrd -f /var/etc/olsrd.conf -d 0
HNA4: 10.3.13.1 255.255.255.0
Which should advertise the whole 10.3.13.x net it would advertise the 10.0.0.0 net. I discovered that it needs the subnet mask in this format instead
HNA4: 10.3.13.1/24
A few other things I learnt
1. NVRAM variable ff_hna4 stores the HNA4 setting
2. /etc/olsr.conf is ignored by freifunk
3. /rom/etc/olsrd.conf stores a permanent copy of the olsrd setup
4. /var/etc/olsrd.conf is a symbolic link to /tmp/etc/olsrd.conf ... this file is copied from /rom/etc/olsrd.conf into RAM (ramfs filesystem) and is the one called by olsrd.
ps -A will reveal that olsrd is called as follows
olsrd -f /var/etc/olsrd.conf -d 0
Tuesday, June 28, 2005
Linksys WRT54G hardware differences
This has been bothering me - there are 5 different hardware versions of the WRT54G wireless router (1.0, 1.1, 2.0, 2.2, 3.0) and many of the open firmware platforms like openwrt or sveasoft (The betrayer of the word open) only run on particular hardware versions. The main changes are the processor, amount of RAM/FLASH, the wireless hardware and the ethernet hardware
Check out all the differences here
http://www.linksysinfo.org/modules.php?name=Content&pa=showpage&pid=6
We have ordered three batches of Linksys hardware - I must check which hardware platforms we have
My Linksys on my roof gave the following results
Result of the command
$>cat /proc/cpuinfo
system type : Broadcom BCM947XX
processor : 0
cpu model : BCM3302 V0.7
BogoMIPS : 199.47
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
dcache hits : 3472555964
dcache misses : 1631950511
icache hits : 264142837
icache misses : 2075639807
instructions : 0
Some of the possible clue NVRAM settings when running the command
$>NVRAM show
boardrev=0x10
bootver-v2.3
boardnum=42
Check out all the differences here
http://www.linksysinfo.org/modules.php?name=Content&pa=showpage&pid=6
We have ordered three batches of Linksys hardware - I must check which hardware platforms we have
My Linksys on my roof gave the following results
Result of the command
$>cat /proc/cpuinfo
system type : Broadcom BCM947XX
processor : 0
cpu model : BCM3302 V0.7
BogoMIPS : 199.47
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
dcache hits : 3472555964
dcache misses : 1631950511
icache hits : 264142837
icache misses : 2075639807
instructions : 0
Some of the possible clue NVRAM settings when running the command
$>NVRAM show
boardrev=0x10
bootver-v2.3
boardnum=42
Thursday, June 23, 2005
Setting up OLSR mesh on a Linksys
Setting up OLSR mesh on a Linksys ( Assumes a stock standard Linksys out of the box)
1. Download freifunk firmware from (http://www.freifunk.net/wiki/FreifunkFirmwareEnglish) - openwrt-g-freifunk-1.0.2-en.bin
2. Set boot wait on linksys
Web method:
Navigate to web page were you can send pings and type each of these lines one line at a time
;cp${IFS}*/*/nvram${IFS}/tmp/n
;*/n${IFS}set${IFS}boot_wait=on
;*/n${IFS}commit
;*/n${IFS}show>tmp/ping.log
NVRAM method:
telnet into box and type the following
nvram set boot_wait=on
nvram commit
reboot
3. Upload firmware
Give yourself a fixed IP in the 192.168.1.x range e.g. 192.168.1.100
Use tftp to upload firmware
tftp 192.168.1.1
tftp> binary
tftp> rexmt 1
tftp> trace
Packet tracing on.
tftp> put openwrt-g-freifunk-1.0.2-en.bin
Wait for the power light to stop flashing
Power cycle the box
4. Check that the web interface is working. Visit the site http://192.168.1.1 on your web browser - you should see the main freifunk web interface appear
5. Set up the wireless interface
WLAN protocol: Static
Ip Address: 192.168.2.5
Netmask: 255.255.255.0
WLAN Mode: Ad Hoc (Peer to Peer)
ESSID: mesh
Channel: 6
TX Power: 100
6. Set up the LAN interface
LAN protocol: Static
LAN IP: 192.168.4.1
LAN Netmask: 255.255.255.0
Disable NAT: yes
Disable Firewall: yes
7. Set up the WAN interface
WAN Protocol: DHCP
Host name: Lawrence
8. Set up OLSR
HNA4: 192.168.4.1 255.255.255.0
9. Restart the Linksys
You should now be given an IP address in the 192.168.3.x range
You should be able to connect to another mesh access point and even get a default gateway to an internet point, if one exists
1. Download freifunk firmware from (http://www.freifunk.net/wiki/FreifunkFirmwareEnglish) - openwrt-g-freifunk-1.0.2-en.bin
2. Set boot wait on linksys
Web method:
Navigate to web page were you can send pings and type each of these lines one line at a time
;cp${IFS}*/*/nvram${IFS}/tmp/n
;*/n${IFS}set${IFS}boot_wait=on
;*/n${IFS}commit
;*/n${IFS}show>tmp/ping.log
NVRAM method:
telnet into box and type the following
nvram set boot_wait=on
nvram commit
reboot
3. Upload firmware
Give yourself a fixed IP in the 192.168.1.x range e.g. 192.168.1.100
Use tftp to upload firmware
tftp 192.168.1.1
tftp> binary
tftp> rexmt 1
tftp> trace
Packet tracing on.
tftp> put openwrt-g-freifunk-1.0.2-en.bin
Wait for the power light to stop flashing
Power cycle the box
4. Check that the web interface is working. Visit the site http://192.168.1.1 on your web browser - you should see the main freifunk web interface appear
5. Set up the wireless interface
WLAN protocol: Static
Ip Address: 192.168.2.5
Netmask: 255.255.255.0
WLAN Mode: Ad Hoc (Peer to Peer)
ESSID: mesh
Channel: 6
TX Power: 100
6. Set up the LAN interface
LAN protocol: Static
LAN IP: 192.168.4.1
LAN Netmask: 255.255.255.0
Disable NAT: yes
Disable Firewall: yes
7. Set up the WAN interface
WAN Protocol: DHCP
Host name: Lawrence
8. Set up OLSR
HNA4: 192.168.4.1 255.255.255.0
9. Restart the Linksys
You should now be given an IP address in the 192.168.3.x range
You should be able to connect to another mesh access point and even get a default gateway to an internet point, if one exists
Monday, June 20, 2005
How the ETX metric in OLSR is calculated
The ETX of a link is the predicted number of data transmissions required to send a packet over that link, including retransmissions. The ETX of a route is the sum of the ETX for each link in the route. For example, the ETX of a three-hop route with perfect links is three; the ETX of a one-hop route with a 50% delivery ratio is two.
The ETX of a link is calculated using the forward and reverse delivery ratios of the link. The forward delivery ratio, df , is the measured probability that a data packet successfully arrives at the recipient; the reverse delivery ratio, dr , is the probability that the ACK packet is successfully received. The expected probability that a transmission is successfully received and acknowledged is df x dr .
A sender will retransmit a packet that is not successfully acknowledged. Because each attempt to transmit a packet can be considered a Bernoulli trial, the expected number of transmissions is:
ETX = 1/ (df x dr)
For a full description of how df and dr is actually calculated see MIT's publication site
The ETX of a link is calculated using the forward and reverse delivery ratios of the link. The forward delivery ratio, df , is the measured probability that a data packet successfully arrives at the recipient; the reverse delivery ratio, dr , is the probability that the ACK packet is successfully received. The expected probability that a transmission is successfully received and acknowledged is df x dr .
A sender will retransmit a packet that is not successfully acknowledged. Because each attempt to transmit a packet can be considered a Bernoulli trial, the expected number of transmissions is:
ETX = 1/ (df x dr)
For a full description of how df and dr is actually calculated see MIT's publication site
Mesh scalability by modifying the MAC layer in Altheros
This is a great article that discusses the whole issue of loss of performance in a single radio mesh network with many hops. Modifying the MAC layer on our 50 Altheros cards we are getting for the massive mesh could prove a very novel way of dealing with the inherent problems in the WiFi spec when trying to build large mesh networks
Tuesday, June 14, 2005
Drawing(almost realtime) pretty network topology pictures with
Tried it, works well'ish.
Regards,
Yusuf Kaka
________________________________________________________________________________
Mobile Platforms Engineer
CSIR - Meraka Institute (African Advanced Institute for ICT)
Web Address: www.csir.co.za or www.meraka.co.za
________________________________________________________________________________
Monday, May 16, 2005
Howto: Mesh Network on a WRT54G using OLSRd
I followed the instructions here: Howto: Mesh Network on a WRT54G using OLSRd and now have a mesh node (AngelNET_mesh) running OLSR.
I used channel SSID AngelNET_mesh, channel 11, 64bit wep, key: 1234567890
I used channel SSID AngelNET_mesh, channel 11, 64bit wep, key: 1234567890
Running Kismet-Drone on a Linksys WRT54G (OpenWRT)
Install either the kismet or kismet_drone package. Then edit /etc/kismet_drone.conf and change the source from wrt54g,eth1,wrt45g to wrt54g,prism0,wrt54g.
Edit /etc/kismet.conf on your host pc, include the line: source=kismet_drone,10.168.1.1:3501,drone
then run kismet and off u go!
Edit /etc/kismet.conf on your host pc, include the line: source=kismet_drone,10.168.1.1:3501,drone
then run kismet and off u go!
Wednesday, April 06, 2005
Linksys Disaster Recovery
Theres nothing like learning the hard way! As a result of my usual "If it ain't broke, it hasn't been fixed enough" approach to life, I fiddled with the Linksys until it innevitably went into a coma/ vegetative state. How did I manage this you ask? Simple, I started by doing a firmware upgrade using the wrong sveasoft image, which resulted in a moderately upset linksys which refused to talk to me on the web interface. With the help of our trusted Android (Andrew), I managed to do a reset-hold/ ping / tftp recovery and then flashed the poor bugger with OpenWRT, which according to OpenWRT is still not supported by them for the version 2.2 Linksys, which I subsequently found out I was using! So alas, all that remained was a perfectly dead Linksys, not responding to anything. It was time to go in, screwdrivers a blazing. I shorted out pins 15 and 16 and started up the Linksys, this created a crc error which was detected on boot, this then started up an emergency TFTP server which allowed me to ping and finally tftp the original Linksys firmware back onto it!
More details on the recovery processes can be found here:
OpenWrtDocs/Troubleshooting - OpenWrt
Whew!
More details on the recovery processes can be found here:
OpenWrtDocs/Troubleshooting - OpenWrt
Whew!
Tuesday, April 05, 2005
War-Driving: Using Kismet and a GPS
This article ""Configuring and Using Kismet"" has a nice tutorial on how to setup Kismet and your GPS on Linux. Also look at the related links on the site for some info on hacking the Linksys!
Saturday, April 02, 2005
How to get ubuntu to automatically start programs when user logs in
If you want ubuntu to automatically login aparticular user and start user programs after login
From Gnome, Select Computer, System Configuration, Login Screen Setup.
Under Auomatic Login, Select check box: Login a user automatically on first bootup. Choose a user under: Automatic login username
To start programs automatically when user logs in edit the following script
~/.gnome2/session-manual
Here is my example:
[Default]
num_clients=3
0,RestartStyleHint=3
0,Priority=50
0,RestartCommand=x11vnc -shared -forever
1,RestartStyleHint=3
1,Priority=50
1,RestartCommand=mount /mnt/win_c
2,RestartStyleHint=3
2,Priority=50
2,RestartCommand=mount /mnt/win_d
From Gnome, Select Computer, System Configuration, Login Screen Setup.
Under Auomatic Login, Select check box: Login a user automatically on first bootup. Choose a user under: Automatic login username
To start programs automatically when user logs in edit the following script
~/.gnome2/session-manual
Here is my example:
[Default]
num_clients=3
0,RestartStyleHint=3
0,Priority=50
0,RestartCommand=x11vnc -shared -forever
1,RestartStyleHint=3
1,Priority=50
1,RestartCommand=mount /mnt/win_c
2,RestartStyleHint=3
2,Priority=50
2,RestartCommand=mount /mnt/win_d
Wednesday, March 23, 2005
IPsec and VPN's
There are several ways to isolate users/groups in a network. One of the neatest ways however is by setting up VPN's (virtual private networks). This is where IPsec comes in.IPsec is a protocol which sits on top of the Internet Protocol (IP) layer. It allows two or more hosts to communicate in a secure manner (hence the name).
There are several online guides to setting up IPsec VPN's:
Creating a VPN between two networks, separated by the Internet, using FreeBSD gateways.
Linux:
Linux IPsec HOWTO
IPsec tools
Windows:
Setting up a windows XP client
IPsec and you
Mixing Different Clients and Servers (Windows/Linux):
Jacco's networking stuff
OpenSwan setup for Linux server and Linux/Windows clients
FreeSwan setup for Linux server and Linux/Windows clients
Example System:
IPSec Secure Tunnel at Mathnet
There are several online guides to setting up IPsec VPN's:
Creating a VPN between two networks, separated by the Internet, using FreeBSD gateways.
Linux:
Linux IPsec HOWTO
IPsec tools
Windows:
Setting up a windows XP client
IPsec and you
Mixing Different Clients and Servers (Windows/Linux):
Jacco's networking stuff
OpenSwan setup for Linux server and Linux/Windows clients
FreeSwan setup for Linux server and Linux/Windows clients
Example System:
IPSec Secure Tunnel at Mathnet
Friday, March 18, 2005
Thursday, February 10, 2005
Setting up WDS on the linksys
Wow it's been a while since a posting on this blog ... it's time to start testing out some linksys ideas again.
Always wanted to test the performance of WDS vs pure mesh. HEre are some good links on setting up WDS
1. The sveasoft WDS tutroial - a little old - April 2004
2. Tutorial with some nice picures
3. Good overall technical information on WDS from Orinioco
Always wanted to test the performance of WDS vs pure mesh. HEre are some good links on setting up WDS
1. The sveasoft WDS tutroial - a little old - April 2004
2. Tutorial with some nice picures
3. Good overall technical information on WDS from Orinioco
Saturday, November 20, 2004
Lets add wireless cameras to the mesh
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
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
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
Subscribe to:
Posts (Atom)