How WiFiDog Works

I introduced WiFiDog in a previous post. In this post, I examine how WiFiDog works by exploiting Netfilter/Iptables.

WiFiDog creates the following chains in magle table, WiFiDog_br-wlan_Incoming /Outgoing /Trusted, and WiFiDog_br-wlan_AuthServers /Global /Internet /Known /Locked /Unknown /Validate in filter table. br-wlan is the GatewayInterface set in /etc/wifidog.conf

WiFiDog_br-wlan_Outgoing is chained in mangle PREROUTING. If a client passes authentication, WiFiDog daemon inserts a rule in WiFiDog_br-wlan_Outgoing, marking the packets from this user with mark 0x2.

WiFiDog_br-wlan_Internet is chained in filter FORWARD table. The contents in this chain is derived from /etc/wifidog.conf, which resembles the following:

Chain WiFiDog_br-wlan_Internet (1 references)

target     prot opt source               destination         

DROP       all  --  anywhere             anywhere             state INVALID

TCPMSS     tcp  --  anywhere      anywhere    tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

WiFiDog_br-wlan_AuthServers  all  --  anywhere        anywhere            

WiFiDog_br-wlan_Locked  all  --  anywhere             anywhere         mark match 0x254

WiFiDog_br-wlan_Global  all  --  anywhere             anywhere            

WiFiDog_br-wlan_Validate  all  --  anywhere           anywhere         mark match 0x1

WiFiDog_br-wlan_Known  all  --  anywhere              anywhere         mark match 0x2

WiFiDog_br-wlan_Unknown  all  --  anywhere            anywhere            

At this point, WiFiDog is capable of separating known users and unknown users. However, there is one more thing, redirecting unknown users to the web portal. This is done with WiFiDog_br-wlan_Unknown chain in the nat table. There is a rule:

REDIRECT   tcp  --  anywhere             anywhere         tcp dpt:www redir ports 2060

which redirects unkown user's HTTP connection to 2060 port on the router.

Enable Web Proxy Auto-discovery on OpenWrt with Dnsmasq

Recently, I set up shaodowsocks and polipo on an OpenWrt router. I'd like every client connected be able to bypass the Great Fire Wall of China automatically. This can be done by pushing an proxy auto-config to the client. And there exists a protocol called Web Proxy Autodiscovery (WPAD).

Dnsmasq is capable of WPAD. Just add this line in /etc/config/dhcp.conf under config dhcp lan section

list dhcp_option '252,http://192.168.10.1:8000/proxy.pac'

the HTTP URL should be replaced adequately. There should be no spaces between the comma and URL. You can convert GFWlist to a PAC file with gfwlist2pac.

A note for iPad users:

iPad do not enable WPAD by default (because WPAD can redirect a client's HTTP connection without informing the user). The user can enable it in the configuration for wireless access points.

WifiDog on Openwrt

WifiDog is a Captive Portal on Openwrt. It utilizes Linux netfilter in order to force a client to log in before granting access to the Internet. Although there is a Wifi in its name, it can work on wired network as well. WifiDog has two components, a gateway and an auth server. The gateway is running on an access point, and redirects unknown clients to the auth server's login page. The auth server is simply a Web server which implements WifiDog's auth protocol.

To install wifidog gateway on openwrt, just type opkg install wifidog in command line. It's config file is at /etc/wifidog.conf. You may want to customize GatewayID, GatewayInterface,  AuthServer, CheckInterval, and TrustedMACList. The comments in the config file explains these options clearly.

The crucial part is the AuthServer section. Upon connection, the client will be redirected to the auth server for authentication. You should have at least one AuthServer section. If you have multiple AuthServer sections, WifiDog will use the first auth server that responses to its ping request. The auth server implements wifidog's auth and ping protocols. An auth server written in php is available at https://github.com/wifidog/wifidog-auth. You may also write an auth server which suits you need. I have written one in python.

You should understand wifidog's protocols before writing an auth server. The protocol is fully describe in http://dev.wifidog.org/wiki/doc/developer/WiFiDogProtocol_V1. I will give a summary below.

Wifidog gateway keeps a list of authorized users' IP, MAC and token. If an unknown user tries to visit a website, it will be redirect to the auth server's login page. If login is successful, the user will be redirected to the gateway's portal with the URL containing the user's IP, MAC and token (a random string). The gateway will verify these information with auth server via auth protocol. Every check interval (default value is 60 seconds), the gateway will contact the auth server and check every user's token by the auth protocol. If the re-authorization for a user fails, the gateway will remove the user from the list and then blocks its internet access. The auth protocol also allow the gateway to send accounting information for a user to the auth server.

Connecting two networks with OpenVPN

I have two routers in two cities, both is connected to the Internet via different ISPs. I wanted to let computers behind both routers to be able to talk to each other directly (without port forwarding and other stuff).

Firstly, I set up a OpenVPN server in p2p mode with static keys, whose IP address is 129.168.20.1, on one router, and a p2p client, whose IP address is 192.168.20.2, on the other router. Below are their configuration files:

p2pserver.conf
-------------------------------
mode p2p
proto udp
port 2333
dev tun
ifconfig 192.168.20.1 192.168.20.2
secret static.key
mssfix 1450
verb 1
log /tmp/p2p.log
keepalive 10 120
persist-tun
persist-key
route 192.168.99.0 255.255.255.0

p2pclient.conf
---------------------------------
mode p2p 
proto udp 
dev tun
remote server's_domain name 2333
ifconfig 192.168.20.2 192.168.20.1
verb 1
secret static.key
keepalive 10 120
log /tmp/p2p.log
mssfix 1450
route 192.168.33.0 255.255.255.0


There is one thing to notice. You should add route of the other end's subnet, so that all traffic to the other subnet will be forwarded through the tun device. To enable forwarding through tun device, you should add firewall rules.

Firstly, add following lines in /etc/config/network

config interface 'p2phome'
option ifname 'tun0'
option _orig_ifname 'tun0'
option _orig_bridge 'false'
option proto 'none'

Then, add the new interface to the lan zone of firewall. And enable forwarding in the lan zone. This can be done with OpenWRT's Web UI.

Auto run VirtualBox VM in background on Fedora 22 with systemd

Recently, I discovered that VirtualBox has a headless mode, where you can run a VM in background. You can start a VM in background with this command,

VBoxManage startvm Win7 --type headless

Win7 is the name of the VM

You can also save the state of a VM with this command,

VBoxManage controlvm Win7 savestate

So, I wrote a systemd service file so as to start and stop the VM automatically.

[Unit]
Description=Vbox for win7
After=network.target multi-user.target vboxdrv.service

[Service]
Type=forking
ExecStart=/usr/bin/VBoxManage startvm Win7 --type headless
ExecStop=/usr/bin/VBoxManage controlvm Win7 savestate
TimeoutSec=60

[Install]
WantedBy=default.target

Put this file as vbox.service in ~/.config/systemd/user/ and use systemctl --user to manage the service.

Python as a tftp server

There is a python package called tftpy which implements a tftp client and server. It's more handy for me to set up a temporary tftp server, compared with Fedora's tftp-server package, which relies on systemd.

In order to listen on port 69, python must be running as root. Then, type these lines in the python interactive shell. 

from tftpy import TftpServer

server = TftpServer("tftproot")

serve.listen()

tftproot is the path to the tftproot directory.

Redshift on Fedora 22

Redshift adjusts the screen's color temperature according to the time. It relieves your eyes when working at night. It's homepage is http://jonls.dk/redshift

To install redshift on Fedora 22, type sudo dnf install redshift in terminal. You may also install redshift-gtk, a GUI front-end for gnome desktop. Then you should enable location service in privacy settings. Also add these lines to /etc/geoclue/geoclue.conf to allow redshift to get location from geoclue.

[redshift]
allowed=true
system=false
users=

Finally, type redshift in terminal, and you should notice the change of the color temperature of your screen. However, the shipped systemd service does not work (redshift starts, but no change of color temperature, quite mysterious.) So I installed redshift-gtk and make it autostart when I login.