CFE bootloader update

[jsmiddleton4]

Yes and its the same as the LAN MAC.

 

[RogerSC]

Yes and its the same as the LAN MAC.

Yep, same results that you get from running "ifconfig | grep HWaddr" via telnet *smile*.

 

[Taurean75]

Taurean75, I had the same problem. Upgraded CFE, used restoration utility to upgrade to tomato-K26USB-NVRAM64K-1.28.0500.5MIPSR2Toastman-RT-N-Ext, unable to communicate with router. Restoration utility back to Merlins, all OK. Held reset, turned, continued holding reset for ~30 seconds. Left it sit a few minutes then powered off. Did same routine with wireless button (not sure which does full reset). Once again used restore to install tomato-K26USB-NVRAM64K-1.28.0500.5MIPSR2Toastman-RT-N-Ext, able to connect. According to the manual, holding reset for more than 5 seconds (router already on) is full reset, try this as well.

I tried to flash Shibby 102 just now, but strangely, the reset button doesn't work with it. It flashes ok, but its GUI doesn't respond.

Oh, well.

 

[jsmiddleton4]

Loaded the Asus Beta firmware. Its display for MAC's shows the LAN and the 5GHZ channel.

Edit: BSSID in Wireless properties in System reports the 2.4ghz has same MAC as the LAN.

Again I do not know if that is a problem, I am not saying it is a bug. I have no idea what it means.

Would like to know and hopefully someone can offer some insight.

 

[mstombs]

MAC addresses must be unique on a network segment, and historically manufacturers of wired Ethernet NICs have followed the IEEE standards correctly - originally MACs were burnt into PROMS and you'd need to change a chip to change! More liberty is common on virtual interfaces including Ethernet over USB, ATM (DSL) as well as Wifi.

I don't see an issue with above since a client should never be connected to same router by multiple Wifi 2.4/5GHz connections - there's even a potential advantage at next level up in the Network Protocol stack - each machine needing to make unique assignment of IP address to MAC address (ARP protocol). One MAC can have many IP addresses, but not the other way round - and your router local IP address usually doesn't change depending on which interface you access.

 

[jsmiddleton4]

Thanks ms....

Just because something is different doesn't mean there is a problem, its wrong, etc. I'm fairly certain there isn't anything about the same MAC's for LAN and 2.4ghz that is problematic. It is different however.

My WDS scenario was about the only one I could come up with in which the N66 2.4ghz MAC might be used.

I have a question about this however.

"a client should never be connected to same router by multiple Wifi 2.4/5GHz connections "

Isn't there talk about channel bonding for clients in the same way we now have channel bonding for cable modems? And if so wouldn't that be a client connecting to the same router via multiple wifi connections?

 

[mstombs]

I don't know about WDS or other variants of Wireless Ethernet bridge - but I think the connection is all within the driver-to-driver connection so clients don't really see the link?

Wireless N and its 40MHz mode is bonding adjacent channels, but again its inside the driver. I've never come across mixed 2.4 and 5GHz, but can see the attraction - mobile phones and 4G etc will use different frequencies for up/download.

 

[Lost_Animal]

Finally i think that Common MAC Addresses for Devices is a BIG problem.
I'm getting strange disconnections from my WAN - loosing DNS etc.

My Router log if full of those messages,,,,,

Jan 1 02:00:38 Samba Server: daemon is started
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address
Jan 1 02:00:38 kernel: vlan1: received packet with own address as source address

Jan 1 02:00:48 kernel: printk: 32 messages suppressed.
Jan 1 02:00:48 kernel: vlan1: received packet with own address as source address

Jan 1 02:09:09 kernel: vlan1: received packet with own address as source address
Jan 1 02:09:10 kernel: vlan1: received packet with own address as source address
Jan 1 02:09:11 kernel: vlan1: received packet with own address as source address
Jan 1 02:09:13 kernel: vlan1: received packet with own address as source address
Jan 1 02:10:23 kernel: vlan1: received packet with own address as source address
Jan 1 02:10:23 kernel: vlan1: received packet with own address as source address
Jan 1 02:10:56 kernel: vlan1: received packet with own address as source address
Jan 1 02:10:58 kernel: vlan1: received packet with own address as source address
Jan 1 02:14:08 kernel: vlan1: received packet with own address as source address
Jan 1 02:14:18 kernel: vlan1: received packet with own address as source address
Jan 1 02:15:27 kernel: vlan1: received packet with own address as source address
Jan 1 02:15:27 kernel: vlan1: received packet with own address as source address
Jan 1 02:21:19 kernel: vlan1: received packet with own address as source address
Jan 1 02:21:19 kernel: vlan1: received packet with own address as source address
Jan 1 02:28:34 kernel: vlan1: received packet with own address as source address
Jan 1 02:28:34 kernel: vlan1: received packet with own address as source address
Jan 1 02:36:26 kernel: vlan1: received packet with own address as source address
Jan 1 02:36:26 kernel: vlan1: received packet with own address as source address
Jan 1 02:45:45 kernel: vlan1: received packet with own address as source address
Jan 1 02:45:45 kernel: vlan1: received packet with own address as source address
Jan 1 02:55:49 kernel: vlan1: received packet with own address as source address
Jan 1 02:55:49 kernel: vlan1: received packet with own address as source address
Jan 1 03:06:43 kernel: vlan1: received packet with own address as source address
Jan 1 03:06:43 kernel: vlan1: received packet with own address as source address
Jan 1 03:18:53 kernel: vlan1: received packet with own address as source address
Jan 1 03:18:53 kernel: vlan1: received packet with own address as source address
Jan 1 03:31:01 kernel: vlan1: received packet with own address as source address
Jan 1 03:31:01 kernel: vlan1: received packet with own address as source address
Jan 1 03:43:07 kernel: vlan1: received packet with own address as source address
Jan 1 03:43:07 kernel: vlan1: received packet with own address as source address
Jan 1 03:55:14 kernel: vlan1: received packet with own address as source address
Jan 1 03:55:14 kernel: vlan1: received packet with own address as source address

I think route from WAN to LAN devices is NOT working well due to common MAC addresses, and creating huge amount of packet loop.

As you see br0 - eth0 - eth1 - vlan1 - wds1 - wds2 - wds3 sharing the same HWaddr(MAC) and this creating routing problems from WAN side.

I don't know if this problem came up with the CFE Upgrade or is FW BUG but is there and is bad.

PS... I'm running Merlin's latest .260 FW.

 

[jsmiddleton4]

Good morning Lost....

Bummer.

I'm not expert enough to say for certain what you are seeing is due to the two same MAC addresses or not. But your setup is the scenario I imagined the shared MAC's could cause an issue.

I wonder if a new thread dedicated to the subject might be a good idea?

Also I'm thinking the MAC addresses are in the cfe and we'd have to update it. But we'd have to enter the MAC manually? Not sure IF this is an issue how we'd even fix it.

 

[lfbb]

In my router there are 9 variables in nvram that contain MAC addresses:

- lfbb

 

[William]

I’ve been using multiple routers for wds to cover my property for years. I always use dd-wrt. I purchased 2 rt-n66u’s to replace my linksys routers. I have used the rt-n66u with 32k dd-wrt, 64k ddwrt,32k merlins,64k merlins and several stock. I have followed this page since it began and thanx to everyone for a fun time. Let me contribute my 2 cents. I have noticed from the beginning that asus stock and merlins all have the lan/ 2.4ghz mac that is the same. I always thought that was strange. But install fractal’s build or any other dd-wrt firmware and the lan, 2.4ghz and the 5ghz all have separate mac’s. The mac’s increase by 2’s. Don’t know the importance, I am just a good listener.

 

[jsmiddleton4]

So it could be a gui issue as in the GUI is reading the wrong variable when there are individual hard coded MAC's?

If so we'd still need, for things like WDS, to make sure the router's can "see" the other's correct MAC for the 2.4 ghz channel.

 

[Lost_Animal]

Finally i end up with TOMATO Shibby's FW.
All Running Smooth now and with great Performance.
No more DNS - DHCP problems and i Have 4 Unique MAC's for each Device.



Something with ASUS FW is BUGGY and make all connections Unstable.

Installed Optware and many nasty apps inside my microSD card and NAS Performace is better than ASUS by 2MB/s.



Tomato FW is a Keeper for me until ASUS make some Better FW.

All the porblems i had was related with FW and NOT with CFE bootloader update.

 

[jsmiddleton4]

As far as I know that is the way it should be. Separate MAC's for each main port, whatever you want to call each.

The MAC must be there however. The firmware doesn't assign mac's to devices does it? It just reads what's there.

Edit: I can't tell for sure both are different, LAN and 2.4ghz MAC. The only thing I can see is the last 2 digits and those are the same, A0.

Edit: Loaded Shibby's over lunch. Same MAC for 2.4ghz and LAN port. So its no different than the ASUS or Merlin's in that regard.

 

[Pierino]

Everything is working fine for me since the last fix from ryzhov and co.
I'm on Merlin's 260.21.

 

[barryware]

when I was working with the cfe and helping with the port many months ago I noticed that two stated macs in the cfe are the same.

the cfe has the mac(s) stated in 3 places.. The offsets are the original 1.0.1.2 cfe. If you update the cfe to 1.0.1.3, the offsets change a bit.

et0macaddr=C8:60:00:00:00:00 @ offset 0x4C1 (this is the mac from the sticker of your router)

pci/1/1/macaddr=C8:60:00:00:00:00 @ offset 0x64D (this mac is the same as et0macaddr)

pci/2/1/macaddr=C8:60:00:00:00:04 @ offset 0xB3C (this is et0macaddr + 4)

In the origional cfe, notice that et0 and pci/1/1 are the same?

you can change the mac via telnet and if it works like you quys want it to, then upgrade / update the cfe again changing the mac in the cfe.

nvram set pci/1/1/macaddr="xx:xx:xx:xx:xx:xx" (xx:~ = et0 + 1)

nvram commit

reboot

The mac thing may be by design, or an Asus mistake (they did ship the router with 32k nvram to begin with.. big mistake)

 

[bird333]

when I was working with the cfe and helping with the port many months ago I noticed that two stated macs in the cfe are the same.

the cfe has the mac(s) stated in 3 places.. The offsets are the original 1.0.1.2 cfe. If you update the cfe to 1.0.1.3, the offsets change a bit.

et0macaddr=C8:60:00:00:00:00 @ offset 0x4C1 (this is the mac from the sticker of your router)

pci/1/1/macaddr=C8:60:00:00:00:00 @ offset 0x64D (this mac is the same as et0macaddr)

pci/2/1/macaddr=C8:60:00:00:00:04 @ offset 0xB3C (this is et0macaddr + 4)

In the origional cfe, notice that et0 and pci/1/1 are the same?

you can change the mac via telnet and if it works like you quys want it to, then upgrade / update the cfe again changing the mac in the cfe.

nvram set pci/1/1/macaddr="xx:xx:xx:xx:xx:xx" (xx:~ = et0 + 1)

nvram commit

reboot

The mac thing may be by design, or an Asus mistake (they did ship the router with 32k nvram to begin with.. big mistake)

I'm no expert but as far as I know every interface should have a unique mac. is et0+1 better than et0+2 or does it matter? How does dd-wrt assign macs for VAP's?

 

[jsmiddleton4]

barry....

Thanks and very helpful.

So change the MAC and then when we run the CFE updater script it reads the existing information, which will have the updated MAC address and write the new CFE with the new MAC?


From then on, MAC's all different?

If we've already done the update can we update it again?

 

[barryware]

barry....

Thanks and very helpful.

So change the MAC and then when we run the CFE updater script it reads the existing information, which will have the updated MAC address and write the new CFE with the new MAC?


From then on, MAC's all different?

If we've already done the update can we update it again?

Well.. That isn't what I meant..

Change the mac via nvram set & commit.. Then reboot the router and make sure your macs are the way they are supposed to be (or the way you want). This is for testing without making anything permanent.

If it all works out.. Then update the cfe again but... you need to edit your original cfe (1.0.1.2), run the patch (#2). It will insert your nvram data which includes your new mac into the 1.0.1.3 cfe. The flash the new cfe.

The latest patch (#3), I have not used. I think #3 is automatic and you don't have the opportunity to edit (not sure.. didn't use it)

 

[jsmiddleton4]

"That isn't what I meant.."

That's why I asked. I get some of this stuff but clearly not all of it.

I did the latest automatic d/l files to the router via telnet commands cfe update process.

I think with it I'd have to restore my cfe.old and then start from scratch.

I looked at my Linksys E3000, it has unique MACS for all 3, LAN, 2.4 and 5ghz.

With Shibby's, Tomato, not sure about Merlin's, you can set the MAC and over ride it.