The Wiki is taking shape

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!

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.

 

Best collection of links I've seen for ad hoc networking

http://www.antd.nist.gov/wctg/manet/adhoclinks.html

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

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.

Making sense of LQ ILQ and ETX in OLSR

You will see a table like this in the OLSR status screen on Freifunk

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 NLQ

ETX = Expected Trasnmission count = How many trasnmission attempts are required to get packets through = 1 / (LQ*ILQ)

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.

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…”

Creating an ipk package

TOOLS

Get the script rightfully called ipkg-build at, among other places, ftp://ftp.handhelds.org/packages/ipkg-utils, or http://www.mizi.com/download/mz20/ipkg-build.

CREATING THE PACKAGE STRUCTURE

Say you wanna create a package called MyPackage; you further wanna package the project called MyProject. Then do the following:

1. Create a directory called MyPackage.
2. Inside directory MyPackage, create a directory called CONTROL.
3. Copy your project (MyProject) to the MyPackage directory.
4. Inside directory CONTORL creating a file called control.

NOTE:

When the package is installed on the target, the MyPAckage directory will be created with respect to root. So if you wanted your files to be installed in /usr/bin on the target system, then our project would in this case be “/usr/bin”. That is you create inside directory MyPackage a directory called /usr/bin.

FORMAT AND CONTENTS OF /CONTROL/control

--------------------------------------------------------------------------------

Package: MyPackage

Priority: optional // default

Version: 1.0 //package version

Architecture: mipsel

Maintainer: I_maintain@you.com

Source: ftp:ftp:122.122.122.122 //See Note below

Section: misc //See Note below

Description: This is an attempt to create ipkg.

------------------------------------------------------------------------------------

NOTE:

The fields Section and Source seem rather useless to me in this example and I initially left them out; however the ipkg-build script complained requiring them, so I just put them in as a workaround without knowing/”caring” of their need. There are other fields not included here which you might need for your purposes, check the web for more.

Further the comments are mine for this documentation purposes only and the script MIGHT NOT permit comments.

RUNNING THE ipkg-build SCRIPT

Now simply run (of course being outside of the directory MyPackage):

“./ipkg-build –c –o root –g root MyPackage” // as root or non-root, or

“./ipkg-build –c MyPackage” //as root

IF all’s well, a package on the current directory will be created.

NOTE:

Without the “-c” option, I could not get the package installed successfully, you can try with or without and see for yourself.

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?

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;

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

Establishing IPsec tunnel/connection between FreeBSD and Linux (openswan IPsec Cisco WRT54G Router)

Establishing IPsec tunnel/connection between FreeBSD and Linux (openswan IPsec Cisco WRT54G Router)

Below is a simple setup demonstrating steps to establish an IPsec connection/tunnel between two machines one running Ipsec/racoon (on FreeBSD) and the other running openswan Ipsec (on WRT54G running Linux) using pre-shared key: This IPsec setup example shows how to control the Private LAN_A (146.64.0.0) network access.

.........(INTERNET)

.........|

.........|

..| FreeBSD | ......10.50.1.3..............................10.50.1.80| Openswan IPsec|

.| Router_A |<========> (“NETWORK”)<=======>| Router_B |

.| 146.64.17.1 |................................................................| 10.1.13.1 |

............ ||.........................................................................||

...Private LAN_A....................................................PPrivate LAN_B

...........|.......................................................................................|...........
....Client_A (146.64.17.12) ..................................Client_B (10.1.13.130)

NOTE: Before running racoon/ipsec and openswan ipsec, ensure that all nodes can successfully reach (ping) each other.

INSTALLING OPENSWAN ON WRT54G

To install, add the following to /etc/ipkg.conf:

src openswan ftp://ftp.openswan.org/openswan/binaries/openwrt/buildroot-20040509/ipkg/

and then run:

ipkg update

ipkg install gmp mawk openswan-module openswan

NOTE: Since /etc/ipkg.conf would normally be a link to the file in /rom directory; You can simple delete the link, and then copy the file over.

CONFIGURATION (Router_A IPsec)

There are three (3) configuration files on Router_A that needs to be edited: ipsec.conf (found in /etc on FreeBSD), psk.conf.(found in /usr/local/etc/racoon/ on FreeBSD) and racoon.conf.(found in /usr/local/etc/racoon/ on FreeBSD).

Add the following two lines in ipsec.conf: (This file defines the ends points of the tunnel to be established. There’d be two lines for each LAN_B client )

spdadd 146.64.0.0/16 10.1.13.0/24 any -P out ipsec esp/tunnel/10.50.1.3-10.50.1.80/require;

spdadd 10.1.13.0/24 146.64.0.0/16 any -P in ipsec esp/tunnel/10.50.1.80-10.50.1.3/require;

Roughly; the first line says “traffic coming from 146.64.0.0 network destined for 10.1.13.0 network must be transported via an IPsec tunnel with local endpoint 10.50.1.3 and far endpoint 10.50.1.80”.

The second line says “traffic coming from 10.1.13.0 network destined for 146.64.0.0 network must/would use an IPsec tunnel with a far endpoint 10.50.1.80 and local endpoint 10.50.1.3”.

Add the following line to psk.conf (This file defines the pre-shared key to be used between Router_A and Router_B).

10.50.1.80 presharedkey

NOTE: Comments must be on a different line to the pre-shared key entry, otherwise the comments are interpreted as part of the pre-shared key.

Add the following lines to racoon.conf

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

remote anonymous

{

# exchange_mode aggressive,main ;

exchange_mode main ;

lifetime time 24 hour ;

proposal {

encryption_algorithm 3des ;

hash_algorithm sha1;

authentication_method pre_shared_key ;

dh_group 2 ;

}

}

sainfo anonymous

{

lifetime time 12 hour ;

encryption_algorithm 3des, blowfish, des, rijndael ;

authentication_algorithm hmac_sha1, hmac_md5 ;

compression_algorithm deflate ;

}

IMPORTANT: The IPsec version (2.3.1) used in this example did not seem to support “aggressive” exchange_mode hence “main” is specified. However, it is possible to include more than mode by separating them with comma; i.e.

exchange_mode aggressive, main ;

Both ways (specifying one or more modes) works! Further other lines with more than one values separated by comma may contain only one value as described for exchange_mode above.

CONFIGURATION (Openswan IPsec, Router_B)

There are two (2) files on Router_B that needs editing: ipsec.conf (found in /etc on Linux) and ipsec.secrets (found in /etc on Linux).

Add the following line in ipsec.secrets: (This file defines the ends points of the tunnel to be established and also the pre-shared key to be used)

10.50.1.3 10.50.1.80: PSK “presharedkey”

NOTE: 1. Place the string after PSK in quotes if it does not start with 0x (as in a hexadecimal number), otherwise openswan will complain.

2. The string after PSK must be the same as that specified in psk.conf on Router_A.

Add the following lines in ipsec.conf: (This file defines among other things, the network to be protected, authentication methods, type of connection, etc.)

config setup

interfaces="ipsec0=eth1"

klipsdebug=none

plutodebug=none

uniqueids=yes

conn %default

keyingtries=0

authby=secret #rsasig

conn crypt

left=10.50.1.80

leftid=10.50.1.80

leftsubnet=10.1.13.1/24

right=10.50.1.3

rightid=10.50.1.3

rightsubnet=146.64.8.8/16

auto=start

type=tunnel

NOTE: The name of our connection is called “crypt”. Under “config setup”, the line interfaces=”ipsec0=eth1” must refer to a real interface (ifconfig will show available interfaces) and also must be the interface through which the data to be protected will travel, in case of more than one NIC. The line “auto=start” says, the connection “crypt” must be brought up when openswan ipsec starts up; to bring up the connection manually either comment out the line or specify “auto=ignore”. The explanation given for ipsec.conf on Router_A is pretty much the same as for Router_B.

STARTING UP IPsec and Racoon (FreeBSD).

At this point all machines are able to reach (ping) each other successfully. Next ensure ipsec and racoon are not running. On my machine I do:

verdi2istc#/etc/rc.d/ipsec stop

Clearing ipsec manual keys/policies.

to stop ipsec if it was already running; and do

verdi2istc# setkey -P -D

No SPD entries.

To ensure there are no IPsec SA/SP database entries; and next do

verdi2istc#killall racoon

to stop racoon.

Next issue

verdi2istc# /etc/rc.d/ipsec restart

to start ipsec, and to verify ipsec started successfully then do

verdi2istd# setkey -P -D

10.1.13.0/24[any] 146.64.0.0/16[any] any

in ipsec

esp/tunnel/10.50.1.80-10.50.1.3/require

created: Aug 30 09:27:39 2005 lastused: Aug 30 09:27:39 2005

lifetime: 0(s) validtime: 0(s)

spid=16531 seq=1 pid=583

refcnt=1

146.64.0.0/16[any] 10.1.13.0/24[any] any

out ipsec

esp/tunnel/10.50.1.3-10.50.1.80/require

created: Aug 30 09:27:39 2005 lastused: Aug 30 09:27:39 2005

lifetime: 0(s) validtime: 0(s)

spid=16530 seq=0 pid=583

refcnt=1

From Router_A, type either racoon (to run in the backgroung) or racoon –F

verdi2istd#racoon

or to fun in foreground type

verdi2istd#racoon -F -d

Foreground mode.

2005-08-30 09:51:59: INFO: main.c:172:main(): @(#)package version freebsd-20040818a

2005-08-30 09:51:59: INFO: main.c:174:main(): @(#)internal version 20001216 sakane@kame.net

2005-08-30 09:51:59: INFO: main.c:175:main(): @(#)This product linked OpenSSL 0.9.7d 17 Mar 2004 (http://www.openssl.org/)

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for AH

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for ESP

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for IPCOMP

2005-08-30 09:51:59: DEBUG: cftoken.l:578:yycf_set_buffer(): reading config file /usr/local/etc/racoon/racoon.conf

2005-08-30 09:51:59: DEBUG: pfkey.c:2379:pk_checkalg(): compression algorithm can not be checked because sadb message doesn't support it.

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 10.50.1.3 (ath0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::202:6fff:fe21:2e71%ath0 (ath0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 146.64.8.1 (sis0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::200:24ff:fec2:b684%sis0 (sis0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 127.0.0.1 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: ::1 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::1%lo0 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:474:autoconf_myaddrsport(): configuring default isakmp port.

2005-08-30 09:52:00: DEBUG: grabmyaddr.c:496:autoconf_myaddrsport(): 7 addrs are configured successfully

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::1%lo0[500] used as isakmp port (fd=5)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): ::1[500] used as isakmp port (fd=6)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=7)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::200:24ff:fec2:b684%sis0[500] used as isakmp port (fd=8)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 146.64.8.1[500] used as isakmp port (fd=9)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::202:6fff:fe21:2e71%ath0[500] used as isakmp port (fd=10)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 10.50.1.3[500] used as isakmp port (fd=11)

2005-08-30 09:52:00: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message

2005-08-30 09:52:00: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message

2005-08-30 09:52:00: DEBUG: policy.c:184:cmpspidxstrict(): sub:0xbfbfea30: 146.64.0.0/16[0] 10.1.13.0/24[0] proto=any dir=out

2005-08-30 09:52:00: DEBUG: policy.c:185:cmpspidxstrict(): db :0x809dc08: 10.1.13.0/24[0] 146.64.0.0/16[0] proto=any dir=in

The –d option is for debug, to see more output add extra –d.

IMPORTANT: At this point if all went well Client_A should not be reachable (try ping) from Router_B and Client_B; meaning private LAN_A is now protected. However, Router_A and Router_B should be able reach/see each other. Do not continue until this is accomplished.

STARTING UP OPENSWAN IPSEC

Now, on Router_B do:

root@Lawrence:/# ipsec setup restart

ipsec_setup: Stopping Openswan IPsec...

ipsec_setup: Starting Openswan IPsec 2.3.1...

verify that the IPsec tunnel has been established correctly by issuing:

root@Lawrence:/# ipsec whack --status

000 interface ipsec0/eth1 10.50.1.80

000 %myid = (none)

000 debug none

000

000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=168, keysizemax=168

000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128, keysizemax=256

000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128

000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160

000

000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128

000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192

000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20

000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16

000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024

000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536

000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048

000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072

000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096

000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144

000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

000

000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}

000

000 "crypt": 10.1.13.0/24===10.50.1.80...10.50.1.3===146.64.0.0/16; erouted; eroute owner: #2

000 "crypt": srcip=unset; dstip=unset

000 "crypt": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0

000 "crypt": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 24,16; interface: eth1;

000 "crypt": newest ISAKMP SA: #1; newest IPsec SA: #2;

000 "crypt": IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024

000

000 #2: "crypt":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27961s; newest IPSEC; eroute owner

000 #2: "crypt" esp.2ec9213@10.50.1.3 esp.aa7dc439@10.50.1.80 tun.1002@10.50.1.3 tun.1001@10.50.1.80

000 #1: "crypt":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2625s; newest ISAKMP; nodpd

000

root@Lawrence:/#

At this point Client_A should be reachable by Client_B. On each/either Router do a tcpdump; and any packets with ESP indicates that the setup tunnel is currently handling data from the clients.

NOTE: ESP packets will only appear if there are packets from either client to the other client.

DEBUGGING (Openswan IPsec)

Earlier I showed how to stop a connection from being started up automatically by openswan. IPsec. So now with ipsec running but our connection “crypt” NOT up, we will debug the starting up of the connection (crypt). To debug the key exchange with racoon, first create a script with following content:

ipsec pluto --debug-all

ipsec whack \

--name crypt \

--tunnel \

--host 10.50.1.80 \

--nexthop 10.50.1.3 \

--client 10.1.13.1/24 \

--updown 'ipsec _updown' --id 10.50.1.80 \

--to \

--host 10.50.1.3 \

--client 146.64.8.1/16 \

--updown 'ipsec _updown' --id 10.50.1.3 \

--psk \

--esp 3des-md5,3des-sha1 \

--ike 3des-md5,3des-sha1 \

--encrypt

ipsec whack --listen

ipsec whack --route --name crypt

ipsec whack --initiate --name crypt

Running this script will show the various key exchange messages. The messages are pretty much clear to see what it’s happening.

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???

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
   1. Identification by S/N
   1. WRT54G v1.0
   2. WRT54G v1.1
   3. WRT54G v2.0
   4. WRT54G v2.2
   5. WRT54G v3.0 & WRT54G v3.1
   6. WRT54G v4.00
2. Table summary
3. Hardware hacking

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.

Please contribute to this list.		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

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

To take the front cover off of this unit you must first remove the small screws under the rubber covers of the front feet!

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 : http://openwrt.org/forum/viewtopic.php?pid=8127#p8127 May be this table should move up to OpenWrtDocs/Hardware.

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.

However, there are no guaranties, that these will work, and changing the memory configuration on a non-XH unit will give You a brick. Check the forums for more info.

If you have a look at the WRT54G v2.2 board, you can find on the left corner, near the power LED, an empty place for a 4 pins button. On the board it is printed as SW2. This is the second reset button you can find on WRT54G v3.0, except that it has not been soldered.

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!

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

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

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

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

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

Getting Kismet working with IPW2200 driver

Thanks to ubuntu forums for this link

Drawing(almost realtime) pretty network topology pictures with

http://meshcube.org/meshwiki/OlsrTopologyVisualization

 

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
________________________________________________________________________________

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

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!

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!

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!

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

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

OLSR

It seems that Mobilemesh is dying a slow painful death and its time to look for something else. OLSR seems to be a suitable replacement and it has been compiled for WRT54G! See: http://www.seattlewireless.net/index.cgi/OpenWrt and http://www.olsr.org/index.cgi?action=download

Interesting Blog on Mesh

Click Here

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

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

CNN.com - Cities find Wi-Fi future - Oct 18, 2004

CNN.com - Cities find Wi-Fi future - Oct 18, 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

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

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

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

New Order - computer security and networking portal

Nice Wifi-security related article

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

Zebra Routing on the linsys

Advnaced Linux routing
Setting up RIP on zebra
Zebra manual

Great site for Linux wireless LAN driver info

Wirless LAN resources for Linux

Setting up a remote sniffer on the linksys

How to setup kismet on linksys

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

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

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

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

The old wire segment feed. I ran netstumbler after installing the new feed. There seems to be a slight increase in gain, but a definate improvement in bandwidth , i.e. I get better gain in the higher and lower channels as opposed to just channel 6. 

Mounted on a camera stand... 

Close-up of the feed element 

The latest coffee cantenna is based upon the previously blogged extremeTech design using a conical feed instead of the simple wire segment. Here are some pics. The cone is made out of copper sheet, I will design a template for the actual construction soon hopefully. 

Sveasoft 1yr subscription approved

We are subscribing to Sveasoft's support which gives us full access to their forums.

Mobile Mesh Kevin's response to David's email

Hi David,

Thanks for the email. Nice to see others are trying to put Mobile Mesh

to some good use.

Other folks appear to have had success in getting MobileMesh to run on
a
MIPS processor. Here are a couple links to the meshcube:

http://www.meshcube.org/english/specs.html

http://www.meshcube.org/meshwiki/

You might want to take a look at their CVS directory:
http://www.meshcube.org/cgi-bin/viewcvs.cgi/build/ ; it has a tools and

toolchain directory that may be of use. I personally have no experience

with the meshcube or their toolchain, but it looks like it might be
useful for your work.

Hope this helps,
Kevin



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

3d simulation (4nec2) of coffee can antenna! 

Building a Wi-Fi Antenna Out of a Tin Can

The best guide to building your own antennae I've come accross so far! Building a Wi-Fi Antenna Out of a Tin Can

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

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

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

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

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

Porting Mobilemesh From Linux To FreeBSD

First off the "Legal stuff", i.e. Limitations and Disclaimers!!!!


1.1 Limitation
At the time of writing this document, the ported implementation was not fully regress tested to make sure it performs exactly the same as the original Linux version. However, the minimal testing done did not reveal any differences in performance and/or functionality between the two ports.

1.2 Disclaimer
The Linux version is written in C++, so please take note that the writer is not a C++ expert and hence (possibly) some of the suggestions made could be amateurish. Certainly with rigorous testing and more time on the project such possible technical errors could have been spotted and fixed (hopefully).


3. Environment
3.1 Software Environment
The following table shows the software used during the porting.
Software Version
FreeBSD 5.2.1
Gmake 3.80
G++ 3.3.3


3.2 Make Utility Issues
From the start, if you get errors when running make using the provided Makefile, simply switch to gmake.

3.2.1 Compiler Isuues
3.2.1.1 Array Indexing Issues
The Linux version indexes arrays using char type. This causes at least warnings during compile time.
Suggested solution: Typecast all indices to unsigned char.
Reason: It appears that the ISO standard does allow/specify that type char can be used as an array index, however, leave it up to the compiler implementors to decided where such char is signed or unsigned. However, a char can either be unsigned or signed. In the case of signed char, this also includes negative numbers that cannot index array and hence a possible runtime error. So some compilers do insist/expect (at complie time) that the char index variable be qualified as either signed or unsigned.

3.2.1.2 Class Variables Initilisation
Ensure that class variables are initialised. Otherwise, calls to some system calls simply fail. E.g. the call to sysctl() function failed until all variables used in its call were properly initialised.

3.2.1.3 Errors and Warnings in File BoBorder.h
Error: “ISO ++ standard ambiguity”.
Suggested solution: At every occurance of an expression where an addition between an object and an integeris performed, use the dot operator+.
E.g. use now.operator+(cAdPeriod) instead of now + cAdPeriod.

3.2.1.4 Errors and Warnings in File LnDiscover.h
Error: “ISO ++ standard ambiguity”.
Suggested solution: At every occurance of an expression where an object is added to an integer, use the dor operator.
E.g. use pruneTime.operator+(cPrunePeriod) instead of pruneTime + cPrunePeriod.

3.2.1.5 Errors accessing member variables of rtentry structure in File MmRouter.h
Error: Variables rt_dst, rt_gateway, rt_genmask and rt_metric are not members of the structure rtentry.
Suggested solution: Comment them out and carry on. At least this stops the compiler errors.

NOTE: Please remember that I didn’t do regress testing and hence didn’t notice any errors as a result of commenting out this code. I however do realise that these commented lines are functional code and one could/should expect some issues either functional or performance related.

3.2.1.6 Errors in Parameter Arguments in File UtDebug.c
Error: Some functions make variable assignments on the function parameters. This causes an error as the same assignments are already made in file UtDebug.h.
Suggested Solution: Comment out the variable assignment part of the function parameters.

3.2.1.7 Changes in File UtInterface.h
This file presented me with so many functional runtime problems that I had to “rewrite” a part of it. This mainly apply to Discover() method.
Suggested solution:
a) Replace all ioctl function calls with sysctl calls. Search the man pages for the sysctl documentation.
b) The Discover() method mainly extracts each interface’s information from the kernel, create an interface object using the extracted information and then pushes the interface object into a list. Replace the extraction of interface information code and a good reference is the source code of ifconfig.c (that’s part of the FreeBSD distribution).

3.2.1.8 Errors in Parameter Arguments in File UtString.C
Error: Some functions make variable assignments on the function parameters. This causes an error since the same assignments are already made in file UtString.h.
Suggested Solution: Comment out the assignment part of the function parameters.

Numerical Electromagnet Code (NEC) Archives

This site contains several versions of NEC (Numerical Electromagnet Code) software, similar to that used by Poyting (SuperNEC)

www.freeantennas.com

This site contains the design, simulation and construction of several home-made wifi and other antennae

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

Site with help on cross compiling

Bill Gatliff's Website

Finally a way to compile mobile mesh for Linksys

This shows how to create the C++ build environment on OpenWrt

Configuring IP Forwarding Policies

Configuring IP Forwarding Policies

Linux IP Masquerade HOWTO

Linux IP Masquerade HOWTO

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

marlow.dk - Marlow@home

marlow.dk - Marlow@home: "Wireless Community WAN"

good link on setting up linux on linksys

how to build image from linksys source

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

Ad hoc protocols implementations - Wikipedia

List of all implementations of ad hoc protocols

Ad hoc protocols implementations - Wikipedia

Ad Hoc Networking Links

Good list of links including simulators

Ad Hoc Networking Links

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

Quick Edit links enabled on this blog

Enabled Quick Edit links. This gives you quick and direct access to edit your posts after they've been published. You see the "pencil" icon on your own posts only. This requires that cookies are enabled on your browser so that the server knows who is logged in.

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

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

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

Nice site with WiFi antenna summaries - Cisco

Cisco antennas summary

Cisco Aironet Antenna Reference Guide-Cisco Aironet Antennas and Accessories - Cisco Systems

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

MIT mesh networking Publications

More good publications from MIT on mesh networking

The Grid Ad�Hoc Networking Project: Publications

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

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

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.

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

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

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

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

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

Anyone that wants to become part of the mesh must contact me for an IP address

Nice receipte for setting up Linux as an access point

O'Reilly Wireless dev centre 802.11b linux AP recipe?

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.

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)

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

Good comparison of Linksys WRT54G, Soekris and Meshcube

Slashdot | Meshcube: A New Mesh-Routing Wireless Device: "http://www.olsr.org"

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.

detail of fishbone antenna as part of experimental wifi installation in building 43c
Posted by Hello

edna experimental wifi installation in building 43c
Posted by Hello

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

Some more useful mesh info

Complete list of mesh protocols - Wiki site

Desciprion of protcols being used at CU wireless

To sustain the scalability of its infrastructure, Community
Wireless Network needs software that implements an uncomplicated,
extensible routing protocol that will support a network of
hundreds of nodes, and a routing path metric that "prefers"
reliable, high-capacity routes to spotty, low-capacity routes.

Based on a review of the wireless networking literature, BBN
Technologies' Hazy Sighted Link State (HSLS) routing algorithm
will support growth to thousands of nodes, which will more than
meet our requirements. HSLS also admits a parsimonious
implementation that will be far easier for a grassroots project
to debug and extend than more complicated algorithms whose
scalability is comparatively poor. The Expected Transmission
Count (ETX) path metric is a simple, proven routing path metric
that favors high-capacity, reliable links. The Community
Wireless Network will develop a UNIX routing daemon implementing
HSLS and ETX. The major functional units of the daemon are
described below.

CWN will leverage existing open source software whenever that
is possible. For example, the Zebra routing software suite
will provide our Routing Information Base (RIB) and kernel
abstraction. Because we will re-use Zebra, we will save tens
of hours of development and debugging, we will gain some
inter-operating system portability (*BSD, Linux, Solaris), and
we will have the capability to extend our HSLS daemon to share
routes with other routing protocols (BGP, OSPF, and RIP) in
the future.


More detailed description of HSLS

More detailed descrtiption of ETX

Fwd: ZDNet UK: Open-source Wi-Fi links remote communities

> Open-source Wi-Fi links remote communities
>
>
>
> Andrew Donoghue
>
>
>
>
>
> European wireless and open-source specialists have embarked on an
> international tour to spread the benefits of the technology to
> developing
> countries from Tajikistan to Ghana.
>
> The team, known as Informal, claims its wireless roadshow is an
> attempt to
> empower non-governmental organisations (NGOs) in the developing world

> to own,
> operate and grow their own Internet infrastructure using wireless
> technology
> such as mesh networking. The aim is to allow remote communities in
> developing
> countries without traditional telecoms infrastructure to communicate

> more
> effectively.
>
> "We support these kinds of activities because we believe that the
> benefits of
> the Internet should be available globally," said Informal lead team

> member
> Simon Crab.
>
> While a lot of attention has been focused on bridging the digital
> divide and
> providing Internet access to remote areas, Informal claims to be
more
> concerned with allowing local communities to exchange information
with
> each
> other -- spreading local knowledge. "In each country, we will work
> primarily
> with local NGOs to assist them in building, maintaining and extending

> their
> own networks in areas that are under-served by telecommunication
> infrastructure," said Crab.
>
> The Informal team recently arrived in Tajikistan where it will remain

> for
> next three months before moving onto Ghana, Nepal, the Philippines,

> China and
> finally India.
>
> Existing examples of wireless technology projects in the developing

> world
> include DakNet and First Mile Solutions in Cambodia and the Jhai
> Foundation's
> Remote IT Village Project in Laos.
>
> Informal plans to use emerging wireless mesh technology to create
> cheap,
> robust connections in remote areas that do not have an established
> telecoms
> infrastructure. Each device on a mesh network receives and transmits

> its own
> traffic, while acting as a router for other devices; intelligence in

> each
> device allows it to automatically configure an efficient network, and

> to
> adjust if, for example, a node becomes overloaded or unavailable.
The
> advantages include ease of set-up, the ability to spread wireless
> access over
> a wide area from a single central wired connection, and the inherent
> toughness of such networks.
>
> Key to the Informal project is the development of a blueprint for a

> low-cost,
> wireless, rugged computing device which Informal will encourage the

> NGOs to
> develop and build. The so-called Autonokit will essentially be a
> low-cost
> computer that can work on non-standard power sources such as solar,

> wind,
> micro-hydro or even bicycle power.
>
> The Autonokit will run an open-source Linux or BSD distribution
> optimised for
> networking and auto configuration. It will be equipped with a 12V
> battery in
> case of power cuts, low wind or a fuel shortage.
>
> In an article written for CNET, UN secretary-general Kofi Annan
> spelled out
> the potential benefits that wireless and other technologies could
> bring to
> the developing world.
>
> "We need to think of ways to bring wireless fidelity (Wi-Fi)
> applications to
> the developing world, so as to make use of unlicensed radio spectrum
to
> deliver cheap and fast Internet access," he said.
>
> While providing developing communities with access to information is

> one of
> the main motivations behind the road-show, Crab -- whose
day
> job is
> at digital consultancy Lateral -- claims Informal's
> motivations are
> not purely altruistic. "A side effect of these projects is that it
> keeps us
> in touch with technical and creative developments in areas most
> companies
> don't look at, it keeps our roots in the real world," he said.
>
> Crab admitted that providing open access to information in some
> countries
> could be politically sensitive but he claimed that there is a lot of
> misleading information circulated about some countries approach
> controlling
> Internet access. "You have to be very careful about how you approach

> it but
> there are a lot of myths about countries such as China -- they
> actually have
> very free access compared to some places," he said.
>
> China has been heavily criticised by organisations such as Amnesty
> International for its attempts to censor Internet traffic and
> imprisoning
> several individuals for Internet-related crimes.
>
>
>
>
-----------------------------------------------------------------------

> -
>
>

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

15 dBi antenna with 10m Mil-spec co-ax before installation at Site no. 1, Lynnwood Glen (Andrew)
Posted by Hello

15dBi antenna (below TV antenna) mounted at Site no. 1 in Lynnwood Glen (Andrew). Directed to twshane access point in Menlo Park.
Posted by Hello

coin: testing image TX

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

Test email function [PLEASE IGNORE]

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