TomatoUSB

Configuration:

[MainGateway]
Asus RT-N66U [192.168.x.0/24] (DHCP Server, Internet Gateway, multiple Wireless N clients, multiple wired clients)
Tomato Firmware 1.28.0000 MIPSR2-124 K26AC USB AIO-64K
^ (private VLAN 192.168.y.1 on wl0.1, Access Point Mode)
|
|  (AES encrypted wireless N connection)
|
v (WAN static IP 192.168.y.2 in Wireless Client Mode)
[KidsRoom]
Asus RT-N16 [192.168.x.0/24] (MediaTomb server, Game System, No Wireless Clients)
Tomato Firmware 1.28.0000 MIPSR2-124 K26 USB AIO

Rationale:
I tried Wireless Ethernet Bridge which destroyed my network reliability (25% dropped packets).
I tried Wireless Client which hid the MediaTomb server from all clients on [MainGateway].
I ended up with this configuration because it works, though it's chewing CPU (80-95%) on both routers during high traffic loads.

Description:
I was successfully using TINC before I decided to try OpenVPN because TINC was very CPU heavy and topped out at 200KiB/s.
Openvpn works fine as long as I specify a cipher, but is still CPU heavy. Openvpn will not come up on either side of the connection if I specify Cipher=None in the UI. Openvpn always exits after logging the message "Adding tunnel interface to bridge failed".

I figure it's a defect in the firmware package since "None" is listed as a valid selection in the UI and this setup works as long as I specify an encryption cipher. Openvpn is way more efficient than TINC was in the same configuration and can sustain 1.3MiB/sec@80-95% CPU load with no compression and the custom configuration "auth none". All clients connected to [MainGateway] can see the MediaTomb PC in [KidsRoom], but I want to reduce the CPU load on the two routers by specifying Cipher:None in the openvpn configuration. I don't need CPU based encryption since the wireless connection is already handling that for the link.

Additional information: These are the final logs at "verb 11", then openvpn dies.

Wed Jan 14 09:53:04 2015 us=79609 OpenVPN 2.3.6 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 24 2014
Wed Jan 14 09:53:04 2015 us=79988 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Wed Jan 14 09:53:04 2015 us=80654 ******* WARNING *******: null cipher specified, no encryption will be used
Wed Jan 14 09:53:04 2015 us=80818 ******* WARNING *******: null MAC specified, no authentication will be used

Edit: increased verbosity from 4 to 11 and re-ran the test. The application fails in the same way.

[low karma, can't post links]

I'll wait for the next release and re-test. It looks like a new version of openvpn (2.3.6) was comitted to the HEAD after the release of Shibby 1.24, so it's possible that the bug is already fixed there.

Edit: Looks like this still needs to be fixed.

# openvpn --version
OpenVPN 2.3.6 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 24 2014
library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>

Edit2:
[low karma, can't post links]
OpenVPN issue #473 says that this was broken in openvpn 2.3.5 as downgrading to 2.3.4 fixes the issue. It is slated for a fix in Release 2.3.7. The bug report lists a few patches which, applied together, fix the problem.

Edit3:
It looks like the patches are partially applied to Tomato. The final listed patch which removes "attribute((nonnull));" lines and adds a test to the testsuite still needs to be applied to the repository. I have manually applied the patch to a local copy of the repository and will attempt to rebuid Tomato to test the patch.

This patch applies cleanly to the tomato-shibby and tomato-shibby-RT-AC branches. I have compiled AIO/RT-16 and my machine is working on AIO/RT-N66U.

diff --git a/release/src/router/openvpn/src/openvpn/crypto_backend.h b/release/src/router/openvpn/src/openvpn/crypto_backend.h
index 8749878..bbc0882 100644
--- a/release/src/router/openvpn/src/openvpn/crypto_backend.h
+++ b/release/src/router/openvpn/src/openvpn/crypto_backend.h
@@ -223,12 +223,12 @@ int cipher_kt_block_size (const cipher_kt_t *cipher_kt);
 /**
  * Returns the mode that the cipher runs in.
  *
- * @param cipher_kt    Static cipher parameters. May not be NULL.
+ * @param cipher_kt    Static cipher parameters.
  *
  * @return             Cipher mode, either \c OPENVPN_MODE_CBC, \c
  *                     OPENVPN_MODE_OFB or \c OPENVPN_MODE_CFB
  */
-int cipher_kt_mode (const cipher_kt_t *cipher_kt);
+int cipher_kt_mode (const cipher_kt_t *cipher);
 
 /**
  * Check if the supplied cipher is a supported CBC mode cipher.
@@ -237,8 +237,7 @@ int cipher_kt_mode (const cipher_kt_t *cipher_kt);
  *
  * @return             true iff the cipher is a CBC mode cipher.
  */
-bool cipher_kt_mode_cbc(const cipher_kt_t *cipher)
-  __attribute__((nonnull));
+bool cipher_kt_mode_cbc(const cipher_kt_t *cipher);
 
 /**
  * Check if the supplied cipher is a supported OFB or CFB mode cipher.
@@ -247,8 +246,7 @@ bool cipher_kt_mode_cbc(const cipher_kt_t *cipher)
  *
  * @return             true iff the cipher is a OFB or CFB mode cipher.
  */
-bool cipher_kt_mode_ofb_cfb(const cipher_kt_t *cipher)
-  __attribute__((nonnull));
+bool cipher_kt_mode_ofb_cfb(const cipher_kt_t *cipher);
 
 /**
diff --git a/release/src/router/openvpn/tests/t_lpback.sh b/release/src/router/openvpn/tests/t_lpback.sh
index 8f88ad9..353b913 100755
--- a/release/src/router/openvpn/tests/t_lpback.sh
+++ b/release/src/router/openvpn/tests/t_lpback.sh
@@ -35,6 +35,9 @@ CIPHERS=$(${top_builddir}/src/openvpn/openvpn --show-ciphers | \
 # GD, 2014-07-06 do not test RC5-* either (fails on NetBSD w/o libcrypto_rc5)
 CIPHERS=$(echo "$CIPHERS" | egrep -v '^(DES-EDE3-CFB1|DES-CFB1|RC5-)' )
 
+# Also test cipher 'none'
+CIPHERS=${CIPHERS}$(printf "\nnone")
+
 "${top_builddir}/src/openvpn/openvpn" --genkey --secret key.$$
 set +e

The patch worked, but I think I built the wrong RT-N66U build, because the trx file was a full megabyte smaller than the AC build I had on there previously.
I think that build size difference (binary driver?) may have accounted for the reappearance of 24% packet loss on the connection during heavy traffic. Restoring the default 1.24 build on *just* the RTN66U (and Blowfish-CBC on the VPN) has the connection back to stable under heavy load.

What target should I be using to have the tomato-shibby-RT-AC branch build something like "tomato-RT-N66U_RT-AC6x—124-AIO-64K.trx"?

My current build "cd release/src-rt;make r64z" creates "tomato-K26USB-1.28.—defMIPSR2-AIO-64K.trx". I tried to build target "ac66z", but Make complained that it wasn't a valid target.

Successful compile of the Shibby AC66U build required building RT-N16 first in the same repository.

Script:

#!/bin/bash
set -ve
cd `dirname $0`
cd tomato_git_compile_RTN66U/tools/brcm
export PATH=`pwd`/hndtools-mipsel-linux/bin:`pwd`/hndtools-mipsel-uclibc/bin:$PATH
cd ../../release/src-rt-6.x
time make distclean
cd ../src-rt
time make distclean
time make r2z
sleep 10
cd ../src-rt-6.x
time make ac66z V1=124pp V2=AIO