Raspberry Pi as a toy web server

1. Tell my router to route certain traffic to the Raspberry Pi. For example, I route HTTP and SSH traffic to one of my Pi’s. I disabled password login for  SSH, using public key authentication instead: in /etc/ssh/sshd_config, use the following setting and restart SSH service using `sudo service ssh restart’.

2. Getting my IP address of the Raspberry Pi. I firstly created a PHP script on my domain to record the IP address in a text file.

Then tell the Raspberry Pi to report its IP address every 5 minutes, using crontab:

After a while the IP address is recorded in the text file and updated every 5 minutes.

3. Optionally create a DNS record for the Pi. I use Cloudflare to manage DNS settings by myself, so just add/update an entry in Cloudflare’s settings. I point pi.daoyuan.li to the IP address of one Pi. This can be done automatically in the future.

4. Install Flask on the Pi.

5. Install nginx and uwsgi on the Pi.

6. Set up nginx along with uwsgi and Flask.

Edit nginx config:

Edit uwsgi config:

Create a simple Flask app:

Start up uwsgi:

7. Done! http://pi.daoyuan.li:5000/

 Update on June 24, 2014:

Getting the external address in step 2 can be done by running this command in Raspberry Pi:

See: http://www.commandlinefu.com/commands/view/5427/get-your-external-ip-address

mod_wsgi and mod_xsendfile on OS X 10.9 Mavericks

Updated on Nov 4, 2013: The following tricks may still work, however I have found a much easier solution. Simply install Xcode command line developer tools and you should be able to compile source code without issues:

After upgrading my Mac from 10.8 to 10.9 Mavericks my apache stopped working, so I have to reinstall mod_wsgi and mod_xsendfile. However, tricks are needed to compile and install these mods successfully.

Upgrade Xcode

Upgrade Xcode in App Store. As mentioned by Valerie:

I had to manually upgrade Xcode (after Mavericks upgrade) from the App Store & agree to its license because ./configure hung forever until I did that.


For mod_wsgi installation, create a soft link to OSX10.9.xctoolchain:

Then run configure under mod_wsgi source code directory:

It will generate a Makefile similar as follows:

However, this Makefile is not correct and running ‘make’ the compiler will complain something like:

Prepend the following line to CPPFLAGS value:

Save the Makefile and it will look something like:

Then make && install:

Modify /etc/apache2/httpd.conf to enable mod_wsgi:


Use the following command to compile and install mod_xsendfile:

Enabling HTTPS/SSL

After upgrading OS X the apache configuration was reset, but your original config is save to /etc/apache2/httpd.conf.pre-update. I need to enable SSL in httpd.conf again by uncommenting the following line:

Restart Apache and everything should work fine

OpenVPN client TLS-Auth problem on Windows

It seems that the OpenVPN Client on windows does not support TLS-Auth with a separate key file. So instead, you can paste your key contents in your openvpn client’s config file and use some thing like the following (inline ta.key):

When not using the above but using something like:

The server log shows something like:

Technical Details

We define a BPF filter as “icmp and dst host <bouncer_ip>”, which filters out all none-ICMP packets and packets not destined to the bouncer. The we compile this filter and set the filter to the capture device.

When the capture device captures a packet, a process_pkt function is called to process the packet. And that is where we validate the packets and then, if the packet is valid, update
the packet and then send it out, or write the packet to a dump file.

The process of validating the packets are as follows:

  1. Validate checksum of IP header.
  2. Validate TTL of IP.
  3. Validate IP source address
  4. Validate ICMP header checksum. 
  5. Validate ICMP type and code. 

Since we write the packet to a dump file in a separate function, so a pointer to the dump file handler is passed to the processing function when the process_pkt function is called. The same method is used to pass server IP address and test mode flag.

We keep a linked list of all the ICMP echo requests. When a ICMP echo reply is received, we go through the linked list to find out where
the original echo request comes from.

The code is as follows.



Multiple Sessions

A linked list of all RUDP sockets is maintained. When rudp_socket() is called, an RUDP socket is created and added to the linked list. An RUDP socket keeps a record of the pees/sessions it talks with. When RUDP receives a packet from an unknown socket address, or when RUDP receives a send packet request to an unknown socket address, a new session is created. And for each session, a linked list of all buffered packets is kept.

Session Establishment and Tearing Down

When rudp_sendto() is called, the protocol first check if there exists a session between the sender and receiver. If not, the protocol will try to setup a session by sending RUDP_SYN messages. And the packet the application wants to send will be buffered in the created session. After an RUDP_ACK message is received, the server side socket start sending out packets. Go back N protocol is used to control the sending process. After the protocol receives a rudp_close() signal, it will first check whether there are still active sessions and packets in the sending buffer. If not, the protocol will send out RUDP_FIN messages and after receiving RUDP_ACKs, the session is torn down.

RUDP Overview

RUDP is a protocol that ensures transfer reliability with UDP. A sliding window protocol (Go back N) is used to realize reliability. Using RUDP, applications can send and receive data packets without worrying about lost packets.

The lines in red signifies state change for RUDP clients (receiver side); while the black lines signifies state change for RUDP servers (sender side).

Multiple Sessions

A SessionManager' is used to manage all the sessions. The SessionManager’ keeps a list of sessions. When it receives data, it will first check which session the data belongs to. Then the data is given to the corresponding session. If it does not belong to any session in the list, a new session will be created and added to the session list.

The basic code looks like this:

Session Establishment and Tearing Down

Each session has a ‘status’, it can be ‘new’, ‘establishing’, ‘cancelling’, ‘established’, ‘tearingdown’ and ‘destroyed’.

When a new session is created, its status is ‘new’.

When an ‘INVITE’ is received, it sends out an ‘OK’ message and change its status to ‘establishing’.

After receiving an ‘ACK’ message the status will be changed to ‘established’.

Then begins the transferring of voice data using RTP.

When the sending finishes the status will become ‘tearingdown’.

A ‘BYE’ message is also sent to the client.

The status becomes ‘destroyed’ after getting ‘OK’ from the client.

When a ‘CANCEL’ message is received, the status becomes ‘cancelling’.

Then it sends back ‘OK’ and ‘Request Terminated’ messages.

After received an ‘ACK’, the status becomes ‘destroyed’.

The thread is as follows:

Generating Voice File

When the web server receives a POST' message from the web page, it will first check whether the message is valid. If so, freeTTS‘ is used to generate a voice file and the file is saved in the `wav’ directory with pre-configured file name.

The voice generator looks as follows:

Non-ASCII characters in Email subject

In this system, Email subjects are encoded in Q' scheme, a scheme similar to quoted printable’. The format is “=?charset?Q?encoded subject?=”, in our case, the charset is `ISO-8859-15′.

For example, the Email object in this system is as follows:

MIME Encoding

Quoted printable characters are encoded in the format =XX', where XX’ stands for the hexadecimal value of the character.

The encoder looks as follows:

URL Decoding

The charset of the form page is ISO-8859-15'. HTTP will encode the form message in URLEncoding, that is, space is replaced with +’; non-ASCII characters are encoded inthe format %XX', where XX’ stands for the hexadecimal value of the character.

The URL decoder in this system looks as follows:

ISP Demo Overview

ISP Demo is a demonstration of how an Internet Service Provider should work using four Cisco routers (one Cisco 2514 and three Cisco 2501), three HP 2524 switches, several laptops and PCMCIA cardd, and some UTP straight and crossed cables.

In this project, a small ISP is set up to achieve dynamic IP routing, IP multicast routing and fault-tolerant IP routing. The ISP provides basic services like DHCP, DNS, WWW web service, Email service and VPN.

OSPF is used as the internal routing protocol for our network, since it has a better convergence time than RIP and consume far less network ressources. There is a static route to the VPN network through the VPN server. OSPF has to handle this and redistribute (redistribute static subnets under the OSPF con figuration) the static routes. OSPF is run only between the routers and all ethernet interfaces are passive.

The web server is a simple Apache2 server on a dedicated computer running Ubuntu 9.04, without any SQL databases or any scripting languages. On this server there is ISP’s home page and the whole documentation. The web server can also be used to put some news to inform the clients if there are problems in the network.

We used Sendmail (version 8.13) to confi gure the MTA and Dovecot as the MDA. SendMail has been chosen because it’s a widely used software, very modular and allows extensions to threat spam and viruses. This server can handle a huge load, and while it is hard to con figure, it works well when con figured.

The VPN server is an OpenVPN server running on debian. We chose OpenVPN because it runs on Windows, Linux, BSD and Solaris hosts, and there are also clients for Mac OS X. Furthermore, it uses only one TCP or UDP port, not like PPTP which uses GRE protocol and may be blocked by the firewall of the remote network (the physical network our client is connecting to).

PIM-SM (Protocol Independant Multicast – Sparse Mode) is used to set up multicast routing.

*Note: some of the contents above are from the final documentation we wrote as a team, which consisted of seven other students in KTH.*