Turn-key Mesh Routing Access Point

IPSection writes "LocustWorld announces the release of MeshAP-05. This is a test release of a bootable CD which turns a single board computer or laptop into a mesh node and access point. Clients can sign on to the network, cells communicate to form a robust, dynamic, compressed and encrypted mesh network. This is a prototype release intended for the widest possible test. Feedback is encouraged." There are several interesting things on this site, actually -- check out the Swarm Chip.

Comments

my dream come true

[winse]

already slashdotted so I can't read it, but I assume that this means that I don't have to buy one of those fancy pants bridges to get a very large wireless network. I have wanted to build this with my friends to canvass an area around our university campus

Campus ?

[penguin_punk]

Can you just imagine 300 Dorm students with their own ad-hoc p2p network? It's too bad that the site's /.-ed, but I think a working application for this would be p2p networking within close proximity like a large University where the majority of the 'web' would be located around dorms, but several 'access points' on the outside of the larger hubs could connect local residents. Possible extending the network across town.

I'd hate to be the only sap between two large dorms - you'd be the gateway and could say good-bye to any bandwidth for yourself.

Damnit! Get that site back on-line. I'd love to test ths sucker out.

yowzers

[Anonymous Coward]

imagine a beawulf cluster of these!

The problem is . .

[GlassUser]

The problem is that the nodes seem to need to be in contact with each other, eg, one NIC per node, and you must be on the same channel as all the other nodes. While certainly useful, it seems to require a relatively high density.

http://www.houstonwireless.org/ and http://www.seattlewireless.org/ appear to be working on systems that work better in multihomed intelligently routed (well, assigned by a person and not guessed at by a machine - which is better may be up for debate) environments. Much less density is required in these types of situations, but near-universal is definately not guaranteed.

I'd like to see first, if this system can support multiple wireless nics, and second, how it behaves in a large scale setting. Second B, how does it work if you have a few directional antennae pointed at each other? The way most meshes appear to get around this is to set client-serving nodes in AP mode, and use ad-hoc for directional (routing) links.

This definately has promise.

Reconnect rate

[mmol_6453]

Just realized: Anyone know how quickly 802.11 devices can connect, authenticate, route and transfer? (in that order...authentication optional.)

Can it be done without loosing running TCP/IP streams, or will we start seeing a prevalence of UDP/IP embedded protocols with connection-owner-tracking methods built in?

And without the UDP/IP embedded protocols, DHCP would/will be a real PITA.

Re:Advanced wireless networking

[voidref]

And the
Wiki Wiki WAN mesh network project.

Cheapest Turnkey Hardware?

[Baldrson]

What is the cheapest turnkey hardware configuration that can operate this software (including CD-ROM drive and wireless card)?

System requirements - 64mb too much!

[no_such_user]

My wish: slim down the memory requirements. Before anyone flames me with "memory is cheap", consider this:

I've got a few idle P100 laptops sitting around. I don't know if the cpu is fast enough, but if it is, this would be a perfect application (especially since most people consider these things useless these days). My only limitation: older laptops like this one have limited RAM. If we could get this to run on 8mb, or even 16mb, I'd be a much happier person.

I suspect a chunk of this RAM is setup for a RAM disk. Perhaps a hard drive install could be an option?

Jeff

I could use this...

[ByteHog]

This is really cool. I'm the installer for a rural ISP in NE Washington state, and often times when I go out to do a site survey, a mountian or a bunch of trees will be in my way.

You can kinda see the view from our tower #2 in colville here. Pictures that I took while I was up replacing an antenna. Kodak DC280 for those interested.

Anyway, we have 2 towers in Colville, which covers most of the town. Although there are a few areas that we can't reach. If we were to put in several inexpensive (a major plus) micro-cells of these things to kinda float around large obstacles, then this is could be a good thing.

I'm going to play with this, although can't exactly use it in production...

Details about how it works:

[osolemirnix]

can be found in the Mesh AP Documentation.
Essentially all nodes that have an internet connection on eth0 broadcast the fact that they are a gateway into the real internet. This model extends by hops, out into the WIFI mesh network.
So all the system does, is route you to the internet via a path with the fewest hops. It does not provide interconnectivity between WIFI nodes themselves at all (they are all NATed). It does not provide a handover from one cell to the next as you move, so it just works for stationary nodes. It just offers a multi-hop VPN to the nearest AP with a "real" internet connection, adding a NAT layer with every hop out.
This is pretty cool, but still a far cry away from spontaneous self-organizing WIFI-only networks, where there is no "root gateway" and no hierarchy as in this case (which is one of the problems).

A short excerpt from the doc before it gets slashdotted:

The software provided, the "Mesh AP", is designed to be run on a node, eg a system designed to serve others. It has the dual purpose of also connecting in to the network. So even if you are just a repeater and using the software to reach the Internet, you are also providing an extension to the mesh and a standard DHCP cell for any non-mesh clients which wish to sign on.

The software boots, it then allocates itself an address, typically in the 10.x.x.x range. Initially the allocated address is random.

Then, it attempts to find an internet gateway, first probing 192.168.1.1/255.255.128.0 and then using a DHCP client on the Ethernet interface to try to sign on to a gateway. If no gateway can be found, the software considers that it has only wireless links and is a repeater-cell.

The cell starts an internal dns server and transparent web proxy on port 80 and 8080, a dhcp server is also started an a random class C network is picked in the range 192.168.128.0/255.255.128.0

Clients connecting to the dhcp cell are pointed to the wireless interface for default gateway and dns server. The dns server running on the repeater always returns the address of the gateway, no matter what domain name is resolved.

At this point, the node still cannot serve clients, but it will sign them on.

Meanwhile, the kernel AODV(11) module is loaded and the node then finds neighbour cells in its local range by sending/receiving UDP packets to the broadcast address.

Any cells within the mesh which are gateways, periodically broadcast a route to a bogus address which implies an internet gateway. This route is repeated outwards in a "ring" fashion as per the AODV protocol.

Any cell without a gateway receiving this address then attempts to establish a compressed encrypted IP-tunnel VPN via the "vtund" package. Compression uses LZO and encryption is blowfish. (ip ranges 172.16.x.x)

This IP tunnel could be over multiple hops to the destination gateway, AODV handles the optimised routing between linked cells. Eg, multi-hop routes eg.

The cell then switches all its outbound dns and ip traffic to go via this VPN gateway link. The DHCP configuration is also updated to now serve the remote gateway address as a dns server (gateway nodes run a real dns proxy) - Any clients who signed on before the link was found will forward traffic to the local cell which will proxy it via http proxy etc, any clients signing on after a gateway is found will receive the remote gateway details and will have full IP routing.

Any client signing directly on to a cell which has a local internet gateway will go directly via that gateway.