Raspberry PI open hotspot for your company site(s) only

Raspberry HotspotThe problem is really simple, you want/need to give open Wifi to your customers (let’s say inside a shop), but to you own company website (or websites) only. And nothing else, no other resources in the (internal or external) network.

The solution is simple and it comes in a tiny format… you will just need a Raspberry PI with a Wifi USB dongle that supports AP mode. Your company website should have an exclusive IP address

Side note: as normal, I’m not liable for any kind of mess, data loss, massive meteorite smash or other apocalyptic event in your world due to this guide.

Have the PI installed with the latest Raspbian, booted and logged in as root (sudo -s or equivalent).

Update the software sources:

apt-get update

Install the required software

apt-get install hostapd dnsmasq

Configure the wireless interface with a static IP address,
edit /etc/network/interfaces

iface wlan0 inet static
address 10.0.0.1
netmask 255.255.255.0
broadcast 255.0.0.0
# pre-up iptables-restore < /etc/iptables.rules

and restart the interface

ifdown wlan0
ifup wlan0

Here I choosed the 10.0.0.1 address to isolate the Wifi guests from the 192.168.1.x internal network. You should adapt it according to your existing set-up.

edit /etc/default/hostapd

and replace
#DAEMON_CONF=””

with
DAEMON_CONF=”/etc/hostapd/hostapd.conf”

now edit (it’s a new file) /etc/hostapd/hostapd.conf

For a full list of switches and whistles please do refer to http://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf, we go with a very minimalistic (but functional) configuration

interface=wlan0
ssid=WIFI-FREE-AS-BEER
channel=0
macaddr_acl=0
auth_algs=1
wmm_enabled=0
driver=nl80211
hw_mode=g
ieee80211n=1

Here we can start the service.

service hostapd start

and I got the dreadful failed in red font… a lsusb command quickly showed the infamous RTL8188CUS chip:
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Thanks to the good people of the Internets you get a quick fix (you are downloading an external binary… so cross your fingers before installation, and nothing bad will happen to your PI… well, it worked for me).

wget http://dl.dropbox.com/u/1663660/hostapd/hostapd
chmod 755 hostapd
mv /usr/sbin/hostapd /usr/sbin/hostapd.ori
mv hostapd /usr/sbin/

and change in /etc/hostapd/hostapd.conf
driver=nl80211
to
driver=rtl871xdrv

service hostapd start

service [….] Starting advanced IEEE 802.11 management: ok
hostapdioctl[RTL_IOCTL_HOSTAPD]: Invalid argument

Even with the warning output the service managed to start and work correctly.

By now there should be an open network called WIFI-FREE-AS-BEER available to log in, but the process will stall in the Obtaining IP Address stage. So it’s time to move to the DHCP and DNS server.

Edit /etc/dnsmasq.conf, and place at the end of the file the lines

address=/#/aaa.bbb.ccc.ddd
interface=wlan0
dhcp-range=10.0.0.10,10.0.0.250,12h015/05/raspberry-pi-open-hotspot-for-your-company-sites-only/
no-resolv
log-queries
log-dhcp

adjust the aaa.bbb.ccc.ddd to the exclusive public IP address of your company website. Basically we are configuring Dnsmasq to answer all name resolution queries to your public IP address, and setting DCHP leases to the Hostspot clients from IP 10.0.0.10 to 10.0.0.250 valid for 12h periods.

From now on it should be possible to log in to the Hotspot, but no data flow, so let’s take care of this now. First activate the kernel IP forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

and then adjust iptables rules

iptables -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p tcp -d aaa.bbb.ccc.ddd --dport 80 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p tcp -d aaa.bbb.ccc.ddd --dport 443 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p udp -d 10.0.0.1 --dport 53 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p udp -d 10.0.0.1 --dport 67:68 -j ACCEPT
iptables -A FORWARD -i wlan0 -j DROP 

remember to replace aaa.bbb.ccc.ddd with your the exclusive public IP address like in dnsmasq. From this point there should be a fully functional system. You can login to the Hotspot, and any http/https request will be landing in your company website. All other network traffic (except for the DHCP and name resolution will be blocked).

Now, to wrap up just make all this stuff survive reboots:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

update-rc.d hostapd defaults
update-rc.d dnsmasq defaults

iptables-save > /etc/iptables.rules

and uncomment in /etc/network/interfaces the line
# pre-up iptables-restore < /etc/iptables.rules

There is just one thing left, avoid the captive portal detection and the respective sign in to network message. If you are using some kind of URL mapping/decoupling system (really hope you do) it’s pretty easy.

For Android, test for http://clients3.google.com/generate_204 request and send a 204 header and 0 bytes:

if (isset($script_parts) && $script_parts[0] == 'generate_204') {
    header('HTTP/1.1 204 No Content');
    header('Content-Length: 0');
    die();
}

For iOS lalaland test for the user agent ‘CaptiveNetworkSupport’ and send a 200 response:

if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/CaptiveNetworkSupport/i', $_SERVER['HTTP_USER_AGENT'])) {
    header("HTTP/1.1 200 OK");
    die();
}

That’s it folks, and I wonder what will be the next use for this tiny big computer?

UPDATE
After all been working well and good for a long time, maybe after a reboot a problem surfaced. Maybe a whim of the bits gods, the system was using the dnsmasq on internal lookups for all interfaces ignoring the interface directive.

So for example if one ssshed into the raspberry and tried to wget google.com one would get our company site…. not good.

Simple fix, manually edit /etc/resolv.conf, you can use Google public DNS (not censored) or your LAN Router IP (that normally uses the upstream DNS of your provider).

# Google IPv4 nameservers
nameserver 8.8.8.8
nameserver 8.8.4.4

and to not be automatic overwritten by dhcpclient updates set the immutable bit:

chattr +i /etc/resolv.conf

UPDATE 2
Noticed that the raspberry was missing /etc/network/interfaces (no file at all and I don’t recall to delete it). Maybe the problem was due to this and Maybe it’s time for a new SD card and fresh install.

Raspberry PI configuring Wi-Fi command-line

This was a saga… i bought myself a second hand USB dongle, a Dynamode WL-700N-XS ultra compact (nano) 802.11b/g/n compatible Wi-Fi adapter, based in tbe Realtek 8188CU chipset. A fully updated USB Wi-Fi adapters list is mantained here.

Dynamode Wireless USB Nano 150mbps WL-700N-XSThis chipset is pretty plug an play on the PI with the latest Raspbian Wheezy, reported to work directly with a decent power source, no driver compilation or obscure installation, just supported out of the box by the Linux kernel. Just perfect.

I confidently connect the dongle in the PI, the USB device was properly recognized:

# lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

also on dmesg

# dmesg
[    3.171681] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[    3.293726] usb 1-1.2: New USB device found, idVendor=0bda, idProduct=8176
[    3.302266] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.311142] usb 1-1.2: Product: 802.11n WLAN Adapter
[    3.317650] usb 1-1.2: Manufacturer: Realtek
[    3.323401] usb 1-1.2: SerialNumber: 00e04c000001
...
[   15.830604] usbcore: registered new interface driver rtl8192cu

and ifconfig, reports a wlan0, so by now everything looked great. I followed an tutorial about configuring wireless on PI, and no connection, then another, and no connection… shit!!! Then of course i dump the PI tutorials (you can guess the technical level as low when you find “reboot to load the new values”….). Moved to good old Linux documentation, as Raspbian is just another Debian clone.

So before messing with /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf the best debug tool is the command ‘iwlist wlan0 scan‘, that should print the available wireless networks. And with this dongle i was getting none (even at 10 centimeters of the wireless router). Long story short, after testing the dongle in other computers (and even other OS – yes, i washed my hands already) i found out the dongle is simply damaged and working rather randomly.

After replacing the dongle (thanks Delaman) by another of the exact same model, things started to work properly, iwlist wlan0 scan started to work right and i could see my wireless network, and the neighbors networks also.

From this point i could confidently resume the wireless network setup. First thing the /etc/network/interfaces:

auto lo
iface lo inet loopback

iface eth0 inet dhcp

auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

the important lines here are those 3 referring to the wlan interface and should be added to the configuration file.

Then the /etc/wpa_supplicant/wpa_supplicant.conf that holds the network security configuration. First i tried some of the suggested configurations in the Internets, but i was just getting the error: “failed to parse ssid ‘MY_NETWORK_NAME’” and the likes. So, go with the wpa_passphrase command to generate a network block configuration:

wpa_passphrase YOUR_NETWORK_NAME password

Now copy and replace the generated network block to /etc/wpa_supplicant/wpa_supplicant.conf, it should look something like this (a quite simple and clean configuration):

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="NETWORK_NAME"
        #psk="password"
        psk=generated_by_wpa_passphrase
}

You can heep the first two lines, as they provide an interface to the wpa_supplicant via the wpa_cli command.

Don’t have to reboot, i tested this while ethernet connected. Restart the wlan0 interface and reload the configuration into the supplicant thing:

ifdown wlan0
ifup wlan0
wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

And there, ifconfig shows an active Wi-Fi connection on wlan0. From other computer, the wlan0 IP responds on pings and is possible to SSH. Now disable the ethernet connection:

ifdown eth0

disconnect the ethernet cable, and there your PI is free to move around without the network cable.