Hi Guys
What are your thoughts on this device? https://www.amazon.com/GL-iNET-GL-MT300N-V2-Repeater-300Mbps-Performance/dp/B073TSK26W/
Anyone here use one? The reviews seem mixed.
1 Like
Have been using one while recently away in Hotel. Solid performance in router mode with usb teathering to my android phone (to avoid capture portals due to time constraints). Gl-INET frontend makes it very easy to setup Wireguard and OpenVPN and turn them on/off. Its not dual band device. Only in last few days have I gone into Openwrt. It comes with closed source wireless driver so no tinkering with that. There is an opensource driver in the Openwrt download 19.07.2 but you lose the GL-INET frontend.
Yeah I’m not interested in using their frontend.
I’d want to install “clean” openWRT on it.
So you’re telling me I’ll lose the onboard WiFi if I do this?
No. If you download the latest Openwrt from Openwrt site you will get an opensource driver that you can adjust. It's said that the opesource driver is not as stable. The firmware from GL site is closed sourced driver .I have tried opensource driver and found no problems but was only using it for 1-2hrs. Even when you brick it , its very easy to recover.
I have used loads of them for clients building an 80211s mesh with encryption. I have been using imagebuilder from a recent snapshot to make a custom image and found it very reliable.
The open source driver is now quite mature. Back when OpenWrt 18.06.x first came out, it was almost unusable, all fixed now, but I guess this is where the bad comments have originated from.
The wifi is very good and the receiver does seem quite sensitive resulting in a greater range than using the oem firmware.
For my application, the cpu/open-source-wireless copes very well with an encrypted mesh running at the same time as encrypted access point, on the same radio - far better than I expected with a single radio.
For doing your own thing, I would very much recommend these, the 16MB flash and 128MB ram giving lots of headroom.
1 Like
I have been experimenting with vanilla OpenWRT 19 on these device.
For me the Wireless in unstable if put under load for more than a few minutes.
I have a 2.5GB file on a server on the WAN side, and connect PC LAN side. If I download it will never complete with vanuall OpenWRT 19, but is all good with the stock GL-iNET firmware.
Ethernet is still responsive afterwards, and I can ssh or luci to reset the wireless and this brings the interface back, so this the driver for certain.
If you do not need the Wireless, then the ethernet is rock solid and IPv6 seems to work, limited testing on this as I am still learning, I can ping on LAN etc.
I tried trunk as of 25/08, slight improvement in wireless I think (might be environment), but still problems.
Simon
This was true, but with 19.07.3 (or maybe even earlier), I have no problems at all (afaik mt76 drivers were backported from master).
You can still see very similar symptoms under high load if your usb power supply is not good enough.
When transmitting, the wireless can draw significant current for a very short interval. The average power requirements are probably less than 500mA but millisecond peaks of over 1A are possible.
I have looked in detail - with an oscilloscope - and the effect is clear to see.
During a large transfer, a poor quality power supply will heat up and drop its output voltage causing the wireless to hang or even in the worst case cause the SoC to crash.
A "Smartphone QuickCharge" grade charger will usually do the trick. Alternatively you could do some hardware hacking and add a big electrolytic capacitor as a reservoir.
I find a good quality power supply of 2A capacity is ideal.
I am not certain, but I think the gl-inet firmware now also uses mt76.....
2 Likes
I found 19.07.03 stock quite stable, but throughput was terrible, which I think is why stack was stable!
I must admit, my initial thought was power. I swapped to a dual plug 1a/2.1a usb connector, and switched the MT300N-V2 to the 2.1a, still very easy to crash the wirelles. The device is fine and will happily peak for a time at 60mbit (busy, busy on 2.4GHz around these parts) with stock GL.inet firmware. Always stable.
I can get similar performance with recent trunk (or whatever we call it now) version of formware. However the higher the throughput, the mroe likely the wireless is to crash.
To get stable wifi I have taken to using a tbf on the output of lan wireless limiting to about 35mbit, with occassional peak about 40mbit as tokens are freed. I still need to play around with the numbers on the trafifc shaping.
Two things of note.
If I connect the WAN wireless it is running with no problem faster than 40mbit.
It only seems to happen in access point mode.
I am not ruling out power, as these are cheap plugs, but they run the GL.inet f/w ok, and raspberry pis with peripherals OK on the 2.1a. So seemed proven to me.
Thanks for your suggestion, I wil investigate power a little further.
Simon
Mmm, interesting. Do you only have one mt300n-v2? Perhaps the one you have has a fault?
My early tests a couple of years ago with the GL firmware (with proprietary drivers) showed throughput was quite low.
Open source drivers at the time were very unstable and exhibited similar issues to what you are getting.
The latest open source mt76 drivers seem rock solid and seem to push the radio very much harder giving far improved performance (perhaps at the expense of possible power supply issues).
I have set up many of these for clients and not seen any issues apart from the initial power supply problem. Since that was resolved, no issues at all.
Many of my client units are AP or AP/Mesh in busy hotels and they get quite a hammering traffic wise.
Most are achieving ~200 Mb/s in ht40 mode when set up as ap/mesh.
The Wireless Enviornment here is not great.
If I widen yo 40MHz, throughput goes down. I live in an estate of flats (3x2, 8 flats per block, 16 blocks). The 2.4GHz is absolutely jammed, The 5GHz is fairly free -only 30 networks in range. Dare not count on 2.4GHz.
So it could be enviornment. Given your observations, I am loathe to make bug report and waste developers time, as throughput is not important to me for these devices and the lab I am putting together and I can shape my way to reliability. However, would like to see the driver as good as it can be.
Simon