As stated elsewhere (and mentioned by beniamin here as well) people want wifi for the Brume 2 because they want a gl.inet travel sized router that has wifi, simple as that. Yes a 'security gateway' shouldn't really need wifi but we're being forced to try and repurpose Brume 2 since gl.inet don't make anything else suitable.
Gl.inet only make one true travel sized router, the GL-AR300M (I'm perhaps unfairly ignoring GL-MT300N-V2 since GL-AR300M is already too slow for OpenVPN usage these days and GL-MT300N-V2 is even slower).
The Brume 2 is significantly larger than GL-AR300M and highly debatable if you could call it a true travel router given the size but I think most would grudgingly accept those dimensions if they had to - it doesn't have any wifi support currently so utterly fails the travel router scenario as is but a decent enough starting point.
Absolutely everything else gl.inet make is laughably huge and in no way a true travel router regardless of the marketing, depressingly every new product release pushes the dimensions larger and larger not to mention the flimsy design of those other products.
GL-AR300M must be approaching a decade old now and still no replacement, if gl.inet reused the same tiny case and just updated the CPU to something newer (and internal wifi obviously) they would sell A LOT of them, doesn't need the latest and greatest wifi or even the worlds fastest CPU, I'm sure they could easily fit something capable of say 40-50mbps openvpn within that case given technological advancements of the past decade and that would make a lot of people very happy. I'd even take the same IEEE 802.11b/g/n wifi as GL-AR300M if that was the trade off required for some sensible product dimensions but something faster better of course provided it didn't increase the dimensions.
I'd love to see gl.inet develop a new product with 2x ethernet ports where the main focus was "smallest size possible" for once, unfortunately every time they get fixated on including the latest 'ultra mega superfast lightning hyper +++' wifi which adds huge amounts of heat and forces the product dimensions up and up - a true travel router is going to be mostly used in a small hotel room using a very limited speed hotel wifi connection or whatever poor mobile reception you can get inside the building - neither option being quick enough to have any real need for the latest and greatest wifi, just utterly pointless (and if you think that's wrong gl.inet already have countless existing bloated sized products to pick from with lots of product overlap to satisfy you).
Sorry such a long post but to reanswer the question, the main downside to buying a Beryl AX is the Beryl AX is absolutely massive for a 'travel' router (those flimsy aerials are a disaster waiting to happen as well of course but the size kills it as an option before you even get to that).
So you don't want to use a Beryl AX to replace the Brume2 because the Beryl AX is too big to be a travel router for you - which obviously has nothing to do with the Brume2 use case? I guess what I do is not traveling with the Beryl AX then. I am not trying to be argumentative, but the Brume2 is not a travel router and is not intended to be a travel router. You are expecting them to make a change to a product to make it something different than it was intended to be. However, the "too big to be a travel router" can perform the same functions at the Brume2 at similar performance levels. Presumably, at home you can accommodate a larger format device than the Brume2, so the Beryl AX should be usable.
I travel with either a Slate AX (slightly larger than Beryl AX) or a Beryl AX. They both travel well and both work off my battery bank I carry in my backpack for mobile use. I also own 3 of the older Slates (AR750S-EXT) and they were smaller of course. They were also severely underpowered for today's standards and cooling in that small of a case with performant wireless and VPN capabilities would be difficult at best. So to cover for that, they can neither make the Beryl AX smaller or the keep the smaller size of the Brume2. It is a trade off. So you would either end up with a throttled travel router to make it smaller or you would end up with a larger Brume2 to allow wireless, which most people who purchase a Brume2 apparently didn't really want anyway.
Agree to disagree here I think, but neither opinion is bad.
The most important feature of a Brume 3 would be that it doesn't have a lot of problems and doesn't get bricked. The Brume 2 a very good, small, low power, pretty fast router in theory, but there seem to be so many Brume 2s getting bricked and having problems. Do we know why?
Regarding adding wifi and more ports, other routers already have those things. If GL-iNet want to add ports and wifi to the Brume 3, I suggest also keeping a varient which is small and without wifi.
You may not have, but a significant number of users of Brume2, myself included, have had issues with recent updates that required de-bricking to recover the device. Not sure where your 70% comes from though.
If 70% was meaningless, 99% is too. Unless only folks who use custom scripts or plugins use Brume2, or they don't use any other model that is less prone to bricking, you are just making crap up. Which it sounds like you are. Brume2 is the ONLY gl-inet router I have ever had to recover due to an update issue. If anything, I do far less with that as it only functions as my wireguard endpoint. I don't do any other routing through it. Just stop with the nonsense blaming users for the issue, please.
I didn't open a new thread as I was able to figure out how to unbrick the device myself. I recovered using the version of code I wanted to move to as I did not see a reason to test further at the time. I had to rebuild all of my wireguard configs after and get my client devices back online.
In short, was running fine, tried to upgrade to 4.7 code, never came back. Never booted, LED never turned white, just solid blue. Explain how a config would have caused that such that the boot environment was corrupted.
It depends on the config. The boot environment isn't protected in any way. If you want to destroy it, you can easily do so. As long as Uboot still works, you can debrick using this method.
Ok, let me rephrase, how would so many people on here that indicate they have had trouble with the Brume2 bricking on update accidentally clobber the boot environment via the GUI?
I don't use the Brume2 actively but i do also see more increase of people having bricks and from what some sounded like even worser ones being not able to attend into u-boot, the last one im not sure about because it depends heavily on the knowledge of the user but it can be hardware issue.
I believe @alzhao mentoided this also on one of these topics it was a hardware defect.
but if it happens this often, and indeed has also the chance of u-boot breaking.
I don't understand why theres not a PSA anouncement yet so people can check on serial numbers wether their unit has this defect, and or wether the defect has a chance to break u-boot, or it are maybe two issues?
I hope and expect they will make an announcement about the problem and about the future for Brume 2 or maybe Brume 3. They said they are in the last step of verifying the problem so maybe it will be soon.
I think that it is important that the new Brume 3 chipset is supported by OpenWrt so there will be a good chance the device will be added to a stable release. It is good for the users who want to use or try OpenWrt, and it is good for GL-iNet because many more people will buy it.
@alzhao Since you have now released new firmware and uboot versions that should resolve the issues with the MT2500s, are you still planning to release a Brume 3 with a new chipset or other changes soon or will you just restock and keep selling the Brume 2?