CFE bootloader update

[lfbb]

The new CFE works fine, with all the variables, but I still can't access miniWeb Server. Anyone has a clue?

Thanks

- lfbb

 

[Lost_Animal]

You can see that in system log. Search for this string:

- lfbb

Thanks again for your help....

My system logs showning....

Jan 1 02:00:10 kernel: _nvram_init: allocat header: 2280783872, size= 65536

And still i am on old CFE 1.0.1.2.

So maybe asus did the trick on newer versions of Fw and upgraded the nvram to 64k without change the version header on CFE.

 

[Koenig]

Thanks again for your help....

My system logs showning....

Jan 1 02:00:10 kernel: _nvram_init: allocat header: 2280783872, size= 65536

And still i am on old CFE 1.0.1.2.

So maybe asus did the trick on newer versions of Fw and upgraded the nvram to 64k without change the version header on CFE.

Nope that is still the "firmware hack" and it works as well.

The only reason for doing this update is for making the CFE able to see 64kB nvram variables at boot. (if you want to overclock, or do something else very advanced.)

 

[lfbb]

But I still can't get miniWeb Server to work.

- lfbb

 

[RogerSC]

assuming you have 1.0.1.2 cfe in cfe_old.bin:
1. extract nvram from the origianl cfe to nvram.txt, using offset autodetection

2. edit nvram.txt as you like (replace bl_version and add odmpid, for example)
3. prepare new 1.0.1.3 cfe with no nvram embedded

4. install modified nvram.txt into new cfe, using offset 0x400 and length 4092 (suitable for 1.0.1.3 cfe)

5. do something on your own with cfe_new.bin

yes, these sdram* values are reserved in header and may not appear in embedded nvram, if not used.

Okay, I'm trying to use a borrowed cfe version 1.0.1.2. Following this procedure, I now have the borrowed nvram.txt file from cfe version 1.0.1.2, where I can modify it to match my router. My understanding is that I need to get my router's MAC address into where the one from the router was borrowed. I see these MAC addresses in nvam.txt:

et0macaddr=
pci/1/1/macaddr=
pci/2/1/macaddr=

Of these, et0macaddr and pci/1/1/macaddr are the same, this might be the main MAC address of the router.

But pci/2/1/macaddr is a different MAC address, all the hex digit pairs are the same except the last one, that's different by 4 from the other two MAC addresses (that were the same *smile*).

So, it looks like all I need to do is get the right MAC addresses into these variables. Can anyone help as to what each of these variables represents? There's a chance that this might be:

et0macaddr= Main router MAC address?
pci/1/1/macaddr= 2.4 GHz. wireless MAC address?
pci/2/1/macaddr= 5.0 GHz. wireless MAC address?

Since what I'm seeing in the nvram.txt file looks like three separate functional units, I'm guessing that the above may be correct.

 

[lfbb]

Roger, I was looking into my nvram variables and you're right about the MACs.

et0macaddr=XX:XX:XX:00:7D:30 ->main

pci/2/1/macaddr=XX:XX:XX:00:7D:34 ->5GHz

pci/1/1/macaddr=XX:XX:XX:00:7D:30 ->2.4GHz

- lfbb

 

[chjohans]

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.

 

[RogerSC]

Roger, I was looking into my nvram variables and you're right about the MACs.

- lfbb

Thanks, very helpful, I think that I may be set then. I'll just put in my MAC addresses, and may just decide to go for it *smile*. I need to look at the final 1.0.1.3 that I get and make sure that the differences are reasonable. I don't feel that this is something that I have to do, but I'd like to get this issue taken care of.

 

[Pierino]

Roger, did you ever figure out what < Ate_power_on_off_ret=2 is about?

 

[RogerSC]

Roger, did you ever figure out what < Ate_power_on_off_ret=2 is about?

Nope, haven't gotten that far yet. Just got the new nvram.txt with my MAC addresses in it and am now ready to go onto the next step. I'm happy to go slow on this one, and verify everything. I'm going to be doing some poking around on the internet, and I also noticed that someone else posted recently about the same diffs that you and I have. Maybe their questions will get answered in the interim, which will answer ours, too *smile*.

 

[Pierino]

Using a different linux distro did not make a difference. Still got that extra line. The first time I did this, I installed ubuntu as dual boot on my laptop, now I am doing it using a live cd.
I wonder if that makes any difference. I removed the Ubuntu install after the last conversion, maybe I should install it again?

 

[Koenig]

Using a different linux distro did not make a difference. Still got that extra line. The first time I did this, I installed ubuntu as dual boot on my laptop, now I am doing it using a live cd.
I wonder if that makes any difference. I removed the Ubuntu install after the last conversion, maybe I should install it again?

You should not run the script, the nvsimple included has bugs

Here is an updated one: http://forums.smallnetbuilder.com/showpost.php?p=53840&postcount=272

 

[RogerSC]

Okay, new idea. I've extracted my current cfe (1.0.1.3) on my router. If the only thing wrong with it is this:

vlan1ports=1

in the nvram.txt that I got using nvsimple-32 (the latest version), why can't I just change this to:

vlan1ports=1 2 3 4 8*

and then put it back into the blank 1.0.1.3 cfe (cfe_n66u-1.0.1.3.empty.bin) and go from there with a cfe that I'm pretty sure will have the right MAC addresses, secret_code, etc. that will work with my router?

Would this work? Seems easier and safer for those of us (probably just me, actually *smile*) that don't have their cfe.original or cfe.old.

Is there anything that I haven't thought of or am not aware of?

Sounds good to me, anyways.

Thanks.

 

[Pierino]

You should not run the script, the nvsimple included has bugs

Here is an updated one: http://forums.smallnetbuilder.com/showpost.php?p=53840&postcount=272

I ran the script using the new nvsimple and I get the same output.

 

[eacmen]

RT-N66R CFE Update

NOTE: as ifbb pointed out, my script below does not fix the vlan1ports issue, it will likely brick your CFE recovery. DO NOT USE the script below. I will leave it here as a reference so someone can develop a patch to support the RT-N66R.


I took the plunge to update my CFE on a RT-N66R (RT-N66U models sold retail and were supposedly "identical"). I realized quickly that there was an issue when the diff between the two nvram files were not as expected. It looked like this:

$ ./cfe_update.sh cfe.original cfe.new
[1/4] Dumping default NVRAM settings from your CFE...
nvram start 0x400
nvram end 0x13e8
nvram len 4052
nvram crc 0xcb
nvram ver 0x01
[2/4] Modifying NVRAM settings (silent step)...
[3/4] Creating new CFE...
4092+0 records in
4092+0 records out
4092 bytes (4.1 kB) copied, 0.177994 s, 23.0 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
4c4
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
177c177
< wait_time=3
---
> wait_time=?????
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.new' is prepared for flash.

Looking at nvram.old:

ate_power_on_off_enable=4
Ate_power_on_off_ret=2
ate_reboot_log=1,2,
bl_version=1.0.1.2
boardflags=0x00000110
boardflags2=0x00000000
boardnum=00
boardrev=0x1100
boardtype=0xF5B2
boot_wait=on
clkfreq=600,300,150
....
lan_ipaddr=192.168.1.1
lan_netmask=255.255.255.0
odmpid=RT-N66R
....

I modified the cfe_update.sh to replace the odmpid value with "ASUS":

#!/bin/sh

if [ -z $1 ] || [ -z $2 ]; then
echo "Usage: "$(basename $0)" cfe.old cfe.new"
exit 1
fi

echo [1/4] Dumping default NVRAM settings from your CFE...
./nvsimple $1 > nvram.txt

echo [2/4] Modifying NVRAM settings \(silent step\)...
sed -i 's/bl_version=1.0.1.2/bl_version=1.0.1.3/g' nvram.txt
sed -i 's/odmpid=RT-N66R/odmpid=ASUS/g' nvram.txt
# echo "odmpid=ASUS" >> nvram.txt

echo [3/4] Creating new CFE...
start=1024
count=4092
dd if=/dev/zero of=$2 bs=1 seek=$start count=$count
./nvserial -i cfe_n66u-1.0.1.3.empty.bin -o $2 -b $start -c $count nvram.txt

echo [4/4] Checking differences between NVRAM from old and new CFE\'s
./nvsimple $1 2>/dev/null | sort > nvram.old
./nvsimple $2 2>/dev/null | sort > nvram.new
diff nvram.old nvram.new
echo 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 \'$2\' is prepared for flash.

# rm nvram.txt nvram.old nvram.new

Once I made this modification cfe_update worked as advertised:

$ ./cfe_update.sh cfe.original cfe.new
[1/4] Dumping default NVRAM settings from your CFE...
nvram start 0x400
nvram end 0x13e8
nvram len 4052
nvram crc 0xcb
nvram ver 0x01
[2/4] Modifying NVRAM settings (silent step)...
[3/4] Creating new CFE...
4092+0 records in
4092+0 records out
4092 bytes (4.1 kB) copied, 0.184513 s, 22.2 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
4c4
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
20c20
< odmpid=RT-N66R
---
> odmpid=ASUS
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.new' is prepared for flash.

I flashed the cfe.new image onto the pmon MTD block and everything worked fine. I make no guarantees that this will work on all RT-N66Rs, but it worked for me. I am now running the 64k DD-WRT 20202 build from the barrywares FTP server.

I hope this helps people that might have RT-N66Rs...

 

[RogerSC]

Okay, new idea. I've extracted my current cfe (1.0.1.3) on my router. If the only thing wrong with it is this:

vlan1ports=1

in the nvram.txt that I got using nvsimple-32 (the latest version), why can't I just change this to:

vlan1ports=1 2 3 4 8*

and then put it back into the blank 1.0.1.3 cfe (cfe_n66u-1.0.1.3.empty.bin) and go from there with a cfe that I'm pretty sure will have the right MAC addresses, secret_code, etc. that will work with my router?

Would this work? Seems easier and safer for those of us (probably just me, actually *smile*) that don't have their cfe.original or cfe.old.

Is there anything that I haven't thought of or am not aware of?

Sounds good to me, anyways.

Thanks.

Okay, changed the nvram.txt that I extracted from my current CFE on the router (1.0.1.3 as mentioned above), modified the "vlan1ports" variable, are putting it back into the blank 1.0.1.3 cfe resulted in:

./nvsimple-32 --install nvram.real.mod.txt cfe.real.mod -o 0x400 -l 4092 -v
nvram header created:
start 0x400
end 0x1368
len 3944
crc 0xe2
ver 0x01

which is a bit shorter in the header area than I was expecting.

I also extracted the nvram.txt parts of the orginal cfe from the router, and the new, modified cfe, and the only difference was the one change in vlan1ports mentioned above. No surprise, but good to verify that I didn't change anything else.

But I'm thinking that this is going to work *smile*.

Any comments?

 

[lfbb]

I flashed the cfe.new image onto the pmon MTD block and everything worked fine. I make no guarantees that this will work on all RT-N66Rs, but it worked for me.

Are you able to access the CFE miniWeb Server?

- lfbb

 

[eacmen]

Are you able to access the CFE miniWeb Server?

- lfbb

Yes I was *just* looking at that. I did this before the code was updated. I believe my CFE recovery is bricked... I was just lucky that I didn't need it. I am going to download the new code and fix my CFE.

strings cfe.new | grep vlan1
vlan1ports=1
vlan1hwname=et0
landevs=vlan1

 

[Lost_Animal]

Add another happy owner of a cfe 1.0.1.3 bl_version.

I followed the instructions of 1st post and all procedure was fine.

manolis@manolis-laptop:~$ ./cfe_update.sh cfe.bin cfe.new
[1/4] Dumping default NVRAM settings from your CFE...
nvsimple 0.2b (c) theMIROn
nvram start 0x400
nvram end 0x1388
nvram len 3956
nvram crc 0x58
nvram ver 0x01
[2/4] Modifying NVRAM settings (silent step)...
[3/4] Creating new CFE...
4092+0 records in
4092+0 records out
4092 bytes (4.1 kB) copied, 0.0723049 s, 56.6 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
1c1
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
16a17
> odmpid=ASUS
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.new' is prepared for flash.
manolis@manolis-laptop:~$

Uploaded the cfe.new to my router and make the flash.

And after a complete vnram delete - reboot - and upload my saved CFG , now i get

admin@(none):/tmp/home/root# strings /dev/mtd0ro | grep bl_version
bl_version=1.0.1.3

So .... all are fine and now i'm free to Upload any firmware i like (Including all DD-WRT ones) without any danger to kill my router (Or NOT ?).

Thanks for your help ...

PS... Currently running Merlin's ASUS_WRT latest FW....

UPDATE....

Tested also the 20Sec boot delay test and passed with success....

Are you able to access the CFE miniWeb Server?

- lfbb

I am able to access the CFE miniWeb Server and no problem to report so far....

 

[lfbb]

I am able to access the CFE miniWeb Server and no problem to report so far....

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