CFE bootloader update

[jsmiddleton4]

And then this?

Use FTP program, WinSCP or Filezilla, and put the CFE back to the TMP directory and then these commands?

mtd unlock cfe
mtd write -f /tmp/cfe_new.bin cfe

Its a QUESTION.....

I'm not saying those are the right commands.

 

[jsmiddleton4]

Ok so now I'm even more confused.

I've been playing with Toastman's FW waiting to load Merlin's .262.

On the MAC tab/page it showed as we've been talking about 2.4ghz and LAN same MAC.

So I hit "Default" just to see what it'd do.

Changed the MAC's for 2.4 and 5 ghz. Went from 60 to 62 and 64 to 63.

So where in the blazes is Toastman's getting the "Default" variable?

I have not edited my cfe.bin. Its still as we've been discussing, LAN and 2.4ghz the same. I know, I've now looked at my backup of it in HexD.

And if the defaults are such that the LAN and 2.4ghz are NOT the same, huh?

What is setting them to be the same?

Edit: So does the firmware read the CFE for the LAN MAC and as the MAC is considered the base MAC and then the firmware follows some algorithm to "create" the other MAC's?

So when it is reported that changing the CFE MAC's for the 2.4ghz channel make no difference that is because the firmware doesn't read the 2.4ghz MAC from the CFE? The firmware doesn't look that far into the CFE for the MAC? The firmware sees the first MAC listed, which near as I can tell by looking at my CFE.BIN is the LAN MAC, the firmware takes that MAC and calculates the others?

You would be able to change the 2.4 ghz all day in the CFE and not see a change in the firmware.

Someone with more knowledge then I regarding the firmware, not the CFE, would have to look and see how the MAC addresses are established as in "read the cfe for all MAC's and pass those along to the firmware" OR "read the LAN MAC and create the rest in the firmware"......

The process would of course make a huge difference in terms of the fix.

The pattern, LAN MAC is base line, WAN MAC is +1, 2.4ghz is +2 and 5ghz is +3 is the same pattern as in my E3000.

 

[barryware]

And then this?

Use FTP program, WinSCP or Filezilla, and put the CFE back to the TMP directory and then these commands?

mtd unlock cfe
mtd write -f /tmp/cfe_new.bin cfe

Its a QUESTION.....

I'm not saying those are the right commands.

I'm a windows user so I use winscp. You must enable ssh on the router 1st to use winscp.

that write command is when running dd-wrt.

running a merlin build use:

mtd-write -i cfe.new -d pmon

this assumes that your new cfe is named "cfe.new". you do not need to unlock the cfe 1st like in dd-wrt.

 

[jsmiddleton4]

Thanks barry. I'll make sure I've enabled ssh.

Will play during the day and see what I observe.

If its the case the firmware is determining the MAC's based off the CFE's LAN MAC, I can test it by setting the 2.4ghz in the "new" CFE to something completely different. If it shows up, then my speculation is incorrect.

Edit: SSH has been enabled but I use the FTP client in WinSCP. Filezilla as well.

Edit: ? Since we're talking the CFE I want to make certain I'm doing the right thing in the commands.

1. Don't I have to put the new cfe file location ?

So this:

mtd-write -i /tmp/cfe_new.bin -d pmon

2. And no need to put "cfe" at the end of the command line as in my previous example?

Edit: Going to wait until I install .262 and play. Right now I have Toastman's, Tomato build, loaded. I'm not sure the commands are the same and I don't want to mess up the CFE.

 

[barryware]

1. Don't I have to put the new cfe file location ?

So this:

mtd-write -i /tmp/cfe_new.bin -d pmon

2. And no need to put "cfe" at the end of the command line as in my previous example?

1). I used /tmp/home/root/ because that was where the extract routine put the cfe. You can use /tmp I would think.

2). Yes.. no need to put "cfe" and the end of the write command. dd-wrt calls the partition "cfe", stock asus and merlin call the partition "pmon".

Note: if you have updated the cfe and the vlans are correct (bug in 1st routine), you should leave it alone. The whole mac thing is a mystery to me.

meaning... et0 and pci/1/1/ (2.4ghz radio) do have the same macs specified in the cfe. But I don't know if this is by design by asus, or a mistake.

anytime you start messing with the inner bolus of the router, you run the risk of bricking it. Because this is the bootloader, if something goes wrong, jtag is the only option and we do not have jtag working on this router yet.

 

[glennsamuel32]

btw...inSSIDer shows the same mac as the Tomato gui...

 

[jsmiddleton4]

Thanks again Barry.

By the time Merlin's .262 is available maybe we'll know more about how the Asus stock/core firmware is dealing with MAC's. I'll not be messing with the CFE update until then.

As noted with Toastman's the default is to start with the LAN MAC, :60, as the base and then adds to it.

The laptops that are connected to 2.4 show the MAC listed in Toastman's.:62, as do the 5 ghz clients show its MAC, :63.

It is quite confusing. If it is the case that the MAC's are getting in the way of WDS/Ethernet bridging I'm curious and would like to both identify it and help fix it for those folks IF, IF, it is a problem.

 

[lfbb]

Hey guys, I found more MACs in my nvram. In this list are 30, some repeated:

- lfbb

 

[jsmiddleton4]

Ain't no way those are coming from the CFE.

 

[bird333]

1). I used /tmp/home/root/ because that was where the extract routine put the cfe. You can use /tmp I would think.

2). Yes.. no need to put "cfe" and the end of the write command. dd-wrt calls the partition "cfe", stock asus and merlin call the partition "pmon".

Note: if you have updated the cfe and the vlans are correct (bug in 1st routine), you should leave it alone. The whole mac thing is a mystery to me.

meaning... et0 and pci/1/1/ (2.4ghz radio) do have the same macs specified in the cfe. But I don't know if this is by design by asus, or a mistake.

anytime you start messing with the inner bolus of the router, you run the risk of bricking it. Because this is the bootloader, if something goes wrong, jtag is the only option and we do not have jtag working on this router yet.

Just to be clear, it should be safe to hex edit the mac if you are going to run ASUS firmware though right?

 

[lfbb]

Ain't no way those are coming from the CFE.

Run this from 'Tools' -> 'Run Cmd':

nvram show | grep :

wl1_hwaddr=50:46:5D:00:7D:34
wl0.14_hwaddr=52:46:5D:00:7D:3E
et0macaddr=50:46:5D:00:7D:30
wl1.12_hwaddr=52:46:5D:00:7D:30
wl0.1_hwaddr=52:46:5D:00:7D:31
wl1.1_hwaddr=52:46:5D:00:7D:35
wl0.7_hwaddr=52:46:5D:00:7D:37
wl1.7_hwaddr=52:46:5D:00:7D:3B
wl0.15_hwaddr=52:46:5D:00:7D:3F
wl1.13_hwaddr=52:46:5D:00:7D:31
wl0.2_hwaddr=52:46:5D:00:7D:32
wl1.2_hwaddr=52:46:5D:00:7D:36
pci/2/1/macaddr=50:46:5D:00:7D:34
wl0.8_hwaddr=52:46:5D:00:7D:38
wl1.8_hwaddr=52:46:5D:00:7D:3C
wl0.10_hwaddr=52:46:5D:00:7D:3A
lan_hwaddr=50:46:5D:00:7D:30
wl1.14_hwaddr=52:46:5D:00:7D:32
wl_hwaddr=50:46:5D:00:7D:34
wl0.3_hwaddr=52:46:5D:00:7D:33
wl1.3_hwaddr=52:46:5D:00:7D:37
wl0.9_hwaddr=52:46:5D:00:7D:39
wl1.9_hwaddr=52:46:5D:00:7D:3D
wan_hwaddr=50:46:5D:00:7D:30
wl0.11_hwaddr=52:46:5D:00:7D:3B
wl1.15_hwaddr=52:46:5D:00:7D:33
wl0.4_hwaddr=52:46:5D:00:7D:34
wl1.4_hwaddr=52:46:5D:00:7D:38
wl0.12_hwaddr=52:46:5D:00:7D:3C
wl1.10_hwaddr=52:46:5D:00:7D:3E
wl0.5_hwaddr=52:46:5D:00:7D:35
wl1.5_hwaddr=52:46:5D:00:7D:39
wan0_hwaddr=50:46:5D:00:7D:30
wl0_hwaddr=50:46:5D:00:7D:30
wl0.13_hwaddr=52:46:5D:00:7D:3D
wl1.11_hwaddr=52:46:5D:00:7D:3F
pci/1/1/macaddr=50:46:5D:00:7D:30
wl0.6_hwaddr=52:46:5D:00:7D:36
boardnum=50:46:5d:00:7d:30
wl1.6_hwaddr=52:46:5D:00:7D:3A

40 variables total.

The 50:46:5D is an Asus MAC.

The 52:46:5D I don't know where it come from!

- lfbb

 

[barryware]

@lfbb.. Those macs are created by the firmware and have to do with virtual interfaces (vlans, wds, etc.). I am not that familiar with Tomato so I don't know exactly how it works in that firmware. I do know that the list of cfe nvram variables is very short compared to what the firmware builds.

@bird333..

I would recommend against changing the macs from the factory scheme in the cfe because:

We will then have a mix of routers (the same model router) in the wild. Some will have a diff mac for pci/1/1/ and some will have the same mac as et0 because not all will change the cfe from stock scheme.

Some have reported that changing the mac in the cfe had no affect in the firmware. Some reported differently. Some report that the macs were fine without changing the cfe. (based on what firmware they were using)

There are many building firmware (kudos to all). dd-wrt (BS, Eko, Fractal, Kong, etc.), Tomato (Shibby, Toastman, Teddybear?, etc. (sorry, not that familiar with Tomato)), Merlin, etc. (sorry if I left some devs out of the list)

Point being.. If all the routers are not the same in regard to default cfe mac numbering scheme, a build that works on one router may not work on another.. See what I mean?

We saw that when Fractal built a firmware for the new patched 64k cfe.. He made some adjustments to get the lan ports working (vlans). Once the error in the cfe patch was discovered and corrected, that build no longer worked.

just my 2 cents..

 

[lfbb]

@lfbb.. Those macs are created by the firmware and have to do with virtual interfaces (vlans, wds, etc.). I am not that familiar with Tomato so I don't know exactly how it works in that firmware. I do know that the list of cfe nvram variables is very short compared to what the firmware builds.

I'm not running Tomato (Merlin 3.0.0.4.260.21) but ok, thanks for the answer.

- lfbb

 

[barryware]

I'm not running Tomato (Merlin 3.0.0.4.260.21) but ok, thanks for the answer.

- lfbb

I'm not too familiar with much other than dd-wrt.

 

[jsmiddleton4]

"Those macs are created by the firmware"

That's what I was saying, those are not coming from the CFE.

It continues to appear, appear mind you, that the CFE hands off the starting point MAC to the firmware. The firmware creates/assigns, whatever the right word is, the rest of the MAC's.

I am of the opinion that the MAC LAN and 2.4ghz having the same MAC address is the Asus stock firmware, not the CFE. Which is why, for those folks who changed the 2.4ghz MAC in the CFE, some did not see any change in the 2.4ghz MAC.

The question boils down to is this an issue or not? If in setting up multiple router systems in which slaves talk to one router as a master via wireless channels AND Asus is not following industry standards for assigning MAC's to its wireless channels, it could indeed create a problem.

Not a difficult one to fix mind you given the ability to assign MAC addresses in the firmware. One can always assign a MAC that will let the 2.4ghz channels talk to each other correctly and without confusion.

I would just like to know whose who in the zoo here. How are MAC's supposed to be assigned and what is Asus doing in comparison to the standard?

I only have 2 other dual band routers to observe. For those the MAC's are different BUT they are running Tomato variants are aren't Asus based. They are Linksys/Cisco based.

So if we are talking how things work "out there" in the real world then we do need to make sure an Asus dual band router is able to talk to other non-Asus router. That is the point of standards yes?

Otherwise the only routers the N66U can easily and reliable talk to are only other Asus N66U routers.

And if so, that ain't so good.....

Is this a big deal?

No, probably not.

Could it potentially be a big deal even though a small matter?

Yes, it could be.

 

[bird333]

The question boils down to is this an issue or not? If in setting up multiple router systems in which slaves talk to one router as a master via wireless channels AND Asus is not following industry standards for assigning MAC's to its wireless channels, it could indeed create a problem.

Not a difficult one to fix mind you given the ability to assign MAC addresses in the firmware. One can always assign a MAC that will let the 2.4ghz channels talk to each other correctly and without confusion.

I would just like to know whose who in the zoo here. How are MAC's supposed to be assigned and what is Asus doing in comparison to the standard?

I only have 2 other dual band routers to observe. For those the MAC's are different BUT they are running Tomato variants are aren't Asus based. They are Linksys/Cisco based.

So if we are talking how things work "out there" in the real world then we do need to make sure an Asus dual band router is able to talk to other non-Asus router. That is the point of standards yes?

Otherwise the only routers the N66U can easily and reliable talk to are only other Asus N66U routers.

And if so, that ain't so good.....

Is this a big deal?

No, probably not.

Could it potentially be a big deal even though a small matter?

Yes, it could be.

I don't know but I just think each interface ought to have an unique mac. It gives maximum flexibility which is why we use 3rd party firmware to begin with. I guess if the firmware can create the unique macs then it probably isn't a big deal. But imho all firmware (including ASUS) should do that.

 

[fritsp1989]

Already on 64k

Okay i flashed my CFE to 64k already do i need to reapply the patch now ?
And if i do need to reapply the patch which procedure should i follow,
what is it exactly that i am fixing if i update the CFE again ?

 

[jsmiddleton4]

reapply a patch for what frit.....?

 

[fritsp1989]

reapply a patch for what frit.....?

The CFE of i did it before while running linux, now i see everybody talking about another bug fix that is suposed to do someting with the routers mac adress.
I am already running the 64k CFE from the beginning, so i was wondering was there something wrong with the first 32k<>64k patch.

 

[barryware]

The CFE of i did it before while running linux, now i see everybody talking about another bug fix that is suposed to do someting with the routers mac adress.
I am already running the 64k CFE from the beginning, so i was wondering was there something wrong with the first 32k<>64k patch.

The 1st patch routine did not handle a variable with a space in the data.

So.. vlan1ports=1 2 3 4 8* turned into vlan1ports=1 in the patched cfe.

as long as you have running firmware there is no problem. However, if you ever need recovery mode, your lan ports will not work.

in regard to the mac address(s).. it seems it is still being debated if the numbering scheme is by design, or a bug.