Starting to wonder if the 32 KB nvram isn't actually more a bug than a stupid design decision...
Code:
nvram_linux.c:#define CFE_NVRAM_SPACE 64*1024
A #define doesn't create any code by itself.
The CFE is built for 32KByte nvram.
Well, duh. My point is, if they are using a 64KB define in part of the code, then I'm betting that their intention WAS to use 64 KB, but unintentionally they made the CFE only allocate 32 KB. That's what I'm saying - it's a bug, not a concious (poor) design decision on their part.
Can you give me more information on your OpenVPN usage and your network setup?
I am in discussion with our development team about NVRAM and I was informed that the NVRAM is 64KB. The utility is not showing the correct amount. I am trying to get clearer information from our team so please stand by. Whether you want to wait for a response, or return the unit is up to you.
It's not just an issue with the nvram tool. The kernel driver also only sees 32 KB:
Code:
reating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "pmon"
0x00040000-0x01fe0000 : "linux"
0x0013b400-0x01340000 : "rootfs"
0x01340000-0x01fe0000 : "jffs2"
0x01fe0000-0x02000000 : "nvram"
Found an serial flash with 0 0KB blocks; total size 0MB
sflash: found no supported devices
_nvram_init: allocat header: 2280914944, size= 32768
No, the Asus development team is full of sh.t if they think they have 64KB nvram and I find it quite remarkable that a group of router enthusiasts has to tell them what specs their router has.
I have made a disassembly of the cfe and it is quite clear from the code that the cfe is made for 32KB nvram, there is no possibility at all that it should be 64KB.
The cfe allocates 32KB of nvram down from the top of flash and with a flash block size of 128KB it means that 96KB is unused followed by 32KB nvram and then we are in the end of flash. _________________ Kernel panic: Aiee, killing interrupt handler!
Haven't heard from Asus today. They asked me to clarify what I meant by no DNS, DHCP or VPN settings enabled. I then follow up that reply with a copy from dmesg showing what the kernel sees. I hadn't thought to include that until after RMerlin's last post. I'll let you all know what I hear from them when they reply.
This is what I received from my contact:
Shoot me the s/n of the router, some basic contact info.
I'm going to create a case and make this an official inquiry.
So, it will either end up going the same route that yours did Andy, or it will fizzle out depending on who gets it.
This is what I received from my contact:
Shoot me the s/n of the router, some basic contact info.
I'm going to create a case and make this an official inquiry.
So, it will either end up going the same route that yours did Andy, or it will fizzle out depending on who gets it.
Looks like people even having problems with minidlna on stock asus firmware.. I think asus is getting a black eye with this one.
Received a response at the end of the day yesterday. Adam is aware of what the kernel sees and has passed that onto the dev team. Looks like this thread has visibility with Asus now as well...
Quote:
On Fri, Apr 27, 2012 at 7:34 PM, <Adam_Kwong> wrote:
Hi Mr. Stafford,
Thank you for the clarification what I previously asked.
I am aware of the output as seen from dmesg. I have been monitoring this forum as well. I do not have information from our development team yet, but I should have a response early next week. Communication between headquarters and my location takes time due to time zone differences. I appreciate your patience. Have a good weekend!
Best Regards,
Adam K.
Customer Care Specialist J
ASUS Computers International
Just for clarification I loaded stock latest asus firmware on the N66U to see what happened.
Right out of the box, NTP broken, free nvram less than 1k.. So lets say you use the router and have NTP enabled, when the nvram write takes place at its sync interval it will set the time back to Jan 1, xxxx
here is serial output confirming this as well:
Code:
Jan 1 02:00:06 syslogd started: BusyBox v1.17.4
Jan 1 02:00:06 syslog: module ledtrig-usbdev not found in modules.dep
Jan 1 02:00:06 syslog: module leds-usb not found in modules.dep
Jan 1 02:00:06 kernel: klogd started: BusyBox v1.17.4 (2012-03-08 19:28:37 CST)
Jan 1 02:00:06 kernel: Linux version 2.6.22.19 (root@asus) (gcc version 4.2.4) #1 Thu Mar 8 19:38:57 CST 2012
It took less then 20 minutes to reproduce nvram failure with stock firmware... Here is what happens:
1. Router status notifications on the front seem fine.
2. No WAN access
3. No LAN access
4. Error's in serial console with unable to write to 0xxxx data block nvram not enough free space
5. no nvram-copy partition
6. Router will set itself back to factory defaults everytime... this is a full reset, SSID/channel, time ect. And you have to go through the setup wizard via web interface to get back onlne.
It seems to me dd-wrt lasts longer then asus original firmware and does not have NTP issue as far as I can see.
This is what I received from my contact:
Shoot me the s/n of the router, some basic contact info.
I'm going to create a case and make this an official inquiry.
So, it will either end up going the same route that yours did Andy, or it will fizzle out depending on who gets it.
Looks like people even having problems with minidlna on stock asus firmware.. I think asus is getting a black eye with this one.
I have made a disassembly of the cfe and it is quite clear from the code that the cfe is made for 32KB nvram, there is no possibility at all that it should be 64KB.
The cfe allocates 32KB of nvram down from the top of flash and with a flash block size of 128KB it means that 96KB is unused followed by 32KB nvram and then we are in the end of flash.
maybe a noob question but couldnt the cfe reallocated, reset or something else by fw-update to use more then the 32KB of the 128KB?