CFE bootloader update

[Lost_Animal]

Damn, I'm having problems with that. When I press 'reset+power on' the router enters rescue mode but I can't access it via 192.168.1.1

Is there another way to exit rescue mode besides using Firmware Restoration tool?

- lfbb

I can't imagine why you have this problem.

You have set static IP on your NIC side ?
Did you get some strange messages from your OS Firewall like Port Scanning ?

In my case, when entering on Quick Internet Setup or CFE miniWeb Server, My Firewall (ESET) blocking 192.168.1.1 due to port & IP scan and i had to disable firewall (ESET) to get access on CFE mWS..

 

[lfbb]

My windows firewall is disconnected, I use the router's firewall. My previous CFE didn't have this problem(it had others).

- lfbb

 

[Lost_Animal]

Did you tried to revert back to old CFE .02 and test the connection on CFE mWS ?

 

[lfbb]

I used the CFE mWS in the previous version(the 1.0.1.3 buggy one) and it worked fine.

- lfbb

 

[eacmen]

ryzhov_al - or someone else who might know

I did a successful update of my CFE before the latest version which added "vlan1ports=1 2 3 4 8*". All went well and I've been running Stock firmware, Merlins firmware, tomato and dd-wrt on my unit since then.

Now I wanted to flash an updated CFE as I want a working recovery mode. But, the output from the script is now different, and what it tells you to check is not what it outputs. This is my result when creating a new cfe:

***

[4/4] Checking differences between NVRAM from old and new CFE's
2d1
< Ate_power_on_off_ret=2
4c3
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
176d174
< wait_time=3
If you see only two differences: one is for 'bl_version' and second is a new 'odmpid=ASUS' variable then all step are done! New CFE image 'cfe.64k' is prepared for flash.

***

I see *three* differences as shown above, and it does not match what the text in your scripts asks me to look for. Two variables I didn't see before and I no longer see the 'odmpid=ASUS' variable that your script asks me to look for.

A "strings cfe.64k | grep odmpid" returns nothing so the odmpid variable has not been included in the new cfe generated by your script.

I already upgraded to your previous version with no problems, but I don't dare flashing the resulting CFE this time until you clearify.

I see others both here and over at the dd-wrt forum that are confused by this, and nobody has so far clearified the situation.

To me it seems like the new version of your script is somehow broken, and the cfe generated by your new script has more differences than just "vlan1ports=1" replaced by "vlan1ports=1 2 3 4 8*".

Please clearify the situation.

chjohans, RogerSC

I am having the Ate_power_on_off_ret=2 issue as well. I have tracked it to the fact that when nvsimple runs it adds four variables to the nvram.txt file:

sdram_init=0x0000
sdram_config=0x0000
sdram_refresh=0x0000
sdram_ncdl=0x00000000

These variables are not present in my original CFE image, I am not sure exactly why they are added to the list of nvram variables by nvsimple - maybe someone more knowledgable can respond. When these four variables are added, it exceeds the maximum size reserved for nvram variables in the CFE. By default, nvram is between bytes 1044 and 5136 in the file (for a size of 4092). Look at the following:

$ ls -al nvram.*
-rw-r--r-- 1 501 dialout 4054 2012-12-03 19:24 nvram.new
-rw-r--r-- 1 501 dialout 4104 2012-12-03 19:24 nvram.old
-rw-r--r-- 1 501 dialout 4101 2012-12-03 19:24 nvram.txt

As you can see above the size of nvram is exceeding 4092 bytes and the variables are getting truncated in the resulting image (clearly not good).

Can anyone give us some insight as to why the sdram_* variables are getting added into nvram.txt by nvsimple?

thanks!

 

[Pierino]

Lol, I've been asking about that extra line for 2 days.

 

[lfbb]

Can anyone give us some insight as to why the sdram_* variables are getting added into nvram.txt by nvsimple?

http://forums.smallnetbuilder.com/showpost.php?p=53850&postcount=277

- lfbb

 

[RogerSC]

Can anyone that understands the cfe better than I do (like ryzhov_al or theMIROn) please comment on whether what I've done is likely to work or I've missed something:

http://forums.smallnetbuilder.com/showpost.php?p=53916&postcount=296

Thanks very much.

 

[Pierino]

Someone who is helping me at the dd-wrt forums thinks I may have made a mistake in obtaining my cfe.original back in October.
He thinks that may be the reason I'm getting the < Ate_power_on_off_ret=2 line.

 

[RogerSC]

Someone who is helping me at the dd-wrt forums thinks I may have made a mistake in obtaining my cfe.original back in October.
He thinks that may be the reason I'm getting the < Ate_power_on_off_ret=2 line.

Yes, while I don't have my original cfe anymore, I don't see that extra stuff in the 1.0.1.3 version that I do have, either. Since it doesn't look like nvsimple would take that stuff out, that sounds right, that they got in there somehow when you got your cfe.original. Maybe some sort of buffering problem or something...

 

[ryzhov_al]

okie, folks, here's new solution
...
calculations seems ok comparing nvserial, not well tested.
have fun, but handle with care.

Great! I'll fix update script, which will allow to update CFE right on the router.

 

[chjohans]

Great! I'll fix update script, which will allow to update CFE right on the router.

ryzhov_al

Could you *please* comment on and clearify regarding the situation where we all get a different result than before when running the version of your script in your latest archive: cfe_n66u-1.0.1.3-3.tgz ?!?

I didn't dare to flash the resulting CFE. According to someone else on the forum your script has a flaw where you now exceed the space reserved for variables.

Has this version of the script, and the resulting CFE, ever been tested and confirmed?

 

[themiron]

Could you *please* comment on and clearify regarding the situation where we all get a different result than before when running the version of your script in your latest archive: cfe_n66u-1.0.1.3-3.tgz ?!

Guess I can give some light on it:
1. first version of the script used nvsimple 0.1 to extract text nvram and nvserial to install it into cfe. that nvsimple version has bug with nvram values containing spaces, so any name="value1 value2 value3" becomes name=value1. that's why recovery mode was broken after
2. next version of the script used nvsimple 0.2* which correctly extracts all spaced value. due nvserial need to know sdram_* values to make correct nvram header, that lines really need to be exported. nvserial is dumb enough to install all lines of nvram, so result contains all sdram_* as well => leads to embedded 1.0.1.3 nvram overflow. that's why several last nvram lines were just lost from cfe_new
3. nvsimple 0.3 correctly extracts nvram values and has the ability to install them, with special handling of sdram_* lines. that means nvserial (x86 only binary) isn't required now, and if sdram_* values are zero/not used, they will not be added to the resulting bin nvram => no overflow issue
if anything with nvsimple 0.3 needs to be improved, let me know or just grab the archice I've posted on a previous pages and send me a patch.
hope it helps to stop the panic

 

[ryzhov_al]

Now you may update CFE right on the router

Ok, all tools is compiled to work on router itself, no PC is needed.
Instructions from the first post updated too.

 

[lfbb]

3. nvsimple 0.3 correctly extracts nvram values and has the ability to install them, with special handling of sdram_* lines. that means nvserial (x86 only binary) isn't required now, and if sdram_* values are zero/not used, they will not be added to the resulting bin nvram => no overflow issue

Nevertheless those 4 sdram* variables are present in nvram.

- lfbb

 

[ryzhov_al]

ryzhov_al

Could you *please* comment on and clearify regarding the situation where we all get a different result than before when running the version of your script in your latest archive: cfe_n66u-1.0.1.3-3.tgz ?!?

Nevermind, cfe_n66u-1.0.1.3-4.tgz is out, will work on router.

I didn't dare to flash the resulting CFE. According to someone else on the forum your script has a flaw where you now exceed the space reserved for variables.

Instead of Broadcom's proprietary nvserial, theMIROn's nvsimple tool is used, with space checking.

Has this version of the script, and the resulting CFE, ever been tested and confirmed?

As for me, I check every script on my RT-N66U before posting.

 

[TeHashX]

Ok, all tools is compiled to work on router itself, no PC is needed.
Instructions from the first post updated too.

I get error: not an http or ftp url
admin@(none):/tmp/home/root# wget --no-check-certificate http://github.com/downl
oads/ryzhovau/asuswrt-ryzhov/cfe_n66u-1.0.1.3-4.tgz
Connecting to github.com (207.97.227.239:80)
wget: not an http or ftp url: https://github.com/downloads/ryzhovau/asuswrt-ryzhov/cfe_n66u-1.0.1.3-4.tgz

Than I manually downloaded in /tmp and error again:
admin@(none):/tmp# tar -xf ./cfe_n66u-1.0.1.3-4.tgz
tar: invalid tar magic

 

[redcloud]

admin@(none):/tmp# tar -xf ./cfe_n66u-1.0.1.3-4.tgz
tar: invalid tar magic

Try: tar -zxf ./cfe_n66u-1.0.1.3-4.tgz

 

[Pierino]

So if I use my cfe.original with the extra variables in it, with the new 1.0.1.3-4 tgz, will I get a correct usable 1.0.1.3 cfe?

 

[TeHashX]

It's safe to update, because cfe.original is 256 kib and cfe.new is 130 kib?