Tag Archives: OpenWRT

uhttpd with a certificate chain

To secure access to my router I wanted to use SSL encryption to access LuCi, so I obtained a certificate issued by a well-known CA. The server certificate was not issued directly off the CA, but there was a certificate chain in between.

Using a certificate chain with OpenWrt’s uhttpd is really easy, although as of today this is not yet even documented to be possible on the OpenWrt web site.

I’m using uhttpd_2015-11-08 from a trunk build (r48648) of “Designated Driver”, and certificate chains can be used here without problems.

I didn’t even have to convert from PEM to DER, I just concatenated the server cert and intermediate certs into a single file:

cat /root/server.crt /root/1_root_bundle_1.crt /root/1_root_bundle_2.crt >uhttpd.crt

Hope this helps. If it does please leave a message, thank you.

OpenWRT: Easy and secure guest WLAN access

I use OpenWRT on my TP-Link TL-WDR3500, and I have a guest WLAN defined on each of the two radios (2.4 and 5 GHz). The guest WLANs are isolated from my LAN, i. e. guest WLAN stations can’t talk to any of my own hosts (either on the WLAN, or in the LAN, i. e. hosts connected via Ethernet). Guest WLAN stations also can’t talk to each other. The actual OpenWRT configuration (apart from passwords, of course ;-)) is not a secret, I will publish an article about that soon.

For security reasons I didn’t want a static guest WLAN password, but one that changes daily, so that I don’t have to manually revoke the right to use my WLAN by changing the password all the time. So I created two tiny scripts, one that actually changes the active WLAN password every day, and one CGI script that displays the password so that I can give it to my guests.

Here’s the first one that sets the password. I run it from cron at 00:01 every day:

 #!/bin/ash
 SALT="theSalt"
 DATE=`date -I`
 PWD=`echo -n "${SALT}${DATE}" | md5sum | cut -c1-16`
 CHANGE=0

 if [ `uci get wireless.@wifi-iface[2].network`x = guestlanx ]; then
   uci set wireless.@wifi-iface[2].key=$PWD
   CHANGE=1
 fi
 if [ `uci get wireless.@wifi-iface[3].network`x = guestlan2x ]; then
   uci set wireless.@wifi-iface[3].key=$PWD
   CHANGE=1
 fi
 if [ $CHANGE -eq 1 ]; then
   uci commit wireless
   wifi
 fi

And here’s the CGI script that needs to go to /www/cgi-bin to show the current password:

#!/bin/ash
SALT="theSalt"
SSID="Guest-WLAN"
DATE=`date -I`
PWD=`echo -n "${SALT}${DATE}" | md5sum | cut -c1-16`

echo "Content-Type: text/plain"
echo ""
echo "Today's Guest Password for $SSID is $PWD"

Don’t forget to make the scripts executable by running “chmod +x <script>“.

If you find this helpful I would appreciate your feedback.

Windows 7 PPPoE-Protokoll schlecht implementiert?

Anläßlich eines Problems mit meinem Vodafone 16 MBit/s-DSL-Anschluss — Geschwindigkeit ging plötzlich dramatisch in die Knie, ca. 1-2 MBit/s nur noch! — habe ich testweise die PPPoE-Verbindung direkt vom Laptop unter Windows 7 über das Arcor-DSL Speed-Modem 200 zum Konzentrator bei Vodafone aufgebaut. Auf diese Weise wurde das Modem als “Schuldiger” ausgemacht: Ein baugleiches Ersatzmodem lieferte sofort über 14 MBit/s!.

Nachdem ich dann wieder das DSL-Modem mit dem TP-Link TL-WDR3500-Router (mit OpenWRT als Firmware) verkabelt hatte, stellte ich plötzlich erstaunt Folgendes fest: Die Ping-Round-Trip-Zeiten gingen von 31-32 ms (unter Windows 7 als PPPoE-Client) deutlich herunter auf 21 ms (mit OpenWRT Barrier Breaker r39582 als PPPoE-Client). Das ist insofern sehr erstaunlich, da ja nun eine 802.11an-WLAN-Strecke und der Router als zusätzliche Latenz erzeugende “Komponenten” hinzu kamen!

Ich interpretiere das so, dass die PPPoE-Implementierung unter OpenWRT der von Windows 7 deutlich überlegen ist, da sie offensichtlich “schneller” bzw. “effizienter” ist. Bevor jetzt jemand sagt “Vielleicht hast Du einen krötenlangsamen Laptop verwendet?” — nein, das ist nicht der Fall, es war ein Lenovo X220 mit einem Core i5-Prozessor mit 2.5 GHz…. Und der Laptop war dauernd “idle”… 🙂

Eure Meinung zu dieser Interpretation würde mich sehr interessieren, daher würde ich mich über Kommentare freuen.

OpenWRT on the TP-Link TL-WDR3500

I got myself a TP-Link TL-WDR3500 since it boasts great hardware (see below for detailed info), and at the same time is supported by OpenWRT which I easily found out by searching in the OpenWRT forums.

Here’s the direct link to the firmware image (current “unstable” or “bleeding edge” OpenWRT release “Barrier Breaker” — i. e. not current stable one, which is Attitude Adjustment — build r36486) which you can use to upgrade a device with the factory firmware still installed. (Update: The link refers to the “trunk”, i. e. the development branch, where daily builds are available.)

Installing OpenWRT using the stock firmware’s “Firmware Upgrade” function worked smoothly. Less than 5 mins. after I started the upgrade I had OpenWRT running (thanks, folks!).

Continue reading OpenWRT on the TP-Link TL-WDR3500

OpenWRT and DNS UPDATE

I’m hosting my domain myself on a dedicated root server, and I wanted my Internet router to automatically update a hostname in my own domain (in a designated dynamic zone) with my current public IP. With OpenWRT this was easily accomplished. I used these instructions as a starting point.

When trying to check whether everything was set up correctly I always got some strange error from the following command:

# ACTION=update INTERFACE=wan /sbin/hotplug-call iface

It turned out that the following statement

config_get ipaddr wan ipaddr

did not return the currently assigned IP address in my case, but just an empty response, so I got the following error message:

could not read rdata
syntax error

(For testing I hooked a spare router with a fresh OpenWRT install with the WAN port into my LAN, and configured the WAN interface to receive its IP address via DHCP from out of the LAN. In “production” the WAN interface receives its IP via PPPoE.)

Some friendly guy in the OpenWRT forum suggested I try the following instead:

. /lib/functions/network.sh
network_get_ipaddr ipaddr wan

And indeed this worked well.