CFE bootloader update

[jsmiddleton4]

Looked for just a bit. Football is on after all.

Looks like IF I wanted to update the already updated CFE so that the new CFE included hard coded separate MAC's I'll need help.

The update script would have to read the current "new" CFE with the NVRAM'ed updated MAC for the 2.4ghz channel and write an even newer CFE.

The current CFE update files and scripts are not designed for that purpose.

While it would be great to have the CFE be hardcoded to separately identify the MAC's, doing it with a NVRAM set as you shared or using the firmware to change the MAC of the 2.4ghz channel is straightforward and works just fine.

If its the case that they should have separate MAC's, then ASUS did mess up on this as well as the CFE thing.

 

[bird333]

It really isn't that hard. He is saying do the 'test' with the nvram commands to set the mac for pci/1/1/. Reboot your router and see if everything is working ok. If it is then do the following:

1. Take your original unaltered CFE and open it in a hex editor and change the mac for pci/1/1/ at the offset he gave you.
2. Save your CFE with the changed mac and exit the hex editor.
3. Run the CFE update with your altered original and then the new CFE should have the different macs for all 3 items.
4. Install your new CFE.
5. Profit.

 

[The Chief]

It really isn't that hard. He is saying do the 'test' with the nvram commands to set the mac for pci/1/1/. Reboot your router and see if everything is working ok.

No. it doesn't. After reboot it just reverts pci/1/1/macaddr to original value.

1. Take your original unaltered CFE and open it in a hex editor and change the mac for pci/1/1/ at the offset he gave you.
2. Save your CFE with the changed mac and exit the hex editor.
3. Run the CFE update with your altered original and then the new CFE should have the different macs for all 3 items.
4. Install your new CFE.
5. Profit.

There isn't any profit. Still shows pci/1/1 mac from et0.

Any ideas?

 

[bird333]

No. it doesn't. After reboot it just reverts pci/1/1/macaddr to original value.


There isn't any profit. Still shows pci/1/1 mac from et0.

Any ideas?

Did you do a 'nvram commit' after you set the mac before you rebooted? I honestly don't see any harm in just going ahead and changing the mac in the original CFE and doing the update again (other than the normal risk of a brick during update). If it still shows a MAC from et0 then we know the firmware is doing it for some reason. To me this needs to be fixed. Every interface needs an unique mac. Take all of the above with a grain of salt as I am not an expert here. Maybe RMerlin or ryzhov_al will chime in.

 

[The Chief]

Did you do a 'nvram commit' after you set the mac before you rebooted?

Yes, I did. After reboot it was reverted to original value.

I honestly don't see any harm in just going ahead and changing the mac in the original CFE and doing the update again (other than the normal risk of a brick during update).

That's what I've tried after unsuccessful "nvram set" attempt. Backup cfe, hex edit mac string, write it back via mtd-write, reboot, nvram edit pci/1/1/macaddr, commit, reboot. Same thing - after reboot it reverts pci/1/1/macaddr to its original value.

If it still shows a MAC from et0 then we know the firmware is doing it for some reason.

Definitely.

 

[Lost_Animal]

Guys i think that the MAC mess is FW Problem and not CFE values.

I am running now Tomato -Shibbys version and i have separate MAC on br0 eth1 - eht2 (WAN - 2.4 - 5 Ghz) which is normal.

On Asus & Merlin's FW all those MAC's are same.

So ASUS mess-up with FW (MAC) and CFE (32K).

Tomato is a Great performer and the only negative is the Slow NAS when use NTFS partitions.
I hope that Shibby can make a new version with Paragon NTFS driver (ASUS use this) because the open source 3G-NTFS is very slow.

 

[jsmiddleton4]

Lost....

I think you need to double check. I ran Shibby's and the LAN and the 2.4 channel MAC's are the same.

In your graphic I can't tell for sure but the last digits you showed are the same.

I appreciate your input bird but you leave things out like "how" to do these things.

Like how to move my older now edited with a new MAC address to the router, which directory to put it in, etc., prior to running the update.

 

[bird333]

Yes, I did. After reboot it was reverted to original value.


That's what I've tried after unsuccessful "nvram set" attempt. Backup cfe, hex edit mac string, write it back via mtd-write, reboot, nvram edit pci/1/1/macaddr, commit, reboot. Same thing - after reboot it reverts pci/1/1/macaddr to its original value.


Definitely.

So even after you wrote the hex edited cfe back (and before you did the nvram edit) the mac address was still the same?

 

[bird333]

Lost....

I appreciate your input bird but you leave things out like "how" to do these things.

Like how to move my older now edited with a new MAC address to the router, which directory to put it in, etc., prior to running the update.

I haven't done this myself but it looks like you are going to either figure out or ask ryzhov_al how to modify his script to process your file. Looking at his instructions I it looks like his script is read the cfe from the chip directly. That brings up this thought, The Chief did you run the newest version of the script during your last attempt? If so that might be why you still have the same mac because it didn't actually create a new cfe from your modded one. BTW, you can use WinScp to copy the file to /tmp or whatever directory you want. You still need to figure out how to make the script work on the cfe in the location where you have saved it.

EDIT: Forget what I said about editing the script. I re-read the instructions and step 2b describes how you can run the script on your previously saved cfe.

 

[Lost_Animal]

Lost....

I think you need to double check. I ran Shibby's and the LAN and the 2.4 channel MAC's are the same.

In your graphic I can't tell for sure but the last digits you showed are the same.

I appreciate your input bird but you leave things out like "how" to do these things.

Like how to move my older now edited with a new MAC address to the router, which directory to put it in, etc., prior to running the update.

I don't understand what you asking for...

 

[jsmiddleton4]

I put Toastman's on last night. Football was a blow out.

With Toastman's I changed the MAC's in its tab/page to do so. LAN is :60, WAN :61, 2.4 :62, 5 :64. Saved. Booted. All stayed put.

Booted just now. All "new" MAC's stayed put and survive a boot.

Lost...

I was asking you to verify your LAN and 2.4 MAC's are different. In the graphic you posted they still look to be the same.

I was asking bird for specifics on the "How to" question.

 

[Lost_Animal]

Yes .... are same !!!

 

[jsmiddleton4]

"you can use WinScp"

My understanding is we have to use Asus's orginal or Merlin's to run the CFE update script because Tomato variants turn off the ability to overwrite the CFE. But with Asus' or Merlin's the FTP access to the router's root is disabled.

So with Merlin's or Asus', the ones we have to use for the CFE script, we use Telnet, or SSH client, etc., and can't use an FTP client.

I of course could be wrong.....

 

[jsmiddleton4]

Then with Shibby's FW nothing is changed with your LAN/2.4ghz MAC's. Those two are still the same.

 

[jsmiddleton4]

I want to be careful to not make more out of this than it deserves. As far as I can tell and speculate the only time this MAY come into play as an issue is when setting up WDS/Bridge kind of setups. Again, MAY....

It does seem odd to me that anecdotally the router should have separate MAC's. That has been my experience with other dual band routers as can be seen in the instructions for those routers in setting up WDS/Bridge systems.

But I am no expert. Just because that has been what most of us in this thread have experienced that does not mean that is "right" and Asus has made a mistake.

So technically there may not be an issue.

Setting the MAC address in the firmware, via the firmware or the NVRAM command it is not writing to the CFE by the way.

 

[William]

Let me add another piece of the puzzle about mac’s on rt-n66u. Since I have tried all available firmware’s to date to set up wds network, I have used asus’s firmware and assigned mac (same as Lan) to set up wds. It worked. Knowing the assigned mac of dd-wrt firmware I experimented by using that mac 2.4ghz on asus wds setup. Thinking that maybe asus just wasn’t correct about the mac’s. This didn’t work . I just didn’t like the encryption asus offers for wds. (none or wep). That’s why I use dd-wrt for wds. (Wpa2 personal). So I think for the moment there is a reason for the asus mac’s identity being the same.

 

[jsmiddleton4]

William....

So you are using DD-WRT and the default MAC addresses, LAN and 2.4ghz the same MAC, and your WDS works fine?

 

[William]

dd-wrt wds only works with dd-wrt assigned mac's and asus wds only works with asus assigned mac's.

 

[jsmiddleton4]

Well isn't that interesting.

 

[The Chief]

So even after you wrote the hex edited cfe back (and before you did the nvram edit) the mac address was still the same?

Exactly. MAC was still the same, even after cfe hex patch.