NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
NVRAM bug - FOUND IT!!
I have posted for some time about various issues with corrupt config parameters (NVRAM). If nothing else, I am a really stubborn geek with 50+ years of experience and I don't like unexplained failur...
Congratulations. My Orbi matches your exactly used plus free = 233,472. Looks like a classic case of using an 'int' where it should be a 'long int'.
Is this a V1 or V2 Orbi?
How many devices are represented in the Orbi tables (LAN reservation, previous but not connected, etc.?)
Tested on V1.
54 active connected devices and 56 items in the previous but not connected per WebUI.. Looks like there are 198 items in the NVRAM "access_control" table.
Scott
CrimpOn wrote:Congratulations. My Orbi matches your exactly used plus free = 233,472. Looks like a classic case of using an 'int' where it should be a 'long int'.
Is this a V1 or V2 Orbi?
How many devices are represented in the Orbi tables (LAN reservation, previous but not connected, etc.?)
SLK-Purdue wrote:
54 active connected devices and 56 items in the previous but not connected per WebUI.. Looks like there are 198 items in the NVRAM "access_control" table.
My access_control list has 77 items in it. Looking at the Access Control web page
37 Active devices
36 Allowed but not connected
1 Blocked but not connected
----
74 Total. I think the missing 3 are three entries for ETH0. 74+3 = 77.
I would expect you to have 54+56+3 = 113, not 198.
I do not have Access Control enabled, so there is no particular difficulty in deleting "allowed but not connected' devices because they will simply authenticate the next time they show up. But, where did those extra 85 entries in your system come from?
My bad - access_control table has 105 entries. Counting error. I think that matches current totals as you did.
Thanks,
Scott
CrimpOn wrote:
SLK-Purdue wrote:54 active connected devices and 56 items in the previous but not connected per WebUI.. Looks like there are 198 items in the NVRAM "access_control" table.
My access_control list has 77 items in it. Looking at the Access Control web page
37 Active devices
36 Allowed but not connected
1 Blocked but not connected
----
74 Total. I think the missing 3 are three entries for ETH0. 74+3 = 77.
I would expect you to have 54+56+3 = 113, not 198.
I do not have Access Control enabled, so there is no particular difficulty in deleting "allowed but not connected' devices because they will simply authenticate the next time they show up. But, where did those extra 85 entries in your system come from?
My ARM assembly language skills aren't as good as some other hardware architectures but, based on a disassembly of NVRAM, it sure looks like that code has a hard coded size constant of 0x10000. That would explain the bug. No clue on the actually allocated size of NVRAM in the EEPROM but I am guessing the buffer size is the real issue. Would likely be an easy fix if NVRAM source code were part of the NG "open source" but, sadly, it isn't.
NG - why keep this a secret? There is nothing in using EEPROM for NVRAM that is your secret intellectual property. Everybody does that. I understand not wanting to release the secret sauce behind for mesh algorithm but that not in reading and writing NVRAM.
AGAIN - this is a VERY serious problem for all users. Send me the source code and I will fix this FOR FREE and send you back code and give you all rights. You're getting a consultant with 50+ years of systems experience that bills at $500/hr when I work for money.
Scott