Intro
Most Raspberry Pi router HowTos describe how to make the Pi act like an Access Point. That can be very useful, and kind of tricky. Here I’ve turned wireless and wired network roles around and show how to make it route traffic from a wired LAN over its WiFi connection.
I bought the EDIMAX nano USB adapter to play around with wireless on my Pi. It wasn’t long before the network lover in me realized, Hey I got an ethernet port on one end, a wireless on the other – that sounds like a potential router – let’s have some fun! So I hooked up my cantankerous Sony Blueray player to it. The thing has always been touchy about using wireless but it also has a wired LAN connection option – in a room where I don’t have a wired ethernet network available. Enter the routing Pi…
WiFi on the Pi
There are many ways to get the thing going. The important thing to note is that this EDIMAX is tested and is known to be compatible with the Raspberry Pi. I guess they even included the appropriate driver for it, because there is no need at any time to read the mini-CD that the EDIMAX comes with and try to pull of, or worse, compile, a Linux driver like I initially feared. I think you merely need to do one of these numbers:
$ sudo apt-get update
to ensure you have the latest of everything on your Pi and that includes the driver for this WiFi adapter.
Also note that the Pi, being a tiny computer, is perfectly complemented by this nano adapter. The thing is so tiny you barely have enough surface area to pull it out of the USB slot.
As I said there are probably many ways to get your WiFi going. Being a command line lover I present that way, and even then there are alternative setups to choose from, of which I present only one here.
If you do one of these numbers:
$ cd /etc/network; sudo nano interfaces
I would recommend to add a line towards the top:
auto wlan0 |
and at the bottom:
# following http://antael.blogspot.com/2013/01/wifi-is-live-and-kicking.html # to see Wifi signal strength and available signals run iwlist wlan0 scan #allow-hotplug wlan0 iface wlan0 inet static wpa-ssid wpa-psk wpa-key_mgmt WPA-PSK address 192.168.0.90 gateway 192.168.0.254 netmask 255.255.255.0 broadcast 192.168.0.255 |
substitute the name of your WiFi SSID and the password (WPA Pre-Shared Key) in place of <MYSSID> and <MYSSIDPASSWORD>.
I prefer static IPs to dynamic ones. That way I ssh to the IP and it is the same every time.
As I am setting up a router this is not my complete interfaces file, just the part I want to emphasize for now. The complete file is listed below.
A word on what we are setting out to do – our network architecture
OK. So I am going to put the Pi next to the Blueray Player. The Pi will connect to my TP-LINK WiFi network. The Pi’s ethernet interface will connect to the LAN port on the Blueray player using a standard ethernet patch cable (these days it is not necessary to use a crossover cable as there’s always a device that auto-senses how it is wired). I will create a new network for this interface on the Pi, and make sure I’ve assigned a valid IP on this network to the Blueray player. The network I choose is 10.31.42.0/24 – something completely different from anything I may already have in use at home.
The Blueray player can also be assigned a static IP address. I give it 10.31.42.13 and the Pi I assign 10.31.42.11. The gateway of the Blueray player is our routing Pi, so that makes the gateway IP 10.31.42.11.
But I have another requirement: I want to conveniently put the Pi back on my wired home network in case something goes wrong with wireless. so I want to keep its valid static IP (192.168.2.100) which it used to have when it was wired to my switch. The way to accomplish all this is to use virtual IPs on the eth0 interface. See the full /etc/network/interfaces file below which shows eht0 still assigned to IP 192.168.2.200, but as well a virtual interface eth0:0 assigned to 10.31.42.11.
Convenient way to test things
Initially I was focused on the architecture I’ve outline above and getting all my interfaces up and running. And I could run, for instance,
$ sudo service networking restart
to make my changes to the interfaces file be dynamically enabled, and I can do a
$ ifconfig -a
to show all my interfaces, their IPs and other information. And I especially like
$ iwlist wlan0 scan
to show the available WiFi networks and their signal strength. But how do I know that routing is working?? Here’s how. You know the ping command, right? Normally you do
$ ping 8.8.8.8
to show you can reach the Internet. Why? because that’s a valid IP address on the Internet that responds to PING – thank you Google – and it’s easy to remember!
But since our default route is out of our WiFi-connected interface, the IP it picks for the source of that PING is the IP assigned to wlan0, namely 192.168.0.90. There’s no Pi-routing involved in that so far. But now, you can choose a different source IP for your pings. So we pick our new virtual IP, 10.31.42.11 like this:
$ ping -I 10.31.42.11 8.8.8.8
but instead of a nice result like
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=44 time=172 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=44 time=92.7 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=44 time=69.6 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=44 time=70.6 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=44 time=70.3 ms 64 bytes from 8.8.8.8: icmp_req=6 ttl=44 time=70.5 ms ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5006ms rtt min/avg/max/mdev = 69.676/91.121/172.740/37.409 ms |
we don’t get much encouragement:
PING 8.8.8.8 (8.8.8.8) from 10.31.42.11 : 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3000ms |
The ^C above means <CTRL-C> was typed in at the keyboard.
So we’re seeing 100% packet loss and we can safely conclude no routing is occurring. By the way, as a reality and typo check on this approach, try to specify as source your wlan0 IP, as in
$ ping -I 192.168.0.90 8.8.8.8
This should work.
Turn on routing
I feared it would be mess to get routing turned on, but it turns out to be pretty tidy, considering. Probably your Pi is already enabled for routing. Mine was. Just
$ cat /proc/sys/net/ipv4/ip_forward
and make sure the value is 1. That means it is set up to do routing. If you’re not so lucky and you have 0, enable routing:
$ sudo sysctl -w net.ipv4.ip_forward=1
But of course there’s more we have to do or else our source ping would have worked!
We need to turn on network address translation. This is the part I was worried about, never having done it before on Linux, but only with expensive products like commercial firewalls. But it’s really not bad at all.
I created a file iptables-NAT in the home directory of the pi user with these contents:
#!/bin/sh # This is a one-time script - DrJ # 2/2014 # explained nicely in http://www.karlrupp.net/en/computer/nat_tutorial # and seems to even work! # flush old iptables stuff. Need to specify nat table specifically iptables -t nat -F iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE # make it permanent #/usr/sbin/service iptables save # list it iptables -t nat -L # persist it: iptables-save > /etc/iptables.conf # note that in /etc/network/interfaces we added this line to read in # iptables.conf upon reboot: # pre-up iptables-restore < /etc/iptables.conf |
and ran it:
$ cd; sudo ./iptables-NAT
It outputs this:
Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere |
Now run our source ping:
$ ping -I 10.31.42.11 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.31.42.11 : 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=44 time=76.3 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=44 time=71.4 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 71.471/73.922/76.373/2.451 ms |
Voila! It worked. We now are NATing our source address of 10.31.42.11 to our wlan IP of 192.168.0.90 before sending the packet along to the next router. But as skeptics, we’d like to see some more empirical proof that all that is really happening. You can. Here’s how using tcpdump.
The thing is that tcpdump doesn’t have full access to pre-processing, it only has “post processing” access. So we need to hook up the Pi to a device we are going to route traffic for, in my case the Sony Blueray player. I don’t have much control, but I can do a network diagnostics which I know tries to reach the configured DNS server (because it complained that it could not reach the DNS server 8.8.8.8 during one of my early tests. So tee up tcpdump to monitor all interfaces’ traffic to 8.8.8.8 like this:
$ sudo tcpdump -n -i any host 8.8.8.8
Then run ping (or a DNS query) to 8.8.8.8 on that device, and voila, this is the result:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 20:22:09.041922 IP 10.31.42.13.54693 > 8.8.8.8.53: 5+ A? m.root-servers.net. (36) 20:22:09.042144 IP 192.168.0.90.54693 > 8.8.8.8.53: 5+ A? m.root-servers.net. (36) 20:22:09.163618 IP 8.8.8.8.53 > 192.168.0.90.54693: 5 1/0/0 A 202.12.27.33 (52) 20:22:09.163777 IP 8.8.8.8.53 > 10.31.42.13.54693: 5 1/0/0 A 202.12.27.33 (52) |
The -i any switch told it to listen on all interfaces. Unfortunately the output doesn’t show which interface, but you can easily deduce it. the traffic comes in from my Blueray player at 10.31.42.13 on eth0, and then leaves the Pi on wlan0 having had its source IP translated to 192.168.0.90. And the reverse happens to the response from 8.8.8.8. In fact I see from this tcpdump output that the Blueray player does not do a PING, it does an actual DNS query to 8.8.8.8. Makes sense since it is a DNS server.
Be persistent
But a reboot will undo this nice NATing we have achieved. Try it. So we have to find a way to make our iptables entry persist across reboots. I’m sure there are many ways to do this. I liked this one. You add this line to the end of your interfaces file:
pre-up iptables-restore < /etc/iptables.conf |
And of course we already anticipated this manner of proceeding in our iptables-NAT file when we included this line at the bottom:
iptables-save > /etc/iptables.conf |
Now reboot again, and try that source ping as the first command you issue. Now it should work.
Ready for the real test
Now I can hook up my Blueray player with some confidence that at least the networking should be working. Assign its IP (10.31.42.13 as mentioned above), its gateway (the Pi’s eth0:0 virtual IP, namely 10.31.42.11 in our example), a DNS server (8.8.8.8, of course!) and see if:
– we can ping 10.31.42.13 from the Pi
– the Blueray player’s network tester shows OK (there aren’t many fine debugging utilities, just this single “network test”)
If the Blueray player can’t reach the configured DNS server then it its test fails.
Why this big long explanation for something that no one else in the world wants to do?
All this sounds like a very, very specific application that doesn’t apply to anyone else. But once you understand some of the core networking principles involved that I’ve touched on here, you will begin to realize that this can be very easily generalized to something much more applicable and powerful: a full-blown replacement for a standard wireless router such as my TP-LINK nano router. After all, we’ve set up almost all the utilities and facilities that you get from a standard router (NATing and routing), perhaps with one glaring exception: a DHCP service. I personally didn’t want one, but nothing prevents you from setting that up on the wired side. I give some suggestions below on how to do that in the next section.
A few words on a DHCP service
I did get that running on the Pi as well, though for an entirely different purpose. I used dnsmasq:
$ sudo apt-get install dnsmasq
and I think if you edit /etc/dnsmasq.conf and put these lines at the bottom:
interface=eth0 dhcp-range=10.31.42.14,10.31.42.254,10h dhcp-option=3,10.31.42.11 |
I think you will pretty much have a working DHCP service as well and could use that instead of assigning static IPs.
What I fear about the DHCP service – and I think I have seen this – is that if I put the Pi back to the wired network, its DHCP server competes with the normal router’s DHCP service, and I start to lose connectivity to my devices! So be careful. If devices like your PC start to pick up 10.31.42.x addresses on a network where 192.168.2.x is expected, there could be some connectivity troubles ahead until you disconnect the Pi!
Finally, the full /etc/network/interfaces file
auto lo auto eth0 auto eth0:0 auto wlan0 iface lo inet loopback # DrJ change: make IP static # somewhat inspired by http://www.techiecorner.com/486/how-to-setup-static-ip-in-debian/ - DrJ 1/8/13 #iface eth0 inet dhcp iface eth0 inet static address 192.168.2.100 #gateway 192.168.2.1 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 # for network 3142 iface eth0:0 inet static address 10.31.42.11 netmask 255.255.255.0 network 10.31.42.0 broadcast 10.31.42.255 # following http://antael.blogspot.com/2013/01/wifi-is-live-and-kicking.html # to see Wifi signal strength and available signals run iwlist wlan0 scan #allow-hotplug wlan0 iface wlan0 inet static wpa-ssid wpa-psk wpa-key_mgmt WPA-PSK address 192.168.0.90 gateway 192.168.0.254 netmask 255.255.255.0 broadcast 192.168.0.255 # wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf #iface default inet dhcp # to read in iptable configuration. See ~pi/iptables-NAT # added - DrJ 3/2/14 pre-up iptables-restore < /etc/iptables.conf |
Conclusion
Yes, we got our Pi to act as a router, and it wasn’t too bad. We demonstrated it for this specific application, but also showed how the simple addition of a DHCP service would make this a very general solution.
Did it help with the problem at hand – getting smoother streaming on the Sony Blueray player? Well, actually, yes, it did seem to help.
References and related
Getting started on a Pi without a dedicated console is described here.
A look at playing around with real-time video using the Pi’s camera is described here.
A more esoteric project, using the Pi to monitor your home’s Internet/power connection, is presented here.
Turning your Raspberry Pi into a transparent networking bridge is described here.
Interested to run some real networking protocols on your Pi like RIP, OSPF or BGP? I suggest to look into Quagga. Quagga is a networking suite. In full disclosure I haven’t had time or motivation to experiment with it myself (yet).