Other than the other things I pointed out.... It is up to the OP to decide given the information accrued here.
In summary:
In contrast, if one day for example OP wants to use VPN, MT3000 will definitely blow the MT1300 away (I own MT1300, so I know it's not fast), both devices are great IMO, while OP mentioned that he/she can get MT3000 with lower price than MT1300, definitely should go for MT3000
I don't recall him saying so, but the point was to make him aware of the difference between the two routers.
Yes, I tested it this afternoon.
eg iphone 11 and earlier do not support 802.11ax, so the connection falls back to 802.11n
A similar story with Android.
At least we agree on something 
I love these forums! Thank you all for your contributions. Even though the power consumption is no problem to me as I will mostly be using it at hotels I am a bit curious about power consumption when both devices stream a video over wifi.
All of the input has been very valuable in making a decision. I have gone with the mt3000 as I mostly use wireless devices and even just two ethernet ports is more than enough for me. I got it for 80 USD (GBP 65, EUR 76) including shipping.
I didn't open the box of the Opal as it is still sealed, so I can easily return it.
Thanks again everyone.
However you don't want it to sit idle and do nothing right? People tested that MT3000 also using 3.8W even when there is WiFi transmission. And.....OP is going to use it as travel AP in hotel....this is never a problem though.
You must be kidding me that iPhone 11 is not supporting AX.
And even for phones without AX, most of them do have AC (my 1st gen iPhone SE which has AC support still here in my AX environment) and why would they fallback to 11n?
The only trouble is when you have the ancient 802.11b devices that requires you to turn on some compatibility mode, but I doubt you still have those devices, other than that, newer routers are just stacking new standards on top of existing one, why would they be incompatible?
Talking about old devices, below are the devices I am running in my AX network fine:
Feel free to find out some older devices that doesn't work with AX router and report, I am interested to see what's the use case and how many people are still having such old thing.
Threads like this one can often result in a valuable sharing of ideas, knowledge and experience, but sometimes they also attract last word trolls.
@Oldnewb Sounds like you got a good deal. I will be doing some hard testing on an mt3000 in the next few days as time permits but so far it looks good 
Hi,
I think the Opal and the MT1300 share the same firmware (https://dl.gl-inet.com/release/router/stable/sft1200/4.3.17 and https://dl.gl-inet.com/release/router/stable/mt1300/4.3.17). And IMO it's a travel router, I'm just going to use it to connect my devices to my VPN and since the Opal is inexpensive it won't break the bank if it get stolen or whatever.
And since it's probably the same firmware, chances are it will be updated as long as the Berryl receives updates.
The Opal (sft1200) and the (Beryl v1 ) mt1300 are totally different hardware so most definitely do not share the same firmware.
Also the Opal is NOT supported by official OpenWrt and it is unlikely it ever will be due to the chipset it uses.
Just because the OEM has the firmware for both devices at the same release version number, it does not mean the firmware is the same.
If you are happy with the Opal Gl-inet firmware then give it a try - but use the Gl-inet forum if you have any questions.
They are completely different hardware, how can they share the same firmware?
Opal is using non open source supported platform so one day GL decides to discontinue then you'll have no upgrade.
Hi,
Not a bad choice for a travel router, may I recommend the GL.iNet forums going forward as the SFT1200, like the SF1200 is not compatible with Openwrt directly, and uses a heavily forked SDK with proprietary binaries and an old kernel version.
It could be the same codebase compiled for the various platforms they use. I don't really know why they would have the same version number otherwise. I'll ask Glinet about the firmware updates and proprietary OpenWRT version.
I don't know if the MT1300 is really a good deal (quite expensive IMO, for less storage and nearly the same performances compared to the SFT1200). Is really the open source label justifying this cost, I don't know. The firmwares are still updated as of today, so it's not yet a clear choice.
At some point (regarding the cost of some routers) I wonder if it wouldn't be better and cheaper to take a SBC (arm or x86) and run a complete OS, like OpenWRT, Armbian, Debian, Proxmox PVE, PfSense, OpenSense or whatever. The soft would be mostly open source and up to date, but you can easily mess up the configuration.
The MT3000 is certainly better and has more embedded storage than the MT1300, so I guess for the price it's overhaul a better value (and I would recommend it). However with the spread of the Wi-Fi 7 norm, we might find inexpensive second hand MT3000 before the support for the SFT1200 ends (I don't need a MT3000 immediately, as I can wait for the newer generation, since I don't travel that much or for its price to decrease).
I think it already happened...
In fact just like official 23.05.4 OpenWrt release, there are thousands of different routers being supported, while most of the core features are the same but driver/uboot are not the same, home routers are embedded devices that even the bootstrap requiring specialized instructions, this is not x86 PC with Windows XX which has BIOS/UEFI to help booting the system up.
Yes you can, in fact many people doing this, but you don't have WiFi, and it might defeat the purpose of "travel router".
I own both, I can tell that both are excellent devices, so in case you can find a cheap used MT1300, don't hesitate and just take it (previously US Amazon has refurbished GL-INET router on sale and this MT1300 sold out in a few hours). Unless you are using it as main router otherwise as a 802.11ac 2x2 router it really works well.
Where did you find this info? The SFT1200 is at most a 3 or 4 years old product and it's not announced as EOL anywhere yet. The SF1200 is discontinued and it will still receive security updates for a bit less than 2 years. The discontinued products are listed here.
I don't know if I'll have more details from Glinet about that. The firmware is distributed as a tar archive which contains 3 files, a CONTROL file, probably used to check if it's the right board, then a kernel and the root with all the needed drivers.
$ ls
CONTROL kernel root
$ file kernel
kernel: u-boot legacy uImage, MIPS OpenWrt Linux-4.14.90, Linux/MIPS, OS Kernel Image (lzma), 2497662 bytes, Thu Jun 6 19:57:26 2024, Load Address: 0X80100000, Entry Point: 0X806A3420, Header CRC: 0X6812C23E, Data CRC: 0X5679D97C
$ file root
root: Squashfs filesystem, little endian, version 4.0, xz compressed, 14538029 bytes, 4086 inodes, blocksize: 262144 bytes, created: Thu Jun 6 19:57:26 2024
$ cat CONTROL
BOARD=glinet_gl-sft1200
$ unsquashfs root
Parallel unsquashfs: Using 4 processors
3891 inodes (3461 blocks) to write
create_inode: could not create character device squashfs-root/dev/console, because you\'re not superuser!
[=============================================================| ] 7351/7352 99%
created 3391 files
created 195 directories
created 499 symlinks
created 0 devices
created 0 fifos
created 0 sockets
created 0 hardlinks
$ ls squashfs-root/lib/modules/4.14.90/
act_mirred.ko ip_set_bitmap_port.ko sd_mod.ko
act_skbedit.ko ip_set_hash_ip.ko sf16a18_fmac.ko
arptable_filter.ko ip_set_hash_ipmark.ko sf16a18_rf.ko
arp_tables.ko ip_set_hash_ipportip.ko sfax8_factory_read.ko
arpt_mangle.ko ip_set_hash_ipport.ko sfax8_netlink.ko
br_netfilter.ko ip_set_hash_ipportnet.ko sf_eswitch.ko
button-hotplug.ko ip_set_hash_mac.ko sfhnat.ko
cdc-acm.ko ip_set_hash_netiface.ko sgmac.ko
cdc_ether.ko ip_set_hash_net.ko sha1_generic.ko
cdc_ncm.ko ip_set_hash_netnet.ko sierra.ko
cdc-wdm.ko ip_set_hash_netport.ko slhc.ko
cfg80211.ko ip_set_hash_netportnet.ko startcore.ko
cls_flow.ko ip_set.ko ts_bm.ko
cls_fw.ko ip_set_list_set.ko ts_fsm.ko
cls_route.ko ipt_ECN.ko ts_kmp.ko
cls_tcindex.ko jbd2.ko tun.ko
cls_u32.ko mac80211.ko udp_tunnel.ko
compat.ko mbcache.ko usbnet.ko
cp210x.ko mii.ko usbserial.ko
crc32c_generic.ko mtdoops.ko usb_wwan.ko
crc-ccitt.ko nf_conntrack_ipv6.ko vfat.ko
crc-itu-t.ko nf_conntrack_netlink.ko wireguard.ko
ecb.ko nf_defrag_ipv6.ko xt_addrtype.ko
ehci-platform.ko nf_nat_ipv6.ko xt_CLASSIFY.ko
em_u32.ko nf_nat_masquerade_ipv6.ko xt_connbytes.ko
exfat.ko nf_reject_ipv6.ko xt_connlimit.ko
ext4.ko nls_iso8859-1.ko xt_connmark.ko
fat.ko nls_utf8.ko xt_CT.ko
fuse.ko ntfs.ko xt_dscp.ko
gl-sdk4-hw-info.ko option.ko xt_DSCP.ko
gl-sdk4-tertf.ko ppp_async.ko xt_ecn.ko
huawei_cdc_ncm.ko ppp_generic.ko xt_helper.ko
ip6table_filter.ko ppp_mppe.ko xt_hl.ko
ip6table_mangle.ko pppoe.ko xt_HL.ko
ip6table_nat.ko pppox.ko xt_length.ko
ip6_tables.ko qmi_wwan.ko xt_owner.ko
ip6t_MASQUERADE.ko rndis_host.ko xt_pkttype.ko
ip6t_NPT.ko rt2800lib.ko xt_quota.ko
ip6t_REJECT.ko rt2800usb.ko xt_recent.ko
ip6_udp_tunnel.ko rt2x00lib.ko xt_set.ko
ipheth.ko rt2x00usb.ko xt_statistic.ko
ip_set_bitmap_ip.ko sch_hfsc.ko xt_tcpmss.ko
ip_set_bitmap_ipmac.ko sch_ingress.ko
I wonder if there is a generic version of OpenWRT for the MIPS architecture that I could use to inject the drivers, forcefully load them and install it on the router. Would be pretty funny if it works (it probably won't). I don't really know if the drivers would work with the new kernel.
For my home network I prefer to have stand-alone "APs" (as I need 3) to handle about 20 Wi-Fi clients in a house full of concrete and steel beams and I'm thinking about virtualizing my router (most likely using Pfsense), since I already use Proxmox for all my home automation stuff and my current router will reach EOL in December after more than 7 years of good service (I'll probably still use it as an AP if I find an alternative to Merlin).
For a travel router, I just need an easy access to my home network for my laptop and smartphone. I may also use it at work to bypass the NTP server blockage which locks the RPis from accessing the internet. All the SSL certificates are seen as non valid and since we use the RPis with newbies, it's easier to reroute the traffic to a VPS or to my home instead of manually configuring each RPi each time we install Raspbian, etc.
Devices without OpenWrt support are as off-topic as discussions about the gl-inet OEM firmware here, if that's what you desire, please use their support forum instead.
To answer your question, as the opal is not supported by OpenWrt and very unlikely to ever be supported by OpenWrt, it is a bad choice within the context of discussions about it here.
You are right. I can confirm the Opal will never be supported. According to GL-iNET Technical Support, the hardware is reaching its limits. They will still continue to upgrade it up to 2 years after it reaches EOL (not announced as of today), while they will only fix bugs on OpenWRT 18. Also, I cannot find any MT1300 in my country, I'll probably change my mind and also get the MT3000, it will be more sustainable.
As I mentioned, it's NOT ONLY DRIVER, don't think in x86 way, in x86 different motherboards can boot and let you load driver, this is handled by UEFI/BIOS. But in embedded device, for example, Cudy TR3000 & GLINET MT3000 are both MT7981 platform, their design are almost identical, however the way both device booting up is not the same, you need to figure out how to boot it properly, that's why Cudy TR3000 has official OpenWrt a lot later than the MT3000 since different processes involved.
For drivers, without source code, taking pre-compiled one won't work with other kernel, you just need to find 2 PCs, with a piece of hardware that needs explicit driver installation, then copy over to another system and try, you'll know what I am talking about. That's why we need driver upstream to kernel to have the proper maintenance.
Ok, I get it. I would need to recompile the kernel anyway for the bootloader to point to the correct memory addresses, so I would need a deeper knowledge of the board (and of OpenWRT), which I can get from the confidential datasheet of the SF19A28. And, the hardware is too limited anyway, so it's not worth anyone's time to try to port it.
If you look at other posts about new hardware support, it's very often that you first find the UART port to console in, observe how it boots, from the boot messages trying to figure out the whole process, something like that.
But the point is, you don't have source code of SoC driver, how do you compile driver? And even with that, most of the time those drivers are ugly patched to the kernel of the product's own source tree, now most devs are doing is to make it scalable, it's really a very tough work, and don't forget to have more people to test with you for debugging.
you had it?
cool !