They are often staged in mt76 but not added until you see the commits go in main. Then click the dropdown to select 24.10 and you will see them added there if backported, I mentioned I’m using a snapshot from 24.10-snapshots a few days ago. This is just for mt76 of course there are main parallel that get added to main. You can also search the git for “mt76: “ and it’ll pull all the changes from whatever branch you want to see.
1 Like
Thanks. I appreciate the additional information.
Crazy deal on this today. £75 at AliExpress from GlInet official store with UK discount code.
It has also sold out on Amazon UK!
i’m seeing a weird behavior with 5G wifi i can’t sort out. It seems something in the 10.4 version, but maybe older (you’ll see it’s not something i use every day).
My use case: flint2 as dumb AP. I have a lan wifi (only 5G, perfect). I have a guest wifi (only 5G, perfect). I have an IOT wifi (2.4G AND 5G, same ssid). Here is the issue: the 5G, and only the 5G, randomly dies. Or better, zombies. It is up. I can connect. No traffic passes (a common speedtest fails). This causes, for example, alexas connected to 5G to answer the call “alexa”, but then stalling not being able to get the proper answer to the question. If i take down and up the connection, it works. No issues logged. I’m a stuck.
If it was a common behavior of wifis i’d have tried disabling WED or other AP packages, but it happens only on IOT 5G wifi and only randomly, it’s a mess to debug
Thanks
Has anyone here with a MT6000 chosen to run a Docker container with WGDashboard & Wireguard? I currently run these in a LXC (container) on my Proxmox server, but I think the MT6000 could run them right on the router, making my setup more resilient to transient failure (e.g. the Proxmox server or the Wireguard LXC goes offline or becomes unavailable for any reason).
Just looking for some feedback before I go down a rabbit hole.
Why bother doing this with docker when you can do it directly with OpenWRT or with the GL.iNet firmware??
1 Like
Why bother doing this with docker when you can do it directly with OpenWRT or with the GL.iNet firmware??
I guess I was considering isolation and simpler maintenance?
I'm just dipping my toes in here, trying to figure out which direction to go.
EDIT: WGDashboard requires Python, which immediately made me consider an isolated container rather than bare metal on the router. Does that make sense or am I overthinking it?
I could give up having the nice WGDashboard interface if you have an alternate suggestion to manage configs and clients? (Does not need to be as fancy.)
For further context, I would be doing this on OpenWrt SNAPSHOT, not GL.iNet's software.
EDIT 2: After researching this, it's probably inadvisable to run such big software (WGDashboard) bare metal OR in a container on the MT6000. I'm going to find a low-resource alternative.
I haven’t done it but would love to hear feedback from someone who has. This router has plenty of CPU and RAM available for something like that, especially if you are hardware offloading. Linux is plenty stable worst case is spin back up the container I’ve never had a single crash on this router running lots of added services (samba, adblock, usb3 storage, sqm, etc.) so I’m sure a container will be fine. Need someone to at least do it and test it out to hear how it runs.
That's what I was thinking: if it's all in a container, the worst that could happen is it overwhelms the system and brings the router down... I reboot it, delete the container (if decided it can't be salvaged) and move on... no harm done.
I still may try it and will report back if I do.
AI is warning me: "Critical concern: 1GB RAM is extremely tight for running Docker + multiple containers. WGDashboard + AmneziaWG will likely cause OOM (out-of-memory) issues. Consider this an experimental proof-of-concept only"
Not sure I trust AI but then again 1GB might not be enough for Docker, I didn’t look into it. I’ve seen them run really well on the NanoPi lineup but those have 4GB so that makes sense. I ran a couple simple containers when I first got this MT6000 about 2 years ago but didn’t go back to it.
1 Like
FYI...
Placed MT6000 on top of my server case's exhaust, cranked up the fans from 30% to 60% for a bit more airflow, and it had an immediate & measurable impact on the MT6000's operating temperature.
First, putting the router on my server's exhaust fans without increasing their RPM:
After increasing the fan RPMs so that it blows up and through the MT6000 with some force:
(This is without running anything crazy on the router... just "vanilla" OpenWrt SNAPSHOT with some small additional packages like nano and luci-app-statistics.)
Modern ARM SOCs are running hot, news at 11.
2 Likes
It’s nice to see don’t get me wrong, and there are USB fan options, but the stock operating temperature is nothing to worry about with this SoC. I’ve run it for months even loaded up heavily and it’s never crashed.
1 Like
Tests results were not openwrt but some may still find the results interesting:
Would be nice to see the tests done again after flashing openwrt.
4 Likes
I wouldn’t mind having a copy of the json that represents those graphana dashboards
That’s an interesting review albeit a rather disappointing result with their zoom call test. I wonder how many similar wifi 6 or 7 routers would do better. It would be nice to compare official OpenWrt builds, and settings which could impact it like HFO on/off, WED on/off, TWT on/off, packet steering settings, 80/160MHz width, new builds on kernel 6.12, etc. but that would involve a ton of testing. Oh well, for my uses and for the last 2 years now this router has been fantastic for home use.
2 Likes
This was just committed in SNAPSHOT... is the MT6000 one of the victims of this (I think so)?
This fixes a failed bring up of the radio on bootup if the model defines a rename of phy in its /etc/board.json. [...] The issue is that after rename, referenced phy in config is going to be
wl0 but in phys array it is still phy0; and so it fails to find phy
and does not bring up radio.
So this should solve the stalled wireless radio startup in affected devices?
Currently I have this in OpenWrt's startup script to resolve the problem:
sleep 5
wifi
exit 0
The link didn’t work but I’m not sure what stalled wireless radio startup issue you have. I’ve never had any such issue on the MT6000 so not sure why you would need to add that the statup script.
edit: I searched ok seeing what you’re talking about the wifi-scripts update it discussed ax6s and wax206 issue pages with a number of devices listed. I haven’t seen the issue but may as well test if you’re on snapshot seems like it fixed that issue.
1 Like
Am I the only one experiencing random slow downs only on a certain client (iPhone 15 Pro)? Disconnecting and connecting again the client brings back the speeds to normal (1gbps+)
PD: I’m on OpenWrt 24.10.4 r28959-29397011cc with HFO and WED enabled
PD2: Signal and TX/RX looks fine to me it’s just the speeds that become throttled
2 Likes
I've seen something similar to this on 24.10.4 stable (same as you). I'm using it only an access point with WED disabled, 5Ghz 80Mhz on Channel 149 @ Max transmit power. Noticed it a few days ago on an Intel AX211 laptop and disconnecting/reconnecting fixed it. Same thing last night, but on a Samsung S23 Ultra. IIRC it capped out at about 60Mbps when it does 400Mbps+ normally.
1 Like