Welcome to the CSIR Meraka Institute's "COIN" Blog

Tuesday, September 28, 2004

The revolution has begun

Here is a list of all the people registered on www.nodedb.com in Johburg and Pretoria with wifi access points. Disorganised collection of people with all sorts of AP's - no one doing any meshing as yet. Question is - does the CSIR reveal their network to the general population - register on nodedb.com?? Security issues could prohibit and we have a different purpose - namely Removing the barriers to enable bottom-up creation of access infrastructure through use of wireless mesh netwirking - their purpose is similar to CB radio - just make a community network. It might be good though to involve a few of these nodes in Pta if the can help on linux/linksys coding side - we could isolate them from the csir network.

List of all active Pretoria nodes

List of all active Johannesburg nodes

Also thanks Albert for pointing our JAWUG (Johannesburg Area Wireless User Group)

The vision of JaWug is to create the largest Community run Wireless Network in the Johannesburg area.

JaWug is a not-for-profit effort to develop a wireless broadband community network in Johannesburg - a free, locally owned wireless backbone.

To get aroung any legal attacks they put a discalimer on their site: Please Note: We do NOT sell Internet connectivity!

There is also a lot of actiuvity and interest in Pretoria - apparently a network called FreeNet - can't find a URL - found this long discussion on the south african myadsl forum

Discussion about sharing ADSL through WiFi in Pta

Wednesday, September 22, 2004

Here's an idea for assigning IP addresses to houses

Got this idea from CU wireless

"We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in 'reading order.' That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16. (We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.) The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24."

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

Monday, September 20, 2004

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. Posted by Hello

Mounted on a camera stand... Posted by Hello

Close-up of the feed element Posted by Hello

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. Posted by Hello

Thursday, September 09, 2004

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
MIPS processor. Here are a couple links to the meshcube:



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,

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

Wednesday, September 08, 2004

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

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

Tuesday, September 07, 2004

Message sent to Kevin Grace at MITRE

Dear Kevin Grace

The CSIR in South Africa is an organisation much like yours with a vision of using multidisciplinary engineering and scientific research in partnership with government to address issues of critical national importance - which in our case is addressing problems from the legacy of an apartheid government such as poverty, job creation, and addressing the lack of good health and education facilities in disadvantaged communities.

Some of the areas that we are addressing are the lack of telecommunications infrastructure - particularly in the rural areas of our country. We are busy exploring and researching the idea of communities building their own infrastructure using Wifi mesh networks as a basis on which mini community owned wireless networks will be built.

Mobile mesh naturally caught our interest and we have been experimenting with it on Linux PC environments. We have also made a port of mobile mesh which compiles on a FreeBSD machine which you might be interested in.

We have purchased some Linksys WRT54G wireless routers which have cuaused quite a storm due to their low cost - approximately $90 for a device which includes a 200MHz MIPs processor, 32M ram, 16M flash and built in 802.11b/g and it is packaged running a thinned out version of Linux. The entire source and build environemnt is also made available by Linksys under GPL - which creates exciting opportunities to add your own custom software such as mesh protocols and congestion control etc.

Our next task is to port mobile mesh to this MIPS based Linksys wireless router. Our first challenge is getting a c++ cross compile tool chain with stdlibc++. This has proved quite a challenge. Has any effort been made to move mobile mesh to pure ANSI C code or to cross compile it for an enviroment such as this.

We would also like to explore the possibility of collaboration with your organisation in the field of wireless networking - we have been working in this area for the past 10 years and their might be some good synergies and shared learning.

Best Regards

David Johnson
ICT for development Infrastructure
Information Society Technology Centre (ISTC)
Icomtek CSIR South Africa
Phone: +27 12 8414266
Fax: +27 12 8414829
Address: PO Box 395, Pretoria, 0001

Monday, September 06, 2004

mesh on linksys - comments from sveasoft

On Sat Jan 10, 2004 sveasoft placed the following poll on their forum: should we build a WRT54G mesh box?

How many folks would like to see a fully interconnected wireless mesh based on the WRT54G?

This would require dumping the WRT54G application source tree and starting anew with an AODV port and some tricky routing daemons built from scratch.

The result from the user base was 79% were for it and 20% were against it

Some highlights from the respondants

Posted: Fri Jan 30, 2004 16:44

I would be *very* happy if that could be implemented. Why not using "mobile mesh" from http://www.mitre.org/work/tech_transfer/mobilemesh/ ?
I've only heard nice things about it (e.g. finds other nodes swiftly, uses wired links (via so called border gateways) to decrease the load on the wireless links if necessary etc.)

There are quite a few initiaves in several towns who want to build up free networks. Meshing is one of the things very much needing!

Posted: Wed Feb 04, 2004 22:23

I'd love to be able to setup my WRT54G as a mesh-capable box. I had looked into running the locust software a while ago, but my hardware (an older model laptop) wasn't up to the job. But perhaps more importantly, I didn't have anyone else to connect with! If a widely available box like the WRT54G supported meshing, there'd be a far greater chance that others in the area would spend the $80 (on the box) to join the network.

My fantasy world would have a few dozen meshing boxes around the city, all forming a private network. Other mesh servers could join the mesh without pre-coordination (though there would be protection against rogue-meshboxen trying to DOS or whatever). Clients could roam easily. If the box was connected to the Internet, you'd have the option of sharing it publicly to locally connected clients only, publicly to the whole mesh, or privately (through the mesh) via ipsec/pptp/whatever.

Posted: Wed Feb 04, 2004 23:05

I would absolutly LOVE to see mesh on this device. Locustworld would be nice
as it would allow already deployed networks to add this unit. IMO there needs to be a way to control what channel the mesh lives on. You do not want the entire mesh running on 1 channel. You want to beable to make sectors and have gateways that transport between the two. Locustworld is in the best position to develop such a item due to there central registration and configuration setup they have.

Posted: Wed Feb 04, 2004 23:19

Posted by sveasoft again

We are looking at using IPv6 and incorporating the Ethernet MAC so we won't need to interact with IANA or any other central body.

At this point I think we will stick with BSS mode and use WDS for the links, depending on what limits we find while developing and testing.

This will mean the mesh build will support all 802.11b/g clients out of the box rather than requiring adhoc mode.

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

-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
-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:
near the bottom

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

I really think with wrt54g you can have two, and the reliablity is to use
multiple units for redundancy, because there cheap.... Wink)

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


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.


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 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. 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. Errors and Warnings in File BoBorder.h
: “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. Errors and Warnings in File LnDiscover.h
: “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. 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. Errors in Parameter Arguments in File UtDebug.c
: 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. 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). 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)


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