is there a link to any information on what has changed / been improved upon since 19277?
Build r19545 +++++++++ privoxy update to 3.0.19
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.
thanks for that, there doesn't seem to be much (just the update to privoxy according to the chang log) but i'll give it a try anyway.
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:
privoxy does not accept the following custom configuration:
What I did to fix it: saved the file to /opt/etc/privoxy.conf and started privoxy with
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.
I have just created a test build in this build openvpn uses polarssl instead of openssl. It looks like the openssl update does not work on mips platform
If anyone wants to test on a nv32k unit.
Can someone tell me, is there a pppoe server added to this new build of kingkong :D?
Wish I had a 32K router to test with. Kong, if you build a 60k version, I'll test that...
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.
I tried the (Extra) version on my 3500L. It caused a race in the openvpnserver process that I could only stop using kill -9 on ssh. I do have some /opt software if that might be an issue. I flashed back to 18730 for now. Thanks for the hard work. I can maybe uninstall the /opt stuff and try again if it will help.
I re-flashed 19545 (Extra) with upgraded optware. The race occurred again, so I turned off coreusb and rebooted so optware was not there and it still raced.
Top with optware updated/upgraded:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
890 root 20 0 1612 760 624 R 93.4 1.3 0:55.38 openvpnserver
3627 root 20 0 1636 632 492 R 5.4 1.1 0:00.25 top
Top with coreusb off:
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
858 843 root R 1612 2.7 98.2 /tmp/openvpnserver --config /tmp/openv
1277 1 root S 2256 3.8 0.8 httpd -p 80
1582 1581 root R 1256 2.1 0.2 top
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.
It's been a little while since the build downloads on MyOpenRouter for Kong's mod have been updated, it's currently at 19277.
Given the issues some folks are reporting, would it be appropriate to update the site download to this build? Another more recent build? Or should I hold off?
Kong (or anyone) please feel free to let me know and I'll post the appropriate updates. I could also upload this build as a separate "test" build.
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.
Thanks slobodan. I've updated the builds on the site to the latest.
I have uploaded a nv60k testbuild in Extras directory that contains openvpn with polarssl. Please test and let me know.
Kong said: I have uploaded a nv60k testbuild in Extras directory that contains openvpn with polarssl. Please test and let me know.openvpn client works on my E3000, thanks Kong. Is it openssl issue?
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
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:
# openvpn --show-engines
Sorry, PolarSSL hardware crypto engine functionality is not available
Hi guys, thanks for the update. I didn't use the latest polarssl only the one that is in ddwrt sourcetree. Now that we know about this I can look at the details.
E3000 WDS mode. The wireless keeps dropping and wireless connection with the client does not give DHCP.
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.
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.
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?
Good news (maybe): Brainslayer seems to feel that Changeset 19928 fixes OpenVPN.
Sash also changed the default HMAC algorithm (it should be SHA1 but was erroneously set to SHA256). Unfortunately, he changed it to MD5...
But that's only a minor flaw if OpenVPN really does work again.
Kong, your last test build for the E4200 (http://www.desipro.de/ddwrt/Extras/usb-ftp-samba3-vpn-nv60k-broadcom.bin) has been working well for the last month. I'd be happy to test a new KingKong build, too, when one is available.