GL-MT300N-V2 unstable connection with hotel captive portal wifi

Hi, I have unable to get a stable wifi connection using the GL-MT300N-V2 router with any of the following firmware:

v2.2.271
v2.3.009-1204
v2.3.010-1214

I am connecting to a hotel captive portal wifi service. I am also using OpenVPN or WireGuard VPN in the router. I have been trying firmware 1214 today, and it has been better, but still not getting a solid connection. It disconnects within about 30 minutes of connecting, and I cannot access the Internet, but in the admin it still says the there is an Internet connection (and IP info is still listed). I then have to disconnect, then reconnect to get it to work again. The connection also drops when I am not using VPN in Mango (just using VPN in laptop). When connecting directly from a laptop wifi + using VPN (not using Mango), the connection is solid.

I am using the Mango router as a modem, connecting to laptop via ethernet/LAN, then using Mango to connect to the captive portal wifi. I put a little network behind the Mango, reason why I don’t just connect directly from laptop to wifi.

Some stuff in the logs that might indicate something (I think the “Token invalid!” error is the most related since the time stamp is close to the time the issue happens):


Fri Dec 14 17:17:10 2018 user.info : [ 146] gl-sdk>> (HTML) new session init…
Fri Dec 14 17:17:20 2018 user.info : [ 387] gl-sdk>> session delete … Token invalid!
Fri Dec 14 17:17:25 2018 user.info : [ 146] gl-sdk>> (HTML) new session init…

Fri Dec 14 17:22:02 2018 user.notice firewall: Reloading firewall due to ifup of wwan (apcli0)

These only appear in the 1214 firmware:

Fri Dec 14 17:37:01 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Fri Dec 14 17:37:01 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Fri Dec 14 17:37:01 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

One way I was able to solve this was to put an old HooToo HT-TM02 TripMate Nano (uses a clean OpenWRT install) in-between the Mango and the portal wifi. The connection is stable this way, but speed is reduced due to the HooToo’s slower CPU.

I’m not sure if its just that the Mango and this captive portal wifi are not compatible or what. This setup is fine at my home wifi.

Also, I am noticing that when I use a clone or random MAC in the admin, the router still uses the “factory” MAC address (I checked via ifconfig, plus the captive portal url shows the factory MAC).

Any thoughts on how to solve this will be appreciated!

Thanks,

Soul1


PS. GREAT JOB so far on the new v2-3 admin, makes things easier. Here are some comments:

Pros:

  1. Clean interface
  2. New “use WAN port as LAN” made my life easier
  3. WireGuard VPN addition is GREAT (using Mullvad), I am seeing 15+Mbps… I was only getting 6.5Mbps max with OpenVPN.

Cons:

  1. Cannot connect to Intenet (Rx) when Tx radio is off. Firmware2.271 was able to do this easily. Though messing with OpenWRT gets this to work.

UPDATE:

When using the Laptop > Mango > HooToo > Captive Portal Wifi method. I am still getting some disconnects, but I am able to reconnect after about a minute without logging into the admin and disconnect/reconnecting.

So, still not sure what the issue can be, if it’s just the wifi here or router related.

OK another update. Connecting from laptop > Mango (with VPN) > hotel captive portal wifi, I was disconnected for about a minute then it reconnected by itself. This happened at the 09:48 part in this log:

Sat Dec 15 09:25:11 2018 user.notice firewall: Reloading firewall due to ifup of wwan (apcli0)
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:25:58 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:26:23 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:27:42 2018 daemon.notice netifd: wwan (3023): udhcpc: sending renew to 10.30.50.1
Sat Dec 15 09:29:06 2018 daemon.notice netifd: wwan (3023): udhcpc: sending renew to 10.30.50.1
Sat Dec 15 09:29:48 2018 daemon.notice netifd: wwan (3023): udhcpc: sending renew to 0.0.0.0
Sat Dec 15 09:29:48 2018 daemon.notice netifd: wwan (3023): udhcpc: lease of 10.30.51.154 obtained, lease time 21600
Sat Dec 15 09:40:42 2018 user.info : [ 146] gl-sdk>> (HTML) new session init…
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:11 2018 daemon.err stubby[9469]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Sat Dec 15 09:48:54 2018 user.notice firewall: Reloading firewall due to ifup of wwan (apcli0)

So, it’s operating just like the way with the HooToo router in between (but faster :slight_smile:). I am guessing that it is just a weird issue with this particular hotel wifi. I contacted them and they are pointing the finger at the VPN. I connected a laptop directly to the hotel wifi without VPN and the connection was solid.

Anyway, I am leaving this hotel tomorrow so don’t worry about this issue too much, but I wanted to mention this experience in case anyone else runs into it or if it can help with the v2-3 dev.

thx!

Some captive portal is limit to the connection time. You have to re-authenticate after 30 mins, 1 hour or other times, but the connection is still exist. After re-connect the captive port, does it work?

Hi kyson-lok,

Yes, after disconnecting & reconnecting, it worked. Though it wasn’t a set duration of time for each disconnection, it varied from 5min - 30min. But, when using the laptop directly, there was no disconnection.

I am no longer at that hotel, but I just wanted to let you know that this was happening. It looks like for that particular captive portal, when using an external router, you have to disconnect, then reconnect periodically. Maybe a cron “service network restart” on the router would solve this?