[SoLoR]

[the-joker]

@dusanv and @all Reporting issues is welcome always.

Especially reporting issues in the right way with information to help duplicate the problems. No duplication will lead nowhere.

Also knowing where issue is, is it DD-WRT maintained code or is it a config issue or is it somewhere in some 3rd party library/component/driver.

If the issue is caused by 3rd party something, this needs to be reported upstream as DD-WRT doesn't maintain that code, so there is a great deal to be said about reporting issues.

Sometimes something is a known issue and we even have workarounds in the meanwhile no matter where issue is.

So the being helpful part by reporting an issue is subjective, most issues reported are low quality and contain no actionable information, and thus no one can really help and we never get to the bottom of it and nothing gets resolved.

@SoLoR bisecting is always a good way to do it, SVN idk if it even supports it, but if this is a driver issue, and you find the commit we can use the information to determine if this needs to be fixed upstream or is something that can be patched internally.

Now that is indeed advanced troubleshooting and the kind of actionable information that will lead to a fix sooner rather than later.

I also understand your comment about reports on build threads saying its OK when you or someone else has issues (happens frequently and it has happened to me), clearly not everyone can be right, it either works or not (not that simple), both are possible (Ill quote an example about the R9000 where one single setting killed the UI/buttons and it would crash and most others didnt have that issue cause that setting was turned off on their setup).

If we knew each persons specific setup, environment and clients and could compare I bet we soon start to see why this is (you will hit a wall when asking people with same router to corroborate or test something specific, sad but true, its extremely hard to get this here). Sometimes a single setting triggers a bug and not everyone will use that setting or whatever. Indeed from your perspective in relation to your situation will likely vary from these other reports.

Will wait however for your findings on your bisecting and thank you for your alacrity in trying to get to the bottom of it.

[kernel-panic69]

The guidelines that Sash posted have been in effect since late June of 2009, and people still do not follow them, and we wonder why things don't always get resolved quickly, easily, and/or painlessly. This is why this part of the build release thread post exists:

[dusanv]

@kernel-panic69, I would have loved to do so, I had those laggy firmwares for months. Nobody mentioned this.

[the-joker]

@dusanv We have forum stickies, the build threads also carry this information, but most community members just gloss over this key information and more often than not we are trying to troubleshoot issues and trying to get to the bottom of these issues with no real actionable information.

This is why every so often I blurt out the facts of opensource development and support, even if I reach < 1% of users its a success.

Well now you know anyway. So you can better help us to help you.

[Dadasuprem]

Hi,
It might be great if we could export the config as text to share for debugging, maybe it already exists but I couldn't find the post about it.
The nvram backup is unusable for that and otherwise it takes a lot of copying and pasting.

[kernel-panic69]

You can add a date and build number to the file name and then copy it over via scp to your PC.

[Dadasuprem]