Richard Stallman, Father of the Free Software Movement

Dr. Richard Stallman, the father of the Free Software Movement, has joined the advisory board of the Free Network Foundation. Dr. Stallman has been advocating for software freedom since 1983, when he launched the GNU Project. He is president of the Free Software Foundation, which he founded in 1985 to promote and defend the freedom of computer users.

Rms will help guide the Foundation as we continue the struggle for liberty in the digital age. His willingness to aid our cause is humbling, and his advice is full of careful and valuable insight. We look forward to working with Richard to build freer networks and a freer world.

If you are willing to join us in our struggle, engage us in the forum, through the wiki, or on our discussion list.

There is lots of hardware out there that can operate at these frequencies, and with the proliferation of Software Defined Radio, it is often simply a matter of updating the radio firmware. We look forward to doing our first 3650 experiments in the coming days as we deploy the core infrastructure for our Kansas City research network.

Our e-mail newsletter, FNF-Announce, is finally coming into use. You can sign up here. This marks the end of several months of inadequate e-mail communication, which started after our old email list, FNF-Discuss, became overcrowded. The membership of the Discuss list has been moved to Announce, and Discuss will be reborn as the forum for discussion which it was always intended to be. You can sign up here.

The first full meeting of our Board of Directors will happen this month. Our application for tax-exempt status is progressing. We are in negotiations to acquire office, server, and antenna space in Kansas City’s Old Southwestern Bell Headquarters (pictured).

The Old Southwestern Bell Building

Much of our work over the past quarter has been in making sure that we have a stable foundation for long term growth. That means building out tools for network management, establishing a sustainable funding model, making sure that appropriate structures of governance are in place, and ensuring that we have effective means of communicating to stakeholders and constituents. We have executed against these deliverables in a way that is timely and transparent. Let’s take a look at everything we got done in the first three months of 2012:

• Moved our base of operations from Brooklyn, New York to Kansas City, Missouri.
• Made massive strides towards full release of the FNF Network Operations Center. This suite of tools will allow network operators around the world to have access to carrier grade tools.
• Built a solid base of paid members.
• Expanded our core team of organizers and engineers.
• Pablo Varona Borges joined the team as Director of Education.
• Joshua Mercado joined the team as CIO.
• Martin Dluhos joined the team as a systems engineer and administrator.
• Built membership to Core and Builders emails lists, migrated from Discuss to Announce.
• Applied for 3650MHz license.
• Relaunched the FNF website.
• Enhanced navigation (makes it far easier for folks to engage with FNF)
• Open video formats
• Improved wiki
• Deployed CRM
• Deployed PHPlist
• Got our board of directors spun up.
• Isaac Wilder (Chair)
• Gregory Foster
• Patti Wyble
• Tyrone Greenfield
• Venessa Miemis
• Got our advisory board spun up.
• John Stone
• Jon Lebkoswky
• Jeff Sterling
• Paul Garrin
• Devin Balkind
• Streamlined our business operations by eliminating excess overhead.
• Canceled VPS
• Cancelled Clear modems

I recently got the chance to hear their story for the first time.

For more than 15 years, name.space has been asking why the ICANN Root domain is so closed.

In some ways, I really do think it’s the fundamental question of our time — who will make names on the network?

I just want to say thank you to our friends at name.space, for not backing down, and recommend that folks take a look at namespace.us. You can follow the instructions there to make it so that you can go to starbucks.sucks and see a picture of Reverend Billy being awesome (among other hidden marvels of the web).

We’ve been overwhelmed with an outpouring of support and encouragement, and want to thank everyone who has helped us get to where we are. We also want to assure you that there are big things in store for this spring and summer. Planning for a wide-scale demonstration network in Kansas City is well underway. Yet, we need to ask for your help. Changing the political economy of our communications systems is going to take all of us, working together. If you’re a network engineer, please get involved.

If you’re not a network engineer, but you still care about the future of the Internet, please consider becoming a member of the Foundation. You’re free to give as you please – we’d just like to let you know that committing to small monthly payments would be very helpful from our perspective. That would help us manage cashflow, and build a sustainable base of support. WePay allows you to specify a recurring donation after you pick an amount, so please keep this in mind when you decide to contribute. The link to our WePay is here.

We’ve been hard at work these past few months, reaching out to communities and building the organizational structure that we’ll need in order to be successful long-term. We’re going to keep at it, no matter how long it takes, because we know that the world needs this. We thank you for your interest and support, and we look forward to working with you to build freer networks, and a freer world.

glad tidings,

Isaac Wilder, Executive Director of the FNF

This

This research definitely calls for further investigation.

Original Article from 2007

-Tyrone

I

In November of the year just past, there was a sudden explosion of interest in the prospect of building a global-scale communications network that is owned and operated by participants in the network. Much confusion ensued, and the idea remains mostly opaque or misunderstood. On the 26^th of November, a graduate student by the name of Shaddih Hasan posted a piece called ‘Why wireless mesh networks won’t work to save us from censorship.’ The piece listed five reasons why “unplanned wireless mesh networks never work at scale” – and used that relatively well-supported claim to warrant the assertion that building peer-to-peer communications infrastructure is a waste of effort and time.

My name is Isaac Wilder, and I’m one of the Directors of the Free Network Foundation. Along with my partner Charles Wyble, and a global network of volunteers and contributors, I work on systems and network architectures for what we call free networks. Our technologies will enable the construction of networks belonging to no one and everyone at the same time. I’d like to take some time now to respond to Hasan’s claims, and explain how mesh networks can and must be used, not only to save us from censorship, but to reclaim the notions of community and trust which current architectures put in grave peril.

If you haven’t read Hasan’s piece, you may want to do so now. It is available on his blog. It’s well argued, and points out some of the many challenges in the implementation of unplanned, large-scale, wireless mesh networks. I do not mean by my dissent to suggest that these challenges are of no importance – they are, rather, key considerations in the design of free networks. I do mean to suggest, however, that these challenges are not insurmountable. What Hasan has shown us is that RF signal is a relatively unfriendly networking medium, which is not to say that radio waves cannot or should not be used to build a new type of network.

It seems to me that Hasan has misunderstood the intent of this new wave of free network activism. I could not possibly speak for a diverse and heterogeneous community of activists, but I will speak on behalf of the FNF, which endeavors to fight censorship using mesh technologies. While Hasan’s technical critiques are generally well-founded, they are also overstated. He attacks a falsely simplified understanding of what a global free network would look like. Furthermore, and finally, the piece culminates in a string of fallacious philosophical and political assertions for which he has presented no relevant evidence.

Now, let’s take the technological claims one at a time. Then we’ll work on understanding what is actually being proposed, and how Hasan’s points don’t really speak to it, before examining the politics of censorship.

II

Reason 1: Management is hard and expensive.

The first reason, we’re told, that one shouldn’t use mesh networks to build cooperative, autonomous systems is that “you’re going to spend all your time just maintaining basic connectivity.” Hasan paints a picture of mesh networks plagued by “transient connectivity problems resulting from RF weirdness in urban areas.” He points out the necessity of traffic shaping due to bandwidth constraints, and offers up the example of a Tibetan mesh which made a move toward a point-to-point architecture as they tried to scale.

Response 1:

While it’s true that management of mesh networks takes effort, it is not true that such management is impossible for a group of volunteers, let alone for a team of professionals. The claim that the Tibetan mesh highlighted in his article was the largest in the world is unsubstantiated. Hasan even mentions a couple of larger, volunteer-operated, city-scale mesh networks (Freifunk and Athens Wireless), but fails to reconcile their ongoing success with the above statements. Mobile Ad-Hoc networks do entail a certain amount of overhead, but they also have definite advantages. Ultimately, such technology is useful when applied in the appropriate situation, and cumbersome when used inappropriately.

Reason 2: Omni-directional antennas suck.

In reason two, we learn that “Omnidirectional antennas are very inefficient, since they throw your energy (i.e., signal) all about, when in reality you just want your signal to reach the handful of nodes nearby.” We’re told that if “Even if all 15,000 people on the Darknet subreddit could install and maintain 10 devices, they wouldn’t cover all of Wichita, KS, not to mention the miles of farmland between it and the next town.”

Response 2:

Again, there’s a kernel of truth here – omni-directional antennae have certain inefficiencies. They also have practical applications that outweigh those drawbacks. To say that omni-directional antennas suck is a pretty obvious overstatement. To say that they need to be used appropriately would be more reasonable.

And then, of course, there’s the assertion that 150,000 network nodes would be insufficient to cover Wichita, KS. This claim is baseless. By any reasonable estimation, that number of nodes would be an order of magnitude greater than the number needed to make coverage available throughout a mid-size city. This is true even if one considers a node to be just a Linksys WRT54G. For reference, Athens Wireless Metropolitan Network reaches an area 110km tall and 85km wide with fewer than 4,000 nodes – Wichita is smaller than 20 kilometers square. Start considering licensed, point-to-point links, industry grade gear from Ubiquiti and Microtik, or wired backhaul and suddenly the 150k node number’s not one order of magnitude off the mark, but two. Fermi would be pissed.

Reason 3: Your RF tricks won’t help you here

The third reason why we’re supposedly doomed is that it can be hard to get radios to communicate with one another, even with high-gain, high-power, or directional equipment.

As regards omni-directional antennae, we are cautioned that higher gain means an elongated beam – further reach, but a smaller margin of error in terms of node elevation. Think of it as smooshing a donut – the diameter goes up, but the height goes down: “the higher gain you go the thinner the disc gets.”

As regards directional antennae, we’re led to believe that they aren’t really useful in the creation of mesh networks. They focus the beam, and so they have to be aimed correctly before they can communicate with a neighboring node, “eliminating a key property of the mesh network”.

Finally, as for power amplifiers, we are told that “They only boost transmit power; the real limitation is receive sensitivity.” Furthermore, we are told, they are power-hungry, and expensive, and restricted in their operation by legal limits.

Response 3:

The main thrust of this response is the same as my last one – yes, there are some truths in what Hasan says, but those truths are exaggerated, while salient facts are willfully ignored. High-gain, directional, and amplified transmissions are not cure-alls, but they are certainly useful, and do make it possible to build cost-effective, scalable community wireless networks.

High-gain omni antennas are terrifically useful for those radios serving as access points, allowing you to cover a large field or floor with a single point of presence. With a small amount of coordination and planning, it is possible to use such antennae to great effect, covering a wide area with relatively few networks nodes.

Directional antennae used at microwave, millimeter wave, and optical frequencies are profoundly powerful pieces of technology, allowing gigabit throughputs and very long range hops (100+ km). Hasan doesn’t even mention the notion of using directional, point-to-point links to connect disparate pockets of a community network – he disparages the technology for not doing something that it’s not designed to do, while completely ignoring its actual uses. It’s true that point-to-point links are generally dependent on line of sight and are susceptible to rain fade, but it seems odd, given his organization’s experience with the technology, that he did not mention its potential.

Finally, there’s power amplification. We are told it’s of no use, because of the constraints of receive sensitivity. In certain situations, this is true – when trying to interact with client devices, for example, or when network hardware is mixed. In other situations, however, increases in transmission power have a considerable effect on network throughput. The problem of receive sensitivity is only relevant if the increase in transmission power is unilateral – if, on the other hand, all neighboring nodes increase their power as well, they can be placed farther afield. It is true that there are legal limits on transmission power without a license (1 Watt in the ISM band), but it is also possible to obtain licenses for higher transmission power, in less polluted bands.

Reason 4: Single-radio equipment doesn’t work; multi-radio equipment is very expensive.

Here, we’re given a rundown of some of the basic technical hurdles that constrain mobile ad-hoc networks. The first hurdle with which we’re presented is the half-duplex problem, which limits the usefulness of some consumer wireless gear in the construction of mesh. The gist is this – nodes with only a single radio transceiver can either transmit or receive at any given moment, but cannot do both.

There is also the problem of interference between two nearby nodes that transmit at the same moment, on the same channel. While the half-duplex problem can be solved by using network nodes with multiple radios, the interference problem is a bit stickier. Hasan points out that radio transmission scheduling and spectrum allocation are NP-hard problems – that is, they’re really freaking hard.

Response 4:

If the half-duplex problem is the “the biggest technical reason mesh networks don’t work for Internet access,” then we’re in good shape. It has a very simple solution – use full-duplex, multi-radio nodes. Hasan says that “a network of multi-radio devices quickly becomes very expensive” but doesn’t give any facts or figures to back up this critical assertion. In fact, multi-radio hardware has become more affordable in recent years, and becomes more so all the time. High quality Atheros-based radio modules are now available for under $100. Hasan seems to forget that this is high tech, and that innovation moves at a breathtaking pace. What was unaffordable just five years ago is now within reach. Given a few more years, it will be commonplace.

Now, that’s not to say that a mesh made of multi-radio nodes doesn’t have some wicked transmission scheduling and fequency allocation problems. Time division multiplexing is a complicated process, to say the least. Still, Hasan makes it seem as though there’s no workable solution to the problem. This is not the case. The theoretical complexity of transmission scheduling and spectrum allocation have less to do with working, practical solutions to these problems than you might think. Multi-radio mesh networks can not scale infinitely, but they can and do scale enough to useful in the creation of free networks.

Reason 5: Unplanned mesh networks break routing.

The problem of routing in mesh networks is a complicated one – “There are many protocols for mesh routing, like AODV, OLSR, and BATMAN. Fundamentally they require individual nodes to communicate with each other, which not only takes up further network resources, but also means that achieving a consistent routing state (i.e., one in which packets won’t get routed into black holes or loops) is extremely difficult for all the reasons distributed systems are hard to build.”

Nodes move around, in and out of range of one another, and routes through the network need to be recalculated and shared when there are changes in the state of connectivity. This introduces the considerable problem of routing overhead – network resources that have to be used just to maintain the network. What’s more, “The unplanned nature of a grassroots mesh network exacerbates this problem, since poor RF-level connectivity means the connectivity state between nodes changes frequently, leading to more routing overhead in the network. It’s a bad cycle.”

Response 5:

Hasan is right about one thing – nodes in a mesh network do need to communicate with one another to share routing information. Beyond that, his analysis of the problem is underdeveloped and out of date. He mentions AODV, OLSR, and BATMAN, but fails to mention Babel, a higher-performing protocol whose daemon recently made it into the mainline linux kernel. He mentions the problem of routing loops, which plagued early implementations of mobile ad-hoc routing systems, but fails to mention that current algorithms are able to virtually guarantee the absence of loops. Mesh routing is complicated, but certainly not impossible – the state of the art is already sufficient for production environments, and is improving all the time.

The argument that mobile ad-hoc networks do not scale because of routing overhead is old and stale. This is the single most commonly heard ‘evidence’ against the idea that mesh networking has a significant role to play in the future of human communication. The problem with this line of argument is not that it’s wrong, it’s that it fundamentally misunderstands what we are trying to accomplish. We are not trying to build a horizontal global mesh. We are trying to build a global free network, consisting of interconnected pockets of mesh. We don’t need mesh to scale beyond a few thousand nodes, which it can already easily do.

III

Having countered Hasan’s arguments against the feasibility of a free network, I’ll now take the opportunity to briefly explain what a workable design for such a network might look like. This is a very brief rundown on what we call fractal mesh – for more info, see our article on the ends and means of our movement.

The design has three basic building blocks. The FreedomNode is a small-form home server with three radios. The FreedomTower is a neighborhood network manager, caching-proxy machine, and traffic aggregator with omni gear for communication with nodes, and directional gear for communicating with other towers. The FreedomLink is a BGP-speaking rackable router connected to directional radio gear (on the roof) so that it can talk to towers. All of these machines would have Ethernet and/or optical connections in addition to their wireless interfaces.

FreedomNodes would mesh together, using both wired and wireless media, to form neighborhood networks, roughly the size of a census tract. Because the nodes are servers (think of a diaspora pod), rather than just clients, it’s not just routes that are distributed, but user data itself. This enables communications which are peer-to-peer not just in the abstract or logical sense, but in the sense of material reality as well.

Each neighborhood network would have one or two FreedomTowers, designed to interconnect neighborhood networks. Just as nodes form a neighborhood area network, towers would form a regional area network. Towers would allow communities to buy backhaul circuits cooperatively from the start. Eventually, with increasing density in the free network, towers would be able to establish a connection to a regional FreedomLink. A full build-out of national free networks might entail 75,000-100,000 such towers.

Finally, within a regional network there would be one or two FreedomLinks, capable of peering with exterior networks, free or otherwise. Neighborhood networks would band together to form cooperative Autonomous Systems and run their own link. A national free network would comprise of about 100 links. Neighboring regional cooperatives would band together to build, buy, or lease lightpaths between links.

So, you see, the idea that “unplanned wireless mesh networks never work at scale” does not actually speak to the feasibility of our undertaking. Building a free network is not reducible to the concept of building a global mesh network, though well-designed mesh networks will play a part. There are many challenges ahead, both technical and political in nature – but with dedication, our goal can be achieved. It must be achieved – for our natural liberties cannot otherwise be won.

IV

The final issue that needs to be addressed is the suggestion that folks who are interested in horizontal, distributed, and free networks would better spend their time politicking. The crux of Hasan’s argument against our work “is that it appeals to the problem-solving oriented nature of many of us who are interested in Internet free speech, thereby distracting us from pursuing other more effective means of protest against censorship.” I see a few problems with this position.

First, it makes the fallacious assumption that those who spend their time engineering free network solutions are not, and can not be, engaged socially or politically. This is not so. Hacking on mesh tech no more precludes political activism than hacking on Tor or GNU. I fully agree with Hasan that there are crucial political aspects to the struggle for digital self-determination. Yet political engagement alone is not enough. We must build, demonstrate, and demand our right to operate systems that allow us to connect directly to our neighbors without having to go through a corporate middleman.

The second problem with Hasan’s thesis is that it woefully overestimates the health of the western polity. The “more effective” remedies offered by Hasan are political engagement, awareness/education, and community action. Unless they are coupled with the creation of alternative infrastructure, his suggestions constitute no remedy at all. We must build precisely because our system of government is fatally corrupt. Congress passes odious and unpopular legislation at every turn; they are beholden to those that finance their campaigns. We can tell our friends and family about SOPA, DMCA, or PROTECT IP until we are blue in the face, but it is clear that our so-called ‘public servants’ will continue to pass laws that benefit special interests, rather than the populace. Of course, Hasan is absolutely correct in suggesting that we “form real-world communities, and work with them to fight for Internet free speech” – that is exactly what we are doing. To suggest that we should form communities when we are already doing so seems confused.

Hasan wisely warns us that “Censorship is broader than just Internet free speech: it is a social problem that has existed long before the Internet ever did and will continue even if the Internet dies.” It is true that censorship has been a problem since before the birth of the Internet. It is also true that we need to maintain social and political pressure on our public servants and corporations. What is false is the assertion that building free networks is somehow opposed to the maintenance of such pressure, or that such pressure is sufficient in and of itself. Sadly, Hasan closes his article with a dangerous falsity, saying that “The only way to really address root causes is to engage with the problem at the social and political level.” What is false here is the notion that we cannot combat censorship by technological advance. Buckminster Fuller said it best: “You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” Human history is full of breakthroughs that have increased our ability to communicate freely. I hope that this response has helped elucidate how the construction of robust, reliable and useful free networks is not only within reach, but essential. The dismissal of such an endeavor as a waste of time indicates that our aims have been misunderstood. So, rather than effectively concede a struggle which has barely begun, I invite Mr. Hasan to join us as we build networks for the future – ones that are owned and operated by the people. Our development roadmap is here. There is very much to be done.

So what did we do in 2011? The following is in rough chronological order:

• Isaac and Charles officially launched the FNF and had a week long summit to work through many of the details, come up with network plans, research hardware, figure out levels of the network etc.
• Isaac traveled the eastern seaboard and abroad to raise awareness and funding for FNF.
• Designed, built, deployed, tested, tweaked, revised three radio towers directly (two for OWS (including one taken during the OWS raid), one for OccupyAustin) and provided engineering, design and implementation support for two more (Los Angeles and San Antonio). That’s a total of 5 towers. 4 of which are in operation.
• Awarded 10k innovation award at ContactCON at the end of October and a good amount of funding throughout the year
• Received quite a bit of publicity in leading online publications and developed excellent relationships with online and print media
• Deployed a beta of our Network Operations Center with full production release scheduled for end of January 2012
• Deployed a beta of our Development and Test lab with full production release scheduled for end of January 2012
• Assembled our executive leadership team (CEO/CTO/CIO/CFO/COO)
• Put together a list of candidates for a board of directors and an advisory board.
• Held a year end summit and review. Figured out a lot of logistical issues and also planned out re launch of website and did a lot of design work on FreedomNode. We also took steps to eliminate single points of failure on the executive leadership team. We now have technical/legal/operational/financial redundancy.
• Published our roadmap to a 1.0 release of the FreeNetwork stack (our 2012 plan)

So what is ahead in 2012?

• Our focus in January will be on finishing up the last pieces of scaffolding work for mass participation. Things like the NOC/Lab being completed and opened for use and our corporate structure to be fully operational. This includes things such as financial transparency, being able to accept non profit donations, legal things related to being a company etc.

• Our focus in February will be on deploying our single sign on, one time password, authentication platform and getting folks to deploy a VM image which will replicate the one time password system. It will be a globally distributed, peer to peer architecture, highly available, democratized identity ownership platform. This will be our first release to end users. The authentication system is the first piece of the network. We also need to publish the tower plans and support an emerging community of builders and early adopters.

Beyond that we will be proceeding against our roadmap and building lots of cool stuff!

After a very successful strategy and year-end review summit in Austin, we wanted to give you all a little insight into what we’re cooking up with regard to the FreedomNode. If you’re not already familiar, the FreedomNode is the foundation of the Free Network technology stack – a device that will allow neighbors to communicate with one another directly, without need for a paid service provider. We think of it as the ultimate sharing machine, allowing you to privately store, selectively distribute and globally publish a wide range of materials, using a variety of connectivity options.

Lets start with the user experience, and from there we can seek to understand the technical aspects. For the time being, we’ll talk only about the experience of the node as a standalone device, and exclude the (likely) possibility that some users will boot the software on existing machines. The node presents a uniform interface across client devices using HTTP(S) – a collection of stylesheets allow the interface to adapt successfully to a wide array of different screen resolutions and input methods.

In simple terms, you interact with your node by opening a browser – any browser – and navigating to your node’s address. That address can be a global name such as a user-owned DNS entry, or a third-party subdomain such as username.fnf.tel, or, from the same local network, a local address, such as ‘https://mynode’. Alternatively, the node can be accessed from its unique IPv6 address.

Navigating to the address of a node prompts the user to authenticate. This is done using the F-Pass system. F-Pass is the key to trust and addressing on the Free Network – tying together x.509, PGP, IPv6, and secure, one time passwords.

Once authenticated, the user is presented with a main menu that provides access to all of the essential functions of the node. Icons exist for Blogging, Microblogging, Planning (like plans.txt on Unix or GrinnellPlans), Mail, and an A/V Center (photos, music, video, and files). An additional icon leads to a list of contacts, with a final icon leading to system settings.

Users can be organized into aspects, with a ‘Neighbor’ aspect generated automatically for those with whom you can communicate without need of an Internet Service Provider.  From the contacts page, a user can access the blog, microblog, plan, or shared media of another user. Users have precise control over who can access each piece of media on their node. Sharing is encrypted by default, anonymized when desired, and opportunistically peer-to-peer – that means that we all cooperate to move each others’ messages, when it is possible, rather than paying a professional bit-mover

Now that we’ve established what the node is designed to accomplish, let’s talk about its actual design. At the core of the FreedomNode is a small-form computer, designed to run continuously for years on end. The computer’s onboard capabilities can be expanded with USB mass storage, and miniPCI radio modules.

On bare metal, the node will run genode, a novel GPL operating system architecture that allows for true fault isolation and tolerance. On top of that, a lightweight debian install will be used to ensure long-term package support and stability. The user-facing services run on top of Debian, powered by a collection of existing open-source daemons and tools. These services benefit from the tight integration of a unified interface and a unified authentication and identity management system.

Add to that the ability to communicate without using the telco’s wires, and you’ve got a truly disruptive piece of tech. The Byzantium Project has built a solid foundation for mesh communications – their routing scheme (based on the babel protocol) will be integrated with nodal services so that local traffic never has to leave the neighborhood network. There is much to do, but we aim to have the FreedomNode ready to release in 18 months or less – join us now, and help us build the greatest tool in the liberation technology toolkit.

It’s currently located in my home in Austin TX. Currently it’s not available for mass use. We need a bit more infrastructure in place before we can open it up for folks to use. Expect a blog post in the near future with a call for participation.

So what is in the lab?

Lab Hardware

Routers:

• Cisco 6509
• Cisco 1841
• Cisco 3540

Switches:

• Cisco 2950
• Cisco 2924

Access Points:

• NS2
• Mesh potato
• Linksys repeater
• Orinoco 802.11b
• AirLink

Computers:

• Optiplex 745 VM server (lxc/virtualbox)

This is used for several functions

• VirtualBox host to run PfSense virtual machines so we can test out configurations, test compatibility with Cisco gear (OSPF/BGP)
• VirtualBox host to run FreedomNode virtual machines (with a genode base, and Debian guests)
• LXC host to run GIS and other computationally intensive work loads in support of FNF network operations
• LXC host to run various software packages / experiments (very early stage FNF software application research projects)

The system has a USB bluetooth adapter. It also has multiple 802.11b/g USB wifi adapters.

• ASUS EEEPC