It looks like the r8000 firmware is in the r7000p folder.
You should not have flashed it if you noticed that.
Can you flash back to Netgear firmware?
For future reference, if a Kong firmware is available for your unit, it’s best to stick with it.
You picture link won’t open. _________________ I am far from a guru, I'm barely a novice.
It looks like the r8000 firmware is in the r7000p folder.
You should not have flashed it if you noticed that.
Can you flash back to Netgear firmware?
For future reference, if a Kong firmware is available for your unit, it’s best to stick with it.
You picture link won’t open.
Well I thought about it before and like always sometimes firmware shares different models I did not even once think it was wrong one, if it is that?
Can we get a confirmation on the r8000 is not supposed to be in the r7000p folder ?
Because older version also has r8000 in it like this
I just tried flasahing back to original firmware and kongs firmware, after pressing upgrade it does the circel load animaion but only a period of like 5-8 seconds then it reboots.
How else can i get back to stock and get back on kongs?
I don’t know if that’s the case. You’d have to ask other r7000p users if they freely use those builds.
All I know is that the r7000p and r8000 have different Wi-Fi chips and if the used the same firmware, why would Kong’s have different nes for each?
http://www.desipro.de/ddwrt/K3-AC-Arm/
Either way, no skin off my back. Carry on as you prefer. _________________ I am far from a guru, I'm barely a novice.
I don’t know if that’s the case. You’d have to ask other r7000p users if they freely use those builds.
All I know is that the r7000p and r8000 have different Wi-Fi chips and if the used the same firmware, why would Kong’s have different nes for each?
http://www.desipro.de/ddwrt/K3-AC-Arm/
Either way, no skin off my back. Carry on as you prefer.
Thanks for the tip with another browser, im on kongs build again THANKS!, but now we should really figure out whats going on with the r8000 builds in those folders, some way we can ping brainslayer?
For fun I wanted to test kongs latest test build and suprising that one also said r6400 v1
I'm also showing Netgear R6400 v1 for my R7000p. However, this started today after automatic updates picked up the latest release in the stable directory.
My router had originally showed as R7000p with the 5/18 stable release, and my AC antenna used to work.
I just manually flashed the R7000p bin from Kong's stable directory, and it still shows as Netgear R6400 v1. And my AC antenna still doesn't work.
Any suggestions?
Last edited by bdub76 on Wed Nov 14, 2018 12:34; edited 1 time in total
I'm also showing Netgear R6400 v1 for my R7000p. However, this started to today after automatic updates picked up the latest release in the stable directory.
My router had originally showed as R7000p with the 5/18 stable release, and my AC antenna used to work.
I just manually flashed the R7000p bin from Kong's stable directory, and it still shows as Netgear R6400 v1. And my AC antenna still doesn't work.
Any suggestions?
Flashed back to original netgear firmware and back to kongs 31/5
However I have both the r7000p and r7000, I think im going to ditch the r7000p for now, the antennas and the lan speed is way slower than my r7000 for some odd reason.
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Wed Nov 14, 2018 9:06 Post subject:
The beginning of septembre there was a change in identification codes (board_id) of the Netgear routers. Netgear released a R6400v2 but identical R6400v2 had different board_id's ( nvram show | grep board).
Netgear really made a mess of that.
It is possible then that either a bug has been introduced or that board_id's of recent R7000P have been changed by Netgear.
I do not have one so I can check, but you can always send one to me for further investigation (just kidding)
If there are any experts I think the code can be found at source/router/rc/mtd.c and source/router/libutils/libutils/detect.c
R7000P board_id should be: U12H270T20_NETGEAR
Edit: just took a peek at the source code, cannot find anything wrong with it (but I have very limited coding skills)
It checks the boardnum ==32, boardtype ==0x0646 and boardrev == 0x1601, then checks the board_id and if that is U12H270T20 then it should be recognised as a R7000P.
If it is not recognised then it defaults to R6400v1!
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Wed Nov 14, 2018 9:49 Post subject:
@egc,
Those two files and locations in the files below, yes. As I was saying, further id info may be necessary, and/or a change to the detection code. I don't think anything Kong changed was reverted or further changed in the detection code.
I guess if I felt like spending ~$170US and adding a *Netgear* device to the family.
@OP,
If it's a Kong-supported device, always, always, ALWAYS stick with Kong builds. You may have to revert to OEM firmware and/or do an 'nvram erase' via telnet / ssh to fix the issue, because if you don't clear the nvram variables via soft reset in the GUI or otherwise, the bad values stay. This is why it is NOT recommended to use nvram backups to restore settings....
Last edited by kernel-panic69 on Wed Nov 14, 2018 10:10; edited 1 time in total