The Pi-Point Raspberry Pi Wireless Access Point
By Dr Michael Dye.
This is a mix and match of various technologies and walkthroughs to use a Raspberry Pi to create:
A Wifi hotspot
A closed network: DHCP and DNS on the Pi, for the Wifi network only
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
A Raspberry Pi
Internet/Network access (for all this setup)
Some PC with SD card reader/writer & the ability to run an SSH terminal; plus to go to all the web sites listed here
SD card (I used 4GB)
Keyboard/mouse for the Pi (optional, not needed once things are running!)
Wifi USB adapter for the Pi (that supports access point mode)
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’.
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.
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!):
Expand file system
Advanced: hostname (ClosedCloud)
Advanced: Memory split; GPU to minimum (16?)
Advanced: Enable SSH
Set a non-default password
Again – for more detail see Pi-Point which shows how to do this using SSH
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!
I guess I should explain this lot; but it’s borrowed from Pi-Point:
We’re now ready to start sorting out the real stuff
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.
This is to get the (network) interfaces sorted out; basically setting our Wifi interface to a static IP address (make a note of it!)
The contents should be
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).
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
tar -zxvf v1.1.tar.gz
(note missing sudo as in sudo -i ; well at least I am!)
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:
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:
Set your ssid (e.g. “ClosedCloud” without the quotes)
Delete/remove/remark out any authorisation (we want open access)
I followed http://wireless.kernel.org/en/users/Documentation/hostapd for this; though actually mostly I just deleted the security stuff.
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…
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.
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:
We want ALL DNS to resolve to us = there is nowhere else to go (that’s the no-resolv and address line)
We want this DNS & DHCP to be on WAN0 (the Wifi dongle)
I’ve given myself a nice domain name (that might appear on client connections)
We want to provide short-lived DHCP; so we’ve got 249 possible addresses on a 2-hour lease
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.
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 192.168.79.1 in my case for WAN0). If you get the “It works” web page – well done, it’s working!
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:
DNS: resolve anything and everything to ourselves (done that, above)
(pre)Route any IP address to ourselves
Ensure 404 errors go back to our homepage
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 192.168.79.0/24 -p tcp --dport 80 -j DNAT --to 192.168.79.1:80
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)
Just to check it out (or add the rule if you hadn’t got it in place prior to installing this package).
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:
And add the lineErrorDocument 404 /index.htmlafter the first ; then:
I got a bit fed up that Apache kept saying my site wasn’t named… Had to:
To the hosts file add my host name (ClosedCloud.net) to 127.0.0.1 and 127.0.1.1; to default site add Servername ClosedCloud.net before the firstentry.
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!).
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:
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.
*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.
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.
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.
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.
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.
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.
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…