Raspberry Pi as a “Wifi Closed Cloud”

By Dr Michael Dye.

This is a mix and match of various technologies and walkthroughs to use a Raspberry Pi to create:

  1. A Wifi hotspot

  2. A closed network: DHCP and DNS on the Pi, for the Wifi network only

  3. A web site running on the Pi available to this closed network

Hence the idea of a “closed cloud”. Why? Think of a public space; where people have Wifi mobiles or tablets (or laptops or whatever); and think of them connecting to this Wifi and browsing the web site. Which could be providing all sorts of information related to the public space they’re in. A web site with endless possibilities but no danger of outside interference or unrelated (or unwanted) browsing – as it’s not connected to the big WWW.


I do like that word

  1. A Raspberry Pi

  2. Internet/Network access (for all this setup)

  3. Some PC with SD card reader/writer & the ability to run an SSH terminal; plus to go to all the web sites listed here

  4. SD card (I used 4GB)

  5. Keyboard/mouse for the Pi (optional, not needed once things are running!)

  6. Wifi USB adapter for the Pi (that supports access point mode)

  7. Some LEDs, wires and switches (if you’re to go the whole way!)

And; to make life easier – a read through of https://www.pi-point.co.uk/documentation/ which is what forms the basis for a lot of this; and will help if I skip things ‘cause they’re obvious (to me…)

And #6 above contains a key phrase – the Wifi adapter must support access point mode (see Pi-Point for more on that) - *and* you need to know a bit more about the Wifi dongle; which will become clearer later on – though my approach was ‘try the alternatives until one worked’.

First steps; Raspbian up and running

Download the latest Raspbian image from the Raspberry Pi foundation (http://www.raspberrypi.org/downloads/) – I’ve gone for the Debian Wheezy rather than NOOBS.

Follow the links on that site to get hold of Win32DiskImager and use that to “image” your SD card.

Boot, configure, reboot

Plug the SD card in to the Pi, boot the Raspberry Pi and set up the basic stuff (via the raspi-config; so a screen and keyboard plugged into the Pi makes this much easier!):

Again – for more detail see Pi-Point which shows how to do this using SSH

Terminal: puTTY

PC users; get hold of puTTY if you haven’t already – or use an SSH terminal of your choice. That’s just easier to SSH into the Pi than doing it all from the Pi keyboard and continually turning round to read this on another screen!

Connect a network cable! Log in to the Pi and use ifconfig to find the IP address (of the LAN0 interface); connect SSH via puTTY. Alternative methods of finding IP address are listed all over the web; but that simple one works for me and I find once the IP is ‘got’ from my DHCP server (router) it keeps it for days.

[actually if you’ve left the screen connected and watch carefully the IP address is printed out during boot]

A note on using puTTY – if you copy from this guide; then right-click on puTTY it pastes the text in – which really helps avoid typing and typos!

Finishing off the basic setup

I guess I should explain this lot; but it’s borrowed from Pi-Point:

sudo –i

aptitude update

aptitude safe-upgrade

We’re now ready to start sorting out the real stuff

Installing software for Wifi access point; and configuring it

We’re going to need a number of items (again; we’re still on Pi-Point here):

aptitude install rfkill zd1211-firmware hostapd hostap-utils iw dnsmasq vim

That gets everything installed. Read http://www.linux.com/learn/tutorials/228600-vim-101-a-beginners-guide-to-vim if you need help. Use an alternative text editor if you want.

Edit interfaces file

This is to get the (network) interfaces sorted out; basically setting our Wifi interface to a static IP address (make a note of it!)

vim /etc/network/interfaces

The contents should be

auto lo
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet static

Having saved that try ifdown wlan0 and ifup wlan0; that’ll show if things are working (use ifconfig).

Custom hostapd

Here “it depends”. If your Wifi USB dongle “just works” then good; if not then (as mentioned in Pi-Point) you need to side-track. I can’t really talk you through this as there are a few permutations; but will record what I used:

I’m using a Belkin “N300” micro USB Wifi adaptor and need a different hostapd (for the Realtek RTL8188 chipset). As per http://andypi.co.uk/?page_id=220

apt-get autoremove hostapd

wget http://andypi.co.uk/downloads/v1.1.tar.gz

tar -zxvf v1.1.tar.gz

cd RTL8188-hostapd-1.1/hostapd


make install

(note missing sudo as in sudo -i ; well at least I am!)

Configure hostapd

This needs doing once hostapd is up and running – which might mean you need to do the paragraph below first to test things; and then once you’re happy:

vim /etc/hostapd/hostapd.conf

Here we need alter a few things; and the file I’m presented with is a bit more involved than the listing on Pi-Point. Still; key changes:

I followed http://wireless.kernel.org/en/users/Documentation/hostapd for this; though actually mostly I just deleted the security stuff.

(re)Start hostapd

service hostapd restart

And if that all worked; then brill. I had to try a few different approaches by Google searches – I knew when it worked ‘cause it just did – there were no errors during make etc.

Note: there is one “warning” that seems to pop up (for me) which doesn’t seem to stop things working: hostapdioctl[RTL_IOCTL_HOSTAPD]: Invalid argument. I can’t explain it and can’t find an obvious answer via Google…

Configure DHCP/DNS

hostapd is our miracle bit of software and does all our DNS and DHCP for us. Those two form the basics of an auto-connecting and auto-directing internet.

vim /etc/dnsmasq.conf

Now; this is a VERY long file; what I’m going to put here are the commands I’ve used; in the order they appear in the file – work your way through it.


Some explanation of this lot is probably needed:

TEST – well nearly

Reboot the Pi (shutdown –r “now”). Wait for it to come back up; check for errors – shouldn’t be any.

You should now be able to use a mobile ‘phone or similar Wifi device to connect to your ClosedCloud (or whatever you used). Type arp to list connections – your ‘phone should be there.

Apache: web server

I know as soon as I mention it people will have alternatives; but this is what I used for this first test.

aptitude install apache2 php5

Once installed it puts up a single web page – that’s good enough to test a bit more – you should find that you get that from either the LAN0 (using the LAN address) or WAN0 (via your mobile ‘phone) – for now just type in the IP address of the interface (so in my case for WAN0). If you get the “It works” web page – well done, it’s working!

Directing ALL content

What we actually want is to make any web address work. Why? It’s quite likely that the Wifi device will already have pages loaded – sites visited. What we want is a “refresh” to load our web site.

To do that we need to do a few things:

  1. DNS: resolve anything and everything to ourselves (done that, above)

  2. (pre)Route any IP address to ourselves

  3. Ensure 404 errors go back to our homepage

DNS “to us”

This is “smart” but possibly annoying; but it does make life easier. People don’t have to enter the IP address of your Pi (how would they know it?) or any “web address” (think big sticker saying ‘type in www.closedcloud.net to see our web site’). Basically *any* site/IP address, anything – will do.


iptables -t nat -A PREROUTING -s -p tcp --dport 80 -j DNAT --to

The format is very precise. There are -- i.e. two minus signs before some of the commands; so be careful. But the concept is to pre-route anything from our WAN0 subnet to ourselves; for port 80 (HTTP). If you’re going to use HTTPS you’ll need to do port 443 too. NOTE: this isn’t a persistent setting; so we need some more software and configuration; see http://www.microhowto.info/howto/make_the_configuration_of_iptables_persistent_on_debian.html

apt-get install iptables-persistent

(which will “capture” the current rule(s) for you = neat)

vim /etc/iptables/rules.v4

Just to check it out (or add the rule if you hadn’t got it in place prior to installing this package).

Redirecting 404 errors back to the home page

We need to edit the right configuration file the right way. This I found to be difficult to Google; and the solution here might not be the best:

vim /etc/apache2/sites-available/default

And add the lineErrorDocument 404 /index.htmlafter the first ; then:

/etc/init.d/apache2 restart

Site naming

I got a bit fed up that Apache kept saying my site wasn’t named… Had to:

vim /etc/hosts

vim /etc/apache2/sites-available/default

To the hosts file add my host name (ClosedCloud.net) to and; to default site add Servername ClosedCloud.net before the firstentry.

Test - again

We now have a working closed cloud Raspberry Pi. It provides DHCP and DNS on WLAN0 so provides a wireless access point solely to its own web site (which has a single page on it at the moment!).

Conclusion of network configuration

At this juncture the Pi is working as a “closed cloud”. It’s capable of serving whatever web site you put on it to anything that connects wirelessly to its Wifi access point. Job done.

Some notes at this point:

  1. We’ve only done port 80 (HTTP) – if someone tries HTTPS or a specific port (http://www.myserver.com:1234/) they’ll get page not found errors.

  2. *Ideally* I’d like this to trigger the “network needs sign-in” that you get from Android (and iOS? Sorry, don’t own one…) – throughout my testing I’ve had this sometimes and not others.

  3. I’m not overly happy at what I see as “DNS poisoning” (making all DNS respond with “me”) – but it makes the closed network work better.

  4. I’d love to ‘force’ a web page load on devices once they connect (that’s the point, after all) but not sure that’s possible.

  5. My Android ’phone gets annoyed/is too smart: it has some much else going on (Exchange ActiveSync to name but one) that being put on a closed network winds it up (!) and it starts trying 3G and other stuff.

  6. Advanced: I had thought of trying the following: Setting the DNS to return a different IP address to the Pi; and then the route command will override that. Why? Because that might “trigger” the ‘login website’ detection on mobile devices better.

Alternative approaches

Whilst Googling for much of this I came across:


Which is very close to what I was after; and in some of the comments things get even closer. I only found this after I’d got most of the way and to a degree I’ve approached things differently… But it’s there as a comparison.

Get in touch

This “walkthrough” is by Dr. Michael Dye who can be contacted through http://www.dyetech.co.uk/ and is much more used to .NET and SQL than Linux…