jsmiddleton4
Very Senior Member
frit....
There is no talk of a bug "fix". The talk is is it or is it not a bug to be fixed.
There is no talk of a bug "fix". The talk is is it or is it not a bug to be fixed.
CFE bootloader update
- Thread starter ryzhov_al
- Start date
- Status
fritsp1989
Regular Contributor
If i want to apply the new patch should i first flash back the 1.0.2 CFE ?
Successfully patched and updated to 1.0.0.3 using OS X. If anyone has a Mac, here are the steps I took:
Unfortunately tomato-K26-1.28.RT-N5x-MIPSR2-104-Mini (Shibby's Build) won't partition the NVRAM for 64K. I could use the special 64K builds he has but I don't need all the features in those large builds and I'm afraid they could brick the RT-N66U with the updated CFE.
So quick question, does anyone know if Toastman's generic NVRAM64K builds work with the 1.0.0.3 CFE (without bricking after you write more than 32K)?
P.S. Shibby if you ever come across this post, do a native 64K Mini build.
Unfortunately tomato-K26-1.28.RT-N5x-MIPSR2-104-Mini (Shibby's Build) won't partition the NVRAM for 64K. I could use the special 64K builds he has but I don't need all the features in those large builds and I'm afraid they could brick the RT-N66U with the updated CFE.
So quick question, does anyone know if Toastman's generic NVRAM64K builds work with the 1.0.0.3 CFE (without bricking after you write more than 32K)?
P.S. Shibby if you ever come across this post, do a native 64K Mini build.
Last edited:
jsmiddleton4
Very Senior Member
Using Toastman's 64K with EXT support currently and loaded it after the CFE update.
No problems. Even seems to keep the MAC addresses straight.
No problems. Even seems to keep the MAC addresses straight.
Using Toastman's 64K with EXT support currently and loaded it after the CFE update.
No problems. Even seems to keep the MAC addresses straight.
Did you hex edit in a new mac?
jsmiddleton4
Very Senior Member
Nope. Didn't touch the CFE regarding MAC's.
Toastman assigns them as one would expect without doing anything to the CFE.
Toastman assigns them as one would expect without doing anything to the CFE.
No, just follow this post:
http://forums.smallnetbuilder.com/showpost.php?p=49790&postcount=1
Since you've already updated, you would follow "2b." rather than "2a." in the above post.
The main thing to note is that you do have to have the original CFE 1.0.1.2 that you started with, or follow the "And here is original stock CFE 1.0.1.2 for those who never make a backups" at the bottom of the above posting to re-create a CFE 1.0.1.2 for your router that you can use for the update.
jsmiddleton4
Very Senior Member
If you use the stock "old" cfe from on-line you have to update its MAC addresses to your router's.
Yes, there are directions for that with the CFE that's online.
What do you mean "old" CFE? Are you meaning before the -4 update?
Last night I did the CFE change to .3 and then tried to install DD-WRT (latest fractal build for 64k). The install went quite well but no MAC for the WAN.
I installed Merlin right after that an no issues with Merlin.
I am going to read this entire thread and see if I can figure out what has gone wrong but if there is an obvious simple fix please let me know. When I tried to install tomato AIO 64k that immediately gave me an error and wouldn't upload. I will try to see why that is happening later. I think I want DD-WRT but can be convinced that another firmware is for me! The options I need for sure are VPN and DDNS.
Can you please describe exactly what you did when updating your router's CFE? I don't know what the "-4 update" is, maybe someone else does?
Used the web GUI (Safari 6.0.2) to load Merlin's RT-N66U_3.0.0.4_260.21
Waited 5 minutes and then Powered off the router
Held down WPS button for 15 seconds while powering back on to clear NVRAM
Set User Name & Password to "admin" and Enabled Telnet (on the Router)
Formated a Thumbdrive with a single FAT16 partition and plugged it in the router
Opened up Terminal;
telnet 192.168.1.1
admin
admin
cd /tmp/mnt/sdb1/
wget http://wl500g-repo.googlecode.com/fi...-1.0.1.3-4.tgz
tar -xzf ./cfe_n66u-1.0.1.3-4.tgz
./cfe_update.sh /dev/mtd0ro
y
exit
Waited 60 seconds, Powered off router and unpluged Thumbdrive
Held down WPS button for 15 seconds while powering back on to clear NVRAM
Re-loaded the Tomato Shibby build I was using
Verified bl_version: Tools > System > type "strings /dev/mtd0ro | grep bl_version" > Click Execute
I did that like back in post 443 all except the Tomato Shibby portion and I didn't do it on a MAC but a PC.
So you hadn't updated your router before, and essentially used the new update stuff to update it in place. Sounds fine to me. Your old CFE (cfe.old) was the current one at that time that ./cfe_update.sh extracted from the router before updating it. As long as you hadn't updated before (you still have the original CFE that came with your router), that should have worked fine, and most likely did.
I verified before I started that it was 1.0.1.2, I had the latest merlin on there before I started this process. I have never done this process before.
So there isn't something obvious I did wrong?
mstombs
Very Senior Member
Bit late to the party - but re some comments earlier. The MAC addresses inside the CFE are the default nvram vars that are used to re-populate the nvram vars on a hard reset which clears/corrupts the nvram. To experiment with different vars just change the current nvram ones using "nvram set .... nvram commit reboot" sequence, then you can always revert to safe default. Both the CFE and the firmware use the live nvram vars as long as the nvram block is valid. Firmwares will also apply their own nvram defaults, they really shouldn't invent MAC addresses or there will be problems with interoperability with routers running the same firmware!
Routers normally have one unique MAC address printed on the box and router label.
On my RT-N16 I have access to here there are only 2 MAC addresses in the CFE, but only the one which matches the case label seems to be important.
Some firmware has used this MAC address to be the LAN Ethernet MAC address the WAN gets the MAC+1, the WLAN MAC+2. (ISTR Linksys used to do this with the WRT54GL).
I don't know if Asus assign MAC addresses with gaps for this to happen, but comments in the Asus CFE default nvram suggest MAC addresses are not as unique as they used to be.
This generation of extra virtual MAC addresses is definitely firmware specific - reinforcing the usual recommendation to erase nvram and reset to defaults when changing firmwares - in case your new firmware make assumptions about how they are assigned!
Routers normally have one unique MAC address printed on the box and router label.
On my RT-N16 I have access to here there are only 2 MAC addresses in the CFE, but only the one which matches the case label seems to be important.
Some firmware has used this MAC address to be the LAN Ethernet MAC address the WAN gets the MAC+1, the WLAN MAC+2. (ISTR Linksys used to do this with the WRT54GL).
I don't know if Asus assign MAC addresses with gaps for this to happen, but comments in the Asus CFE default nvram suggest MAC addresses are not as unique as they used to be.
This generation of extra virtual MAC addresses is definitely firmware specific - reinforcing the usual recommendation to erase nvram and reset to defaults when changing firmwares - in case your new firmware make assumptions about how they are assigned!
Nope, nothing that I see, assuming that you hadn't done anything to your existing CFE (1.0.1.2). What you did looks like exactly the prescribed procedure.
jsmiddleton4
Very Senior Member
"Some firmware has used this MAC address to be the LAN Ethernet MAC address the WAN gets the MAC+1, the WLAN MAC+2."
Yep. That apparently is not what the Asus default/core firmware is doing however.
Toastman's, Shibby's the Tomato core FW's look to be reading the CFE for the LAN MAC and then building MAC's from there.
So each device has a unique MAC as you indicated following the +1 process on up the chain.
Why the Asus FW is leaving the 2.4ghz channel and the LAN MAC's the same is still unclear.
It does seem to be clear, still not 100%, that it is the FW not the CFE that is building the MAC's. And that conclusion is based on the observation that those who have changed the various MAC's in the CFE, they did not see the change reflected in the GUI/FW.
It appears that even the Asus FW starts with the assigned LAN MAC and goes from there BUT leaves the 2.4ghz channel as the LAN MAC.
That does seem to be an over sight however. I do think, as others have noted, that is consistent with other routers. The "norm" is to have each device with a separate MAC.
The reason behind needing to understand where which MAC is coming from is one way we're looking at hex edit and changing MAC values in the CFE. The other process means FW is the target.
With Toastman's I hit "Default" for MAC's and the FW changes the MAC's to what one would expect, I hit save, and I'm off and rolling with unique MAC addresses and no problems.
Yep. That apparently is not what the Asus default/core firmware is doing however.
Toastman's, Shibby's the Tomato core FW's look to be reading the CFE for the LAN MAC and then building MAC's from there.
So each device has a unique MAC as you indicated following the +1 process on up the chain.
Why the Asus FW is leaving the 2.4ghz channel and the LAN MAC's the same is still unclear.
It does seem to be clear, still not 100%, that it is the FW not the CFE that is building the MAC's. And that conclusion is based on the observation that those who have changed the various MAC's in the CFE, they did not see the change reflected in the GUI/FW.
It appears that even the Asus FW starts with the assigned LAN MAC and goes from there BUT leaves the 2.4ghz channel as the LAN MAC.
That does seem to be an over sight however. I do think, as others have noted, that is consistent with other routers. The "norm" is to have each device with a separate MAC.
The reason behind needing to understand where which MAC is coming from is one way we're looking at hex edit and changing MAC values in the CFE. The other process means FW is the target.
With Toastman's I hit "Default" for MAC's and the FW changes the MAC's to what one would expect, I hit save, and I'm off and rolling with unique MAC addresses and no problems.
Oddly doing it one more time was what was needed .... it's the oddest thing.
That is odd. Glad that you got it going.
I think the bottom line has to be that I didn't do it right the first two times. I hate to admit that I am human but sometimes it is necessary
- Status
Similar threads
