When I buy electronic devices, I always keep an eye on their power consumption. Especially the power drain that you’ll get 24/7. For most devices, this is their “standby” power consumption, but some devices are left on all day long. My broadband router, a TP-Link Archer C7 running OpenWRT 15.05 Chaos Calmer, is in this last category.
Posts tagged ‘router’
My ISP, Skynet Belgacom Proximus, has been rolling out IPv6 since 2013. However, you need a B-Box 3 in order to get it. Recently, my B-Box 2 decided to stop working, so I got a (free) upgrade to a B-Box 3 (but see below).
I’ve been struggling with my dd-wrt setup lately. So I started looking around for potential alternatives. One thought was to use a Raspberry Pi as router, but I was worried about its performance. So I did a few tests.
As a follow up on my previous article with the WRT320N, here’s my journey for the WRT610N revision 2 (which is very similar, but has two radio’s).
Since none of the dd-wrt releases include ip6tables support, I added it myself. The standard kernel does support module loading, so you can simply add additional kernel features without reflashing the device. You do need some writable storage. I use the remaining 4MB of flash using JFFS, but using an external storage (USB, network, …) is also possible.
Since you can’t run a complete build environment on the router itself, you’ll have to set up a cross-compiling environment on your own machine. As I found out, this isn’t always very easy to do…
Continue reading ‘Compiling custom dd-wrt kernel modules’ »
I bought myself a new WiFi router. When in the shop, I specifically searched for a router that is supported by dd-wrt, and has (at least) 8MB of flash. I settled for the Linksys WRT320N: it has a dual band (switchable between 2.4GHz and 5GHz, not simultaneous) 802.11a/b/g/n radio, a 4 port GbE switch, and a WAN port. It houses a Broadcom BC4717 processor running at 354MHz, 8MB of flash and 32MB of RAM.
The default Linksys firmware is actually not bad, but dd-wrt just offers a ton more features: Multiple SSIDs, IPv6 support (including Sixxs tunneling), WAN volume monitoring, custom firewalling, traffic shaping, … So I decided to void my warranty and put my router on steroids! Mandatory note: this may very well turn your router in to a very expensive brick.
It is perfectly possible to configure a linux server (or workstation if you wish) to talk IPsec. The Linux Advanced Routing & Traffic Control site has a page describing it. Since IPsec is a standard protocol, I wanted to get a tunnel up and running between a linux host and a Cisco router: with success! Here are the config files that I used in this test:
IPsec is becomming the Internet standard for securing IP packets. Instead of manually configuring all the encryption parameters, the keys are usually negatiated between the peers using an ISAKMP (Internet Security Association and Key Management Protocol)/Oakley protocol: IKE (Internet Key Exchange). This post goes into its details.
When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:
- Security: You don’t want the carrier-network to see your data
- IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
- Workarounds: for whatever reason you whised that there was a connection between A and B
Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.
Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.
