August 2, 2012 8:08 AM

Brackb01 said: Hi is there a link to any information on what has changed / been improved upon since 19277? thanks

There is a changelog file where you downloaded the firmware that lists all the changes between firmware versions. I suspect more information about changes will require some research at the DD-WRT website.

r19545 seems to basically work on my Asus RT- N16 - I have not really tested it out much yet.

August 3, 2012 3:40 AM

Build 19545 OpenVPN fails in the same way that all Kong builds after 18730 have failed.

On the DD-WRT bug tracker, Kong advised diagnosing the problem by comparing strings in 18730's openvpn with strings in 19545's openvpn. The results were interesting: Large sets of strings apparently related to OpenSSL (names of ciphers and protocols, PKCS12_xxxx and SSL_xxxx and X509_xxxx symbols, etc.) are present in 18730 but missing in 19545.

The raw strings output from each build is attached to DD-WRT bug #2536:

http://svn.dd-wrt.com/ticket/2536#comment:33

August 3, 2012 1:58 PM

Re-reading my last comment, I see that I might have given an inaccurate impression of the Kong builds when I wrote "Build 19545 OpenVPN fails in the same way that all Kong builds after 18730 have failed."

Kong's builds, of course, aren't the only ones that are failing. Judging from the comments on the DD-WRT bug tracker, unmodified DD-WRT builds since approximately build 18777 have also been failing in the same way.

August 4, 2012 3:34 PM

Can someone tell me, is there a pppoe server added to this new build of kingkong :D?

August 4, 2012 10:00 PM

fastfwd said: Wish I had a 32K router to test with. Kong, if you build a 60k version, I'll test that...

yeah, I also have E3000... Kong please build 60k, I can test that too.

August 5, 2012 2:20 PM

Hi Kong,

thank you for continuing your work.

The reason I had to go back to build r19215 is that my Huawei E398 LTE modem isn't working with build r19545. On build r19215 it works like a charm. I don't know if I get connection over LTE but the modem is recognized. Is there a way to check the type of network I'm connected to?

The problem is that the modem is not claimed by usb_modeswitch. I'm sorry that I can't give output of dmesg but I don't have time to play with such things in the moment.

On r19545 it is recognized as modem, the driver gets loaded but then the process stops and the modem stays recognized as CD-ROM. There are at the moment no AT-command for the E398 that I know of that one could use to switch of this function.

I don't need all the fancy openvpn and privoxy stuff so the r19215 is working fine for me. If it isn't possible to fix this without further information we have to wait until it is winter and I do not have so much work in the garden and with our yard. ;)

Is there an alternative to the old Optware thing and how does it work?

Looking forward to your answer.

Benjamin

August 7, 2012 3:46 AM updated: August 7, 2012 3:46 AM

If you ask me, 19545M is doing fine. I have gone back to default configuration for privoxy, so what I said above is not an important issue. For those who have problems with VPN, 18730M works best. I don't use VPN.

August 10, 2012 1:11 PM

I have uploaded a nv60k testbuild in Extras directory that contains openvpn with polarssl. Please test and let me know.

August 10, 2012 11:46 PM

Thank you, Kong. I've tested the nv60k test build on my E4200; here's what I've found:

The OpenVPN server in the nv60k test build works, but its PolarSSL library supports fewer ciphers than the OpenSSL library in build 18730. I've attached the output of the test build's openvpn cipher-listing commands below; the important thing to note is that --show-ciphers indicates that the new build lacks support for the OpenVPN default cipher, Blowfish (BF-CBC).

A VPN setup that's already configured to use one of the test build's supported ciphers (e.g., AES-256-CBC) will work as expected, but any setup that either specifies BF-CBC explicitly or that relies on the default to be BF-CBC will fail.

My configuration for 18730 didn't specify a cipher, so when I configured the new test build identically, the openvpn server didn't even start up. Once I identified the problem and reconfigured the server and one client to use AES-256-CBC, that client was able to connect, and so far in my limited testing it appears to work fine, although I haven't yet been able to test whether there's a difference in throughput between AES-256-CBC and BF-CBC.

Fortunately for me, my system includes only a small number of clients and I can easily (more or less) modify their configurations to use AES-256-CBC. It's easy to imagine, though, that many OpenVPN users won't have such access to their clients' configurations. Adding BF-CBC support to the build, if possible, would allow those users to migrate with no trouble from build 18730.

Here's the list of ciphers supported by the new test build's openvpn server:

==================================================
# openvpn --show-ciphers
The following ciphers and cipher modes are available
for use with OpenVPN. Each cipher shown below may be
used as a parameter to the --cipher option. The default
key size is shown as well as whether or not it can be
changed with the --keysize directive. Using a CBC mode
is recommended.

AES-128-CBC 128 bit default key
AES-192-CBC 192 bit default key
AES-256-CBC 256 bit default key
CAMELLIA-128-CBC 128 bit default key
CAMELLIA-192-CBC 192 bit default key
CAMELLIA-256-CBC 256 bit default key
DES-CBC 56 bit default key
DES-EDE-CBC 112 bit default key
DES-EDE3-CBC 168 bit default key

# openvpn --show-digests
The following message digests are available for use with
OpenVPN. A message digest is used in conjunction with
the HMAC function, to authenticate received packets.
You can specify a message digest as parameter to
the --auth option.

MD5 128 bit default key
SHA1 160 bit default key
SHA224 224 bit default key
SHA256 256 bit default key
SHA384 384 bit default key
SHA512 512 bit default key

# openvpn --show-tls
Available TLS Ciphers,
listed in order of preference:

SSL-EDH-RSA-AES-128-SHA
SSL-EDH-RSA-AES-256-SHA
SSL-EDH-RSA-CAMELLIA-128-SHA
SSL-EDH-RSA-CAMELLIA-256-SHA
SSL-EDH-RSA-DES-168-SHA
SSL-RSA-AES-256-SHA
SSL-RSA-CAMELLIA-256-SHA
SSL-RSA-AES-128-SHA
SSL-RSA-CAMELLIA-128-SHA
SSL-RSA-DES-168-SHA
SSL-RSA-RC4-128-SHA
SSL-RSA-RC4-128-MD5

# openvpn --show-engines
Sorry, PolarSSL hardware crypto engine functionality is not available
==================================================

August 15, 2012 2:41 AM

E3000 WDS mode. The wireless keeps dropping and wireless connection with the client does not give DHCP.

September 1, 2012 12:15 PM

I gave the new Privoxy a test run and I get poor download performance around 12Mbps on a 40Mbps connection.

Currently with build 17940 and Proxy Server running I get around 24Mbps.

For the Proxy Server, I use the Transparent non-custom settings. I was hoping the new Provoxy would fix it.

September 5, 2012 9:48 AM

slobodan said: Well, here I get at most 30 Mbps through privoxy. In itself it is not so relevant, since FTP, torrents and Usenet do not pass through privoxy and Skype, Yahoo! Messenger and Windows Live Messenger can be told to use direct connection. In order to measure real download speed use Firefox with a direct connection, of course all other downloads have to be stopped at that moment and your computer should be virus and spyware free.

Thanks for your reply and I understand that privoxy only effects content on port 80 or http. Can you test your speedtest.net connect to see what speed and ping time you get? 

TIA!