So (to everyone else), the answer was "no - the OP didn't fix the WiFi in the network config"?
It's hard to follow.
Since I'm being spiteful asking if he fixed his router, I'll go back to reviewing.
Edit:
If my post wasn't clear, I've experienced that issue with devices before where that setting was incorrectly made. It though it should have been obvious that placing something into a bridge twice might cause an issue. I never imagined someone would call it spiteful.
Edit 2:
Sans the other user inches down who runs SNAPSHOT and has no issue.
All that's gonna happen now is I'm gonna clean flash it, start again and likely end up right back here where I started, but whatever I'll give it a go.
One wrong tickmark editing etc/config file kills file content after that and files alphabetically later dont eenumerate though you can retrieve individual settings. Eye eye?
There is uci and luci to save you kinda
So I did a clean flash and I havent made the changes like I did last time and it seems to be working well after a couple of reboots, though it was lke that yesterday too.
I'll increment any other changes over the next couple of days and see how it goes.
Great! This now tells us that the hardware doesn’t appear to be faulty. And it also indicates that the issue is not a bug that affects the default config.
Now, we will hopefully uncover the problem (if it manifests again) as you reconstruct your previous config, step by step (testing at each step).
With respect, this should've been the first step in debugging your issue (even better, reverting to defaults, if only temporarily).
I only say this because I experienced it in my early days with OpenWrt, too. I had misconfigured something and broke WiFi; reverting to defaults and starting over fixed it and I eventually realized my error.
First, my assertion that the configuration was responsible for the crashes was correct, as we have now seen since the op reset to defaults.
Second, if one is going to claim a bug (which may well exist, still tbd), it is critical to identify the specific context in which it occurs. This means reproducing the claimed bug from a near-default state and making it possible for others to do the same. Further, this narrows down the suspect config option(s) as to make it possible for the code to be evaluated.
Third, much of troubleshooting is about first principles and logical analysis. I have helped solve a very large number of threads here, so I have seen other scenarios where the problem needs to be broken down into logical parts to be solved.
Finally, we have seen many occasions where someone claimed that there was a major bug when none actually existed. Instead it was an invalid option, deprecated syntax, or other typo or human error that was responsible for the issue they experienced. I’m not accusing the op of that, but the same troubleshooting techniques described above are the ones that help determine the cause, be it a faulty configuration or a specific option that is then shown to make the issue manifest.
So, before you call me unthinking and other insults, maybe you can take a moment to acknowledge that we are moving the process forward using some basic troubleshooting methods and we will be able to more concretely identify if the problem was purely config based or if there is a real bug (and specifically what triggers it).
I have the router running again today and everything is fine.
I have to admit I think I may have messed something up the config previously which was causing the issue.
I didn't think so initially because everything was working after I'd finished all the changes + rebooted more than once to check. When I returned a couple of hours later it started crashing so that was strange as nothing had changed.
I think my first experience with openwrt (23.05.4 with the wifi bug) tainted my perspective somewhat - I presumed it was more of the same.
On a related side note - the bugged 23.05.4 firmware is still linked to on the OpenWrt MT3000 page and there are no notes anywhere (github either) that there's a wifi bug in the firmware.
For any new users (like I was) this could really do with updating.
Anyway my issue seems to be resolved, thanks to all for the assistance.
I agree, that's another reason I thought it was a bug, but I've been trying to configure the router for around 2 weeks now and I'm finally at a good, stable point so I don't want to mess things up again.
WAT, I did not say a single word about, or regarding you. Not everything is about you, come down off the high horse already. My post was a response to the moniker insisting that reset to OOTB defaults is THEE answer to all problems is simply wrong. Anyone coming from an extensive *nix background knows this to be true.
Since there appears to no longer be a Wiki admin the update process for the Table Of Hardware is manual. I had not even finished updating entries to 23.05.4 when 23.05.5 was released. I'm working on it but it took me from July 20th to September 24th to update all but ath79, at91 and apm821xx devices. I'm now in process of updating those to 23.05.5 and then will re-update all the 23.05.4 entries. If I could find someone to give me permissions to the underlying database I could likely accomplish it much faster!