I'm mostly using my Beryl in repeater mode during vacation to provide all my devices easy access to public hotspots / guest WiFis.
For this, it would be very handy if one could scan WiFi QR code when connecting to a new public hotspots / guest WiFi. Unfortunately, I didn't find such a function yet.
Could you image it? It would take some work but I could easily see GL.iNet adding the feature in their mobile app that 1.) scans the posted Wi-Fi QR code, 2.) sends the info to the router and 3.) reconfigures the repeater to use it.
Heck, I would think the mobile app could even push the details over as a unique configured .conf file to the router via scp if the mobile app saved the same login credentials used by dropbear.
Wow, what an idea. I can't think of a single travel router manufactuer that has that capability!
(@bruce : GL.iNet, @mu88 & I can discuss compensation later. I know I wouldn't mind a Slate 7. )
That's only to connect to the travel routers own SSID. OP I believe was asking for a feature where we can scan the connecting repeater SSID that might be displayed via QR code on the premises.
@9b9e69c2-4b75-4420 is on the right path. Sounds like it could be an interesting feature.
I think it could even be a killer feature. I've also been following along the reports of the fiascoes of using a travel router on DPI-scanning sites such as cruise ships. An update mobile app with an internal list of various AP configuration settings for various site operators could really 'take the wind out of the sails' of those who want to block us from using travel routers:
Heck, you could even pull these conf list directly via the app from a GitHub repo. That way anyone could contribute their findings/'known good' settings.
I'll also take a Comet Pro to accompany that Slate 7, Bruce. I'm only half kidding. GL.iNet is about to leave every other travel router manufacturer 'in the dust' if your devs can properly implement a solution to QR scanning & the aforementioned DPI/cruise ship problems.
You'd better get a pay raise or a nice little bonus, too.
@alzhao : I think your company is on its way to be an even greater 'disruptor' in the market. Congratulations.
The question with cruise WiFi is improved, please upgrade to the latest firmware first, and enable Camouflage mode for repeater and then you can use it on the cruise ship.
Does the camouflage mode also automatically match the hostname of the mobile device that was first authenticated to the ship's captive portal? I don't think so... so there's still that method the DPI can block out these routers.
You guys should put me on the payroll as an 'outside consultant'.
Scan the QR using smartphone, then sync to the router. It seems complicated. Smartphone and router are just two devices.
What we have now in Slate 7 is that you can connect to OpenWiFi easily form the touch screen. Seems needs to add a camera on the router to scan QR code. I actually considered this before.
... but they both have Wi-Fi capabilities & your app is already used to communicate with the device. The phone reads & translates the QR code anyway. I don't think it much of a challenge to output it to a configuration file &/or saves it in the GL.iNet app's sqlite database (assuming it has one) just like any other saved profile. The user would scan the QR code via the app, connect to the device, chooses the newly saved profile, enters their device creds (if not already saved on the phone to 'auto login') to push over the profile (like using dropbearor other scp client/curl)
I don't do mobile app development but I can tell you I already have parts of OWRT, including on GL.iNet firmware, execute similar tasks like the dynamically re-configuring the firewall, other aspects to push & pull data (via curl or rsync) to/from hosts base on various changing states:
There's already a camera available. I don't think a function to output & P2P sync a JSON/XML/TOML file from a mobile app to a Linux-based device is beyond the skills of GL.iNet developers. It's not beyond mine.