New Build 20500 (Kong)

76 posts / 0 new
Last post
OGGY
OGGY's picture
hello and thanks Kong

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

kuroukage
kuroukage's picture
Will the nv64k of this build

Will the nv64k of this build work on a Netgear WNDR4000?

BlaSTiWi
BlaSTiWi's picture
You have to do it in section

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

OGGY said: 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

 

 

rocky13
rocky13's picture
@Kong,

@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

OGGY
OGGY's picture
thanks for the reply BlaSTiWi

thanks for the reply BlaSTiWi i will try it now i hope it works ^^

buddee
buddee's picture
@ kong : if you are compiling

@ 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.

STALonge
STALonge's picture
KONG

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

Kong
Kong's picture
buddee said: @ kong : if you

buddee said: @ 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.

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.

ecsaltz
ecsaltz's picture
Upgrading from KingKong

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.

BlaSTiWi
BlaSTiWi's picture
ecsaltz said: Upgrading from

ecsaltz said: 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!

ecsaltz
ecsaltz's picture
BlaSTiWi said:

BlaSTiWi said:

ecsaltz said: 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.

buddee
buddee's picture
@ kong, ah i see, thank you.

@ 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?

rocky13
rocky13's picture
@ buddee I did the 64k nvram

@ 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.

Kong
Kong's picture
unfortunately without output

unfortunately without output on serial console, while uploading the bin, it is hard to tell where it fails

buddee
buddee's picture
@ rocky13: Ok, so you have

@ 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?

rocky13
rocky13's picture
@ Buddee: I did install

@ 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.

yzy-oui-fi
yzy-oui-fi's picture
Did this build embed a

Did this build embed a working Chillispot daemon ?

basmaf
basmaf's picture
Hi Kong,

Hi Kong,

Quick question.
Since your build do run optware.
Did you compile with fpu added to config?

buddee
buddee's picture
rocky13 said: @ Buddee: I did

rocky13 said: @ 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.

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.

debiansid
debiansid's picture
up '/usr/sbin/iptables -A

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.

eTaurus
eTaurus's picture
Hi Kong,

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

Kong
Kong's picture
@eTaurus,

@eTaurus,

new build with updated lib3g is on the way.

@rocky, did you use thea trx or bin file to flash?

rocky13
rocky13's picture
@Kong, I used the bin format

@Kong, I used the bin format when trying to upgrade

Kong
Kong's picture
@globestar, yep you are right

@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.

basmaf
basmaf's picture
H Kong,

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

Kong
Kong's picture
basmaf said: H Kong, Did you

basmaf said: 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.

scottl523
scottl523's picture
I have a Linksys E3000, I

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.

basmaf
basmaf's picture
Kong said:

Kong said:

basmaf said: 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.

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

BlaSTiWi
BlaSTiWi's picture
chjohans said: @kong Found

chjohans said: @kong Found your new builds 20575, but CIFS Automount is still broken in that build. Please let me know what I can do to help you debug this as I really need it to work and right now I'm stuck on 18730 because builds between that an 20500 does not have a working OpenVPN, and my setup requires both :)

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.

Kong
Kong's picture
@chjohans, ok since you guys

@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