Mesh networking with multiple Raspberry Pi boards

Since he’s got several Raspberry Pi boards on hand [Eric Erfanian] decided to see what he could pull off using the robust networking tools present in every Linux installation. His four-part series takes you from loading an image on the SD cards to building a mesh network from RPi boards and WiFi dongles. He didn’t include a list of links to each article in his post. If you’re interested in all four parts we’ve listed them after the break.

He says that getting the mesh network up and running is easiest if none of the boards are using an Ethernet connection. He used the Babel package to handle the adhoc routing since no device is really in charge of the network. Each of the boards has a unique IP manually assigned to it before joining. All of this work is done in part 3 of the guide. The link above takes you to part 4 in which [Eric] adds an Internet bridge using one of the RPi boards which shares the connection with the rest of the mesh network.

The future, IMNSHO, involves mesh. Especially for areas with any manner of population density.

For instance: In the age of increasingly-pervasive bandwidth caps, why torrent indiscriminately from a machine on the other side of the pond when the same file is directly available a few hops away over WLAN from a dude down the block or elsewhere in the building?

In and around my house, in my not-so-dense neighborhood of medium-sized houses and big yards, I can find between 15 and 21 different access points that are obviously operated by my neighbors.

Extrapolated out a couple of hops, and one can form a sizeable mesh network very quickly.

Does performance degrade as it scales? Of course. But that’s why we’ve got things like QoS and TTL, to balance performance as it scales and allow folks to get the most of their own hardware.

AFAICT, this has all been fairly practical for a few years now. All that’s left is protocol support in applications and factory-made wireless gear.

Maybe for things that don’t use bandwidth, for anything else mesh doesn’t give enough umpf, and you forget that “over the pond” isn’t a good measure there have been many instances were we went over the pond and back again just to route between different operator.

I took a course about cloud computing concepts on coursera a few months back, where I was introduced to the concept of small world networks. I don’t think networks are that hard if you let them self-organize.

The problem, IMO, is caused by commercial constraints. You can’t easily charge/split the money if data is allowed to flow freely, wherever it finds a shortcut.

With mesh networks and most data living on torrents, we’d probably need to increase storage several times (but storage is cheap) and get better performance than we get now with the high bandwidth trunks between operators/huge Internet exchanges.

I hear apple wants to move away from intel completely and AMD gave themselves over to JP morgan for a possible sale (or in other words is committing harikiri), coupled with a windows8 version for ARM made it seems ARM might be the future of CPU’s.
So it might be a good time to start developing for it eh.

I’m not convinced ARM can do it, but I think the intel architecture might be getting a bit dated and a million extensions is not necessarily helping things really, not as much as you’d hope/expect. The problem might be the legacy expectations causing them to have to stay too much stuck in some areas as opposed to what you’d get if you started with a clean ship.

But these things aren’t decided by a single person after long thought but by many factors and sales and money and patents and old software and all that. The old betamax vs VHS (vs v2000) effect, it’s not always about technological superiority, quite the opposite even. And as outsider all you can do is roll with the punches.

Question: Could this set up be used to connect about 2300 Raspberry devices that are all clustered fairly close together? Trying to eliminate a network wiring issue (small space for wiring conduit — old system used a serial bus approach). Thanks!

Depending on your environment, get ready for a maintenance nightmare. I have installed about 100 devices, daisy chained and not, the issue isn’t the theoretical “Could/Can/If”, but the reality that these things break, require upgrades and other maintenance. The biggest benefit is cost, but when one goes offline, you have to pay someone to physically replace it. That, for me, is the main issue right now. To answer your question though it – it works and works well. It solved a huge problem for me of having unreliable network connectivity. It also streamlined the commissioning process since the /etc/network/interfaces file is identical on all devices [well, not exactly, but close]. If I were you, I would test it out on 4 or 5, then 20 or 30, then ramp to 100ish. There are lots of pitfalls before you get to 2300, as I’m sure you can imagine. Good luck!

Hi Mike! Firstly, thanks a lot for responding to my comment wayyyyy after the article was written!

My use-case is that these units will be in a seating theatre and only used once per evening for 2-3 hours (at most). They would be powered off after the performance. During the day, there are extensive opportunities to do testing and replacements with on-staff folks who would do the testing and replacing.

The other track that I’m looking at is RS485 with something like Modbus running on them, because RS485 is a multi-drop protocol, it’s better than 10Base-T in that regard.

Can you guess what your MTBF is on a single unit? The mesh network approach is intriguing because it will utilize a little usb wifi dongle, and it will eliminate all of the RS485 data wires that would have to be run, potentially fail, and the higher level networking that is necessary on RS485 compared to the mesh wifi approach.

What do you think? I’d welcome any opinion of someone who has been-there/done-that with these things.