Unlock lightning-fast Microsoft support with Magenium’s Premier Services+. Our expert team ensures seamless integration, proactive monitoring, and rapid issue resolution. Save up to 40% on costs while enjoying priority access to top-tier engineers. Experience unparalleled support today!
Recent comments
- After the initial Kong Mod 1 year 6 months ago
- Working the EXACT same 1 year 6 months ago
- While the "5 Easy Steps" 1 year 6 months ago
- R8000P would be grate to see. 1 year 6 months ago
- Have a R8000 but ordered a 1 year 6 months ago
hello and thanks Kong everything is working fine with me only the time range every time i put time range i get this error here is the picture..
http://img404.imageshack.us/img404/8885/timeswe.jpg
Will the nv64k of this build work on a Netgear WNDR4000?
You have to do it in section ... so create one section that do 22:00 - 23:59 and another that do 0:00 - 6:00
@Kong,
Hi Kong, there is a discussion over at the DD-WRT fourms about the ASUS RT-N66U router of having support by DD-WRT, this is what they say below, this is probably why I am having problems installing 20500 build to this router?. Not sure
"The nv64k flavors should work on that unit because it has a USB port and did get official native dd-wrt support. Its the RT-N66U that didn't get native nv64k dd-wrt support, no commits to svn that i know of have been added to support the Asus with nv64k, Fractal compiled a dd-wrt build that does have the support, which is available via barryware's FTP, but that support wasn't officially added to the dd-wrt tree."
Thanks
thanks for the reply BlaSTiWi i will try it now i hope it works ^^
@ kong : if you are compiling from the main dd-wrt svn, it'll still produce trailed RT-N66U builds that only support 32k nvram. The changes that are specific to the RT-N66U with nv64k CFE were not added to the main dd-wrt svn, only Fractal has made the change in his own compiled builds.
The nv64k kong builds should work on all other nv64k dd-wrt supported units that have a USB port, such as the WNDR4000, the kong nv64k builds however WILL NOT work on all nv64k units such as an E900, E1200, E1500 and will brick those units, because you have USB enabled by default, and those units don't have a USB port, so in the CFE it gets stuck at the USB initialization part - thus effectively bricking the unit in question (example: E900), which can only be recovered via serial connection. If USB was not enabled by default, the kong builds could support a wider array of units, such as all that dd-wrt support.
KONG
Congratulations ..
This is the best build of DD-WRT for broadcom routers since 2006 ( yes , 7 years ) ... i had flash my routers since 2006 thousand of times ..
Thank you for fixes FTP and Samba is working fine ..
thank you
STALonge
buddee, yes I compile from ddwrt svn, but this does not mean I compile 32k builds for the rt-n66u, in order to do 64k builds the kernel configs needs to be set to 64k, thats what I do. The change fractal submitted to the makefile is only needed if you flash from a vendor build e.g. asus, their firmware checks the firmware signature, but if you flash from a dd-wrt build this is not needed. Therefore my 64k build should work on the RT-N66U, if it does not, then there must be some other problem.
Actually since I don't need usb on by default I can disable it again. At the time I introduced that change pretty much all the units with 8MB flash had a usb port.
Upgrading from KingKong r19549 to r20500 (release dated 2-4-2013), Kingkong-nv32K-broadcom.bin, on my Asus RT-16N failed. I re-downloaded r20500, same issue. I never had this issue updating between KingKong firmware releases before.
Is there something I am doing wrong - thanks...and thanks for this and all other firmware releases you have done, KingKong.
Upppsss I'm about to do it ... I guess I better put it on hold ... does the md5 checksum matches?
Tkx!
Thanks for asking about the md5 checksum - for some reason, FireFox mis-downloaded the file twice, but Internet Explorer did fine, md5 verified okay. r20500 is installed on my Asus RT-16N and seems to basically work okay - no fancy testing yet.
@ kong, ah i see, thank you.
@ rocky13 i also must inquire: have you performed the 64k nvram CFE upgrade? Or are you still using this as you still bought it, with no mod done to it yet?
@ buddee I did the 64k nvram CFE upgrade and is working fine. I do have anyother one that is not modded at all, should I try it right from stock build?
Thanks.
unfortunately without output on serial console, while uploading the bin, it is hard to tell where it fails
@ rocky13: Ok, so you have the 64k nvram CFE, have you flashed the unit with the 64k nvram CFE with dd-wrt already or no? And if so, have you used the Fractal RT-N66U build located on barryware's FTP? its the trailed RT-N66U builds that DO HAVE the 64k CFE board detection code for working correctly with the modded CFE. My theory here is that if you use one of those trailed Fractal builds first, get dd-wrt on there functional with the 64k NVRAM CFE, you can then upgrade to one of the kong nv64k flavors of your choosing, and it should work fine then.
@ kong: serial output for which unit? RT-N66U or some other?
@ Buddee: I did install Fractal's build first, Build 20363 that is his latest one on Barryware ftp site. I have this loaded and is working. I did the hole process of upgrading to the 64k version. Now are you suggesting to flash a different build that is on barryware's site?.
Thanks.
Did this build embed a working Chillispot daemon ?
Hi Kong,
Quick question.
Since your build do run optware.
Did you compile with fpu added to config?
So the kong build is failing even after the Fractal dd-wrt build is flashed to the unit? If so, then what i said before will apply, the changes regarding the RT-N66U will have to be made to the dd-wrt svn tree before the nvram64k kong builds will work.
up '/usr/sbin/iptables -A POSTROUTING -t nat -o tun0 -j MASQUERADE;/op/etc/openvpn/vpnup.sh openvpn'
down '/usr/sbin/iptables -D POSTROUTING -t nat -o tun0 -j MASQUERADE;/opt/etc/openvpn/vpndown.sh openvpn'
I have these two lines in my openvpn.conf. which does not work in 20500,but was good in older version.
Hi Kong,
thank you for the new build.
Unfortunately it does not switch my Huawei E398 LTE stick into a modem. The last working build has been kingkong 19215 for my Asus RT-N16.
I was able to get the stick running on Ubuntu by manually switching it. Would one of you be so kind and look into the usb_modeswitch config file and check its contents concerning the E398 in the new build? I may be able to fix it myself with little support of you people.
Vendor ID: 12d1
Product ID unswitched (mass storage): 1506
Product ID switched (modem mode): 1505
The newest build recognizes the modem only as CDROM so maybe I need this Product ID also.
I'm now back on 19215 after debricking the router because the downgrade failed. I hope you understand why I don't want to check myself.
Thanks!
Benjamin
@eTaurus,
new build with updated lib3g is on the way.
@rocky, did you use thea trx or bin file to flash?
@Kong, I used the bin format when trying to upgrade
@globestar, yep you are right, the cron issue, it is a timing issue and I reported that to trac a long time ago.
I added a workaround in my usb hotplug stuff, have you tested this issue with an attached usb drive? In case you did not have an usb drive attached, can you try to attach some usb drive and test again if this helps the cron issue?
Due to the lack of space I did not add tcpdump to the smaller builds yet, only to kingkong, tcpdump might fit though.
@rocky, ok I'll upload the trx files soon so you can test if those work
@chjohans, I first have to setup a test share so I can debug this, not sure if I can do it before I upload the newest builds.
H Kong,
Did you enable FPU in the kernel config?
A request as enhancement,
Can you enable syslogd on default?
Kr, Basmaf
Edit:
Just noticed that according to /sbin/softwarerevision
build is 20537
No FPU changes in my builds. I have my own kernel config, that adds a few features I need.
The revision issue is a bit difficult to explain:-) DD-WRT has a few places were they check on the current revision in order to integrate it into the build. If I don't sync all changes then there may be differences in the revisions at some places in the build. So in this case most of it was at revision 20500 + a few fixes from never revisions + a few fixes that are not yet in dd-wrts sources.
I have a Linksys E3000, I want to hook a external hard drive to it and stream movies to my tv. After reading some on VPN and how it can help protect my browsing activities I might do that to. So do I need to use usb-ftp-samba3-dlna-nv60k-broadcom, or usb-ftp-samba3-vpn-nv60k-broadcom? Do I need 60K or 64K? I know one has VPN in the name but I thought I need dlna for usb storage. Or am I just all confused need help please.
I flashed with 20500 couldn't figure out how to get External HDD to work right minidlna said stopped. So I tried tomato-E3000USB-NVRAM60K-1.28.7501.2MIPSR2Toastman-RT-Ext the External HDD worked I could access it through windows explorer but I couldn't get a wireless device to connect.
Thanks for the response.
Can you verify that disabling FPU in BS builds could be the cause of optware failure.
Im don't have much linux kernel knowledge but i've done quite some reading after optware broke.
Changeset 20047 disabled FPU and from what I understand from it that is most likely the cause of the problems.
Thanks for your builds.
kingkong is working fine on my E3200/E4200
CIFS Automount is broken but you can do manual mount, so if you want to use the new build but can't wait just telnet/ssh into the router and do a manual mount, that's what I've been doing.
@chjohans, ok since you guys were able to manually mount I found the problem, the latest commits to dd-wrt startup scripts create the mountdir under /mnt which in official builds is a symlink to /tmp/mnt. In my builds /mnt is a real directory which can be used in automount setup. Fixing this now.
Pages