I found when I bricked my R6300 using Telnet, I loaded the original Netgear firmware and then did another 30/30/30 reset. From the Netgear firmware, I was then able to load the DD-WRT firmware.
@PaulGo, I think this may be an important distinction between us. Can you please clarify.
From what I understand, the only way you were able to load DDWRT successfully was to load stock Netgear FW first, then load DDWRT on top? Did you use .bin or .chk?
I tried loading DDWRT on top of older DDWRT builds (using physical button to induce reset after).
@the-joker, I think you are right. Not a size issue. But seems like some sort of library or driver issue. You mentioned changes to network config recently. Do you know what build that happened in?
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu May 26, 2022 18:09 Post subject:
Duxa wrote:
From what I understand, the only way you were able to load DDWRT successfully was to load stock Netgear FW first, then load DDWRT on top? Did you use .bin or .chk?
I can answer that, stock to dd-wrt its the .chk file ONLY, also for recovery purposes you can use same file, e.g flashing via TFTP, hence why I already recommended this to you.
The bin file is ONLY for flashing via CLI or web upgrade, in your case. IDK why Brainslayer doesn't have a consistent naming conventions for webupgrades/webflashes, but doesn't matter, that's the way it is.
Duxa wrote:
@the-joker, I think you are right. Not a size issue. But seems like some sort of library or driver issue. You mentioned changes to network config recently. Do you know what build that happened in?
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Thu May 26, 2022 18:20 Post subject:
Duxa wrote:
@PaulGo, I think this may be an important distinction between us. Can you please clarify.
From what I understand, the only way you were able to load DDWRT successfully was to load stock Netgear FW first, then load DDWRT on top? Did you use .bin or .chk?
I tried loading DDWRT on top of older DDWRT builds (using physical button to induce reset after).
@the-joker, I think you are right. Not a size issue. But seems
I have always used the .chk version of the firmware.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu May 26, 2022 19:59 Post subject:
PaulGo wrote:
I have always used the .chk version of the firmware.
According to wiki and experience, the .chk file used from stock to dd-wrt can only be used for upgrading, if done via TFTP/Recovery and not for web-upgrades. I will confirm this just to make double sure.
well either way it seems like this should not be happening:
Code:
get_wl_instance doesnt return the right value 0
wl: wl driver adapter not found
Write wireless mac fail : : No such device
wl: wl driver adapter not found
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Fri May 27, 2022 6:59 Post subject:
Duxa wrote:
well either way it seems like this should not be happening:
Code:
get_wl_instance doesnt return the right value 0
wl: wl driver adapter not found
Write wireless mac fail : : No such device
wl: wl driver adapter not found
Have you tried TFTP'ing the .chk file?
Regarding your output, Im assuming this doesnt happen with a build that works right? I think you should attach a serial log from a good build so it can be compared to a bad build.
But, regardless of that output, does it all work or not with latest build?
When I spoke to Brainslayer about this, he said that you may have wiped the nvram completely as opposed of just doing a regular reset. Personally I have no idea what you initially did, or if something went wrong that caused the weirdness.
What I can suggest is that you dump all your partitions and boot code, then if PaulGo can and is willing to do the same you can then compare the results, and assuming these are identical machines, you can try write PaulGo's data into your machine. (would need board pictures from both machines (silkscreened text to determine compatibility as without it, it wont be good to flash non compatible anything or write any partitions contents)
This isnt for the faint hearted, but since you would in that case have your original dumps it's always possible to revert to that.
well either way it seems like this should not be happening:
Code:
get_wl_instance doesnt return the right value 0
wl: wl driver adapter not found
Write wireless mac fail : : No such device
wl: wl driver adapter not found
Have you tried TFTP'ing the .chk file?
Regarding your output, Im assuming this doesnt happen with a build that works right? I think you should attach a serial log from a good build so it can be compared to a bad build.
But, regardless of that output, does it all work or not with latest build?
When I spoke to Brainslayer about this, he said that you may have wiped the nvram completely as opposed of just doing a regular reset. Personally I have no idea what you initially did, or if something went wrong that caused the weirdness.
What I can suggest is that you dump all your partitions and boot code, then if PaulGo can and is willing to do the same you can then compare the results, and assuming these are identical machines, you can try write PaulGo's data into your machine. (would need board pictures from both machines (silkscreened text to determine compatibility as without it, it wont be good to flash non compatible anything or write any partitions contents)
This isnt for the faint hearted, but since you would in that case have your original dumps it's always possible to revert to that.
That scenario is a last ditch effort, I have no idea of what else to suggest. It's not possible that PaulGo can get the last build and a fully working machine and you cant, makes no sense, it's illogical except in the case where there is some damage to some partition or some hardware failure (including power brick).
I guess what I want to know is final confirmation that code was looked at and its not a bug in the code. Id like to know the function which throws this get_wl_instance error (under what conditions).
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat May 28, 2022 8:08 Post subject:
Duxa wrote:
I guess what I want to know is final confirmation that code was looked at and its not a bug in the code. Id like to know the function which throws this get_wl_instance error (under what conditions).
I've asked you for serial logs for the good/bad builds for comparison, Ive asked you to try TFTP'ing the latest build asif you are recovering the router.
You want to assume its the code, or the firmware size or something else external, these assumptions are incorrect and have been proven and discounted.
Fact: Other people with same router can and have flashed the latest builds and have working machines.
Fact: Firmware size is a non starter since your machine has 30MB available for the flash, and current firmwares take 4 extra blocks when comparing to firmwares from March, with current builds you will have 35 block free (exactly) after flashing.
If you want some sort of confirmation outside of this, I haven't looked at the code, I cant say with any certainty that Brainslayer has, but I doubt personally since hes is really busy with associated components for dd-wrt to waste time he doesn't have on this because the 2 facts above already strong indicators that its not the code.
I guess what I want to know is final confirmation that code was looked at and its not a bug in the code. Id like to know the function which throws this get_wl_instance error (under what conditions).
I've asked you for serial logs for the good/bad builds for comparison, Ive asked you to try TFTP'ing the latest build asif you are recovering the router.
You want to assume its the code, or the firmware size or something else external, these assumptions are incorrect and have been proven and discounted.
Fact: Other people with same router can and have flashed the latest builds and have working machines.
Fact: Firmware size is a non starter since your machine has 30MB available for the flash, and current firmwares take 4 extra blocks when comparing to firmwares from March, with current builds you will have 35 block free (exactly) after flashing.
If you want some sort of confirmation outside of this, I haven't looked at the code, I cant say with any certainty that Brainslayer has, but I doubt personally since hes is really busy with associated components for dd-wrt to waste time he doesn't have on this because the 2 facts above already strong indicators that its not the code.
Hes so busy that it takes him a whole 24 hours to merge my patches as previously it was around 5 minutes or less.
Well Id argue with your assumptions. Its 100% the code. Question is, can build sometimes function or not. PaulGo said numerous times he had issues with the builds and had to do various resets to finally get it to work. We dont know if he has same errors on serial or not.
Why do I say its 100% the code? Because I would consider it a bug if my kernel cant load on top of a previous build and requires tftp flash.
I already know that I can load build previous to march on top of each other. So something is 100% wrong with the code with builds that cant. Unless you are saying that updating builds from within the GUI is all of a sudden not supported functionality anymore.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sun May 29, 2022 8:52 Post subject:
Duxa wrote:
Well Id argue with your assumptions. Its 100% the code. Question is, can build sometimes function or not. PaulGo said numerous times he had issues with the builds and had to do various resets to finally get it to work. We dont know if he has same errors on serial or not.
Why do I say its 100% the code? Because I would consider it a bug if my kernel cant load on top of a previous build and requires tftp flash.
I already know that I can load build previous to march on top of each other. So something is 100% wrong with the code with builds that cant. Unless you are saying that updating builds from within the GUI is all of a sudden not supported functionality anymore.
To clarify, PaulGo's issues ARE NOT related to any of your issues, again its a FACT, you can disagree with me, but for the sake of civility, lets not go down the disagreement path any longer, it's pointless and not constructive.
He can run/install/upgrade to latest builds, his issues are related to something being explored atm on another thread.
Again Ive asked you for serial logs of both instances to show any indications of what could be wrong for comparison. Ive asked you to try TFTP he latest build and grab serial logs of both good and bad results.
Choose your path, argue the finer points of disagreement or try to cooperate by helping us help you better, only one of those paths leads towards a garden, the other path leads towards an abyss.
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Sun May 29, 2022 15:58 Post subject:
MY issues relate to making changes to test different configurations and then losing GUI and the steps I need to recover use of GUI. One interesting thing with the builds in early December, I could make as many changes as I wanted and never lose the use Of GUI. But the latter builds are the ones causing me some trouble. But I have no problems upgrading to the latest version (which I do frequently) and even when I lose GUI access I still have full functionality from my router.