We don't leave for a couple weeks and I've been debating this as well.
If I do this:
Connect with my iPhone first, go through captive portal use up the MSC device license
Then connect with the travel router, clone the iPhone MAC to the router
It SHOULD work either with the router or the iPhone.
Eg: If we're just walking around, disable the travel router, use the iPhone.
However the other method of just doing it with the travel router is probably "safer", just that I'll always need to use the travel router for Internet access. Eg - are they doing some other profiling beyond just the MAC that they won't recognize the travel router is legit after using up the device license on the iPhone.
in the GL.inet GUI, set the Network mode to "router" , not to "extender"
In the GL.inet GUI start the repeater , and scan for the MSC wifi
Set the "Auto-Enable Login Mode for Public Hotspots" option on (it will disable VPN and DNS setting, until portal login is done)
select and connect to the MSC wifi with the OPAL
You will not have internet access because the MSC portal Login is not done yet
You may have to reconnect to the OPAL now with the smartphone if the same band is used for the smartphone as for the MSC wifi (OPAL will change channel to the MSC wifi channel)
ON the smartphone surf to some HTTP based website (not HTTPS) while connected to the OPAL with the smartphone
This will trigger the MSC login page. MSC sees only the OPAL, independent of whatever device is used through the OPAL. The login will be registered for the OPAL.
Any device connecting through the OPAL will be seen by MSC as coming from the OPAL
Maybe they don't like this, and will try to discover the fact that it is not the OPAL itself. They will check the TTL of packets and other things, maybe even the MAC address used and compare it to the VENDOR list of the hardware MAC address, in an attempt to detect a travel router. TTL if not mitigated changes when "extender" or with Network mode "router".
The host network (MSC wifi) only sees the OPAL when in Network Mode "router", and everything comes and goes to the OPAL So MAC vendor list and TTL check is the only thing that will reveal the OPAL. You can use the connect option "Enable Camouflage" to hide the OPAL MAC address and use the smartphone MAC address instead. There is also an option to set a fixed TTL.
Oh well, the DHCP client name says GL-SFT1200 by default, so change that as well, just in case they would check that. I doubt if they do that, but I do this.
(You can only change DHCP hostname in Luci AFAIK)
System-> Advanced -> Luci -> Interfaces -> WWAN -> General setup -> "Hostname to send when requesting DHCP "
There are exemples in this forum how to fix TTL via SSH, Change TTL in the case they check it. Change outgoing TTL
These steps were exactly how my experience was recently on a Disney cruise and also what I do on American Airlines flights.
Logging in through my phone first and then cloning my phones MAC etc on the router results in my router WIFI radio cycling on and off and not being usable in repeater mode.
These steps are exactly the same for my USB150, AR300M and Slate AX.
There are several descriptions here for the steps taken in this thread.
"Logging in through my phone first and then cloning my phones MAC" is quite different from what I described as steps.
It is a "cat and mouse" game (Squid game?) to be detected or not. Any little thing can reveal the presence of an unwanted travel router.
They probably answer with a TTL=1 , so the packets cannot be routed further down, unless you reset also the incoming TTL number. And the TTL of the smartphone probably is 32, and for the router it is 64, so switching them is enough to blacklist that MAC address.
The GL.inet router SFT1200 cannot handle any DFS channel with 4.7.2beta or any 4.3.x version , only version 4.3.21 did connect to DFS channels.
Or even worse, as I'm in favor of the clever use of travel routers, I still do have to block them from time to time, because they ruin my wifi infrastructure, and the wifi access for them and others nearby.
If MSC is using some professional wifi controller, the GL.inet router will be identified even before you hit the first key. Devices at startup send lots of packets in a certain sequence, and it's a fingerprint. (DHCP info, NTP check, firmware upgrade check, cloud mgmt connect, MWAN3 checks, TTL used, respons to PING, respons to port 123, .... )
In this case the onus would be on GL to minimise their routers' fingerprints, at least for Repeater mode, so that the host network only sees traffic from client devices.
I had imagined that camouflage mode would stop this fingerprint traffic characteristic of their products, but perhaps not.
Answer here can be very long, on what and why this confrontation between use and deny of travel routers is changing over time.
The deny becomes useless these days (last year), as the old "business model" of earning easy money on connectivity dies. (30 years ago, phone bills in hotels were higher than meal and room bills for our technicians ...).
I used to block repeaters in previous years, now it's time to support them. Public and shared wifi networks MUST use client isolation just for malware mitigation, as clients are unrelated. Modern use of internet services requires client interconnection and use of VPN, A personal (travel) router is the ideal answer. That interconnect router can be a smartphone, travel router, tablet, PC, Apple TV box, etc etc.
It takes a while for every wifi provider to adapt.
In the meantime, just take your mini Starlink with you on that MSC cruise.
Let me just show a older professional wifi that is widely used:
2nd page:
Dedicated third radio delivers 24x7 wireless security
and RF analytics*
The MR18’s dedicated dual-band third radio scans the environment
continuously, characterizing RF interference and containing wireless
threats like rogue access points. No more need to choose between
wireless security, advanced RF analysis, and serving client data: a
dedicated third radio means that all three occur in real-time, without
any impact to client traffic or AP throughput
GL would have to not show their wireless fingerprints on any travel router to get around this dedicated radio.
That's why I love adding USB wifi dongle when using wifi as uplink. Good luck to match that USB wifi dongle to the AP, because I do wonder how you would be matching a whole separate radio (used as uplink) to the AP radio itself. Especially as the AP itself also makes a bit of traffic to monitor of links are up.
Indeed in repeater mode you could see that the AP and a certain client never want to send at the same time and that the AP channel follows the uplink channel perfectly (instead of trying an emptier channel or just staying where it is). I do however wonder how much such systems actually do against a repeating differently name AP. Rogue access point detection is mostly for detecting AP trying to pose as that same network (to mitm or such).
Without knowing about that interesting Meraki setup, that was practically what I did, after their GL.inet routers saturated one of my AP receivers ... check and triangulate the position of visitor APs with my other APs. (There are 30 of my AP in that network in range of the users).
With Fortinet (FortiAP's with Fortigate controller), what I used as professional IT manager, checking for "Rogue APs" and denying them access (even disturbing their wifi) is a standard feature. "Rogue APs" in a business perspective are wired APs that broadcast the business LAN to some users wifi setup. Using the corporate SSID is another major rogue action. WPA2/Enterprise access conrol helps somewhat.
Wireless fingerprints in Fortigate where just traffic based fingerprints, to identify the client devices. It will match the USB dongle to the AP, on that 'bit of traffic'. That 'bit' is quite extensive.
Looking in your own beacons will reveal how much you actually show when the AP is active. And it's a lot.
But I assume MSC is only protecting their business revenue from this internet service. Unfortunately still based on the number of connected devices and not traffic volume.
You just checked everything?
Lets see what has been talked about here already.
MSC wants you to only use one device (did they specify smartphone or not?) with each user account or voucher
What does a wifi provider do to enforce this 1 device rule?
They send out with a TTL=1 . If you do not adjust this on the incoming packets, no packet (eg portal logon screen) will go further than the GL.inet itself if Network mode "router" is used. It will never reach the client device.
If repeater with mode extender is used, any device behind the extender will request its own DHCP lease. MSC will see requests with GL.inet MAC in the request header, and the client device MAC and TTL in the request packet itself. That kind of DHCP requests often fails to get answers to the client. And different MAC in header and packet is a clear indication of a 2.5 layer bridge (=extender with MAC-NAT)) Also the MSC DHCP server will refuse to lease a second IP address to the same MAC address.
In both extender and router mode for repeater, any packet from the client device will use the TTL setting of the client device , and that packet will arrive at MSC with that TTL or with "TTL-1" if routing is used. That TTL may be different from the initial GL.inet packets, as GL.inet router but also the phone have their own default TTL value. Varying TTL values is a very clear indication of multiple devices behind a travel router. Keep the outgoing TTL values all identical in the outgoing packets.
Single device per user. If the phone is registered to the portal with a username or voucher values, then a second device will not be accepted with the same credentials. "Camouflage" is necessary to appear to be the first device , camouflage (FR) of everything: MAC, IP, Host name, TTL, ....
Portals can check on MAC or check on IP address or both. They probably maintain a list of active (logged on) MAC addresses, and the portal page will not appear if already logged on, as it is not needed then.
ICMP is not following the TCP and UDP rules of the portal and firewall. It is not a valid test to see if the portal connection is open for internet use or not.
Camouflage mode does not seem to clone the iPhones mac address.
I purchased a GL-MT3000 with the intention of using it on a MSC cruise. Not on the cruise yet but will be soon.
Flashed to 4.7.4.
For testing I’m using an Aruba network setup for captive portal / guest access. I’m an admin in Aruba Central for that network so can see what’s happening on that side throughout the process.
The intention was to do a test where I authenticate via my iPhone directly, then connect the MT-3000 and should not have to authenticate. Desired end result I can use either device as long as only one is active at a time.
The test:
I connected my iPhone to the guest network with the real MAC. Went through Aruba Central authentication. Have Internet access.
Connected my iPhone to my MT-3000 SSID using the real MAC.
On the MT-3000, I pick camouflage mode to connect to the guest SSID – and it’s not actually grabbing the real MAC from my iPhone (which is what I expected). It’s picking something else. Same mfr code but not the same MAC. Also confirmed from the Central side.
I can disable camo mode and clone my iPhone MAC and it does grab the correct MAC. But now not in camo mode.
I don’t think this is the expected behavior for camouflage mode?
Anyway, I think I’ll abandon the dream of being able to switch back to the iPhone direct.
Just do the initial connection / login with the router connected initially.
Very strange interpretation of what "camouflage" is.
Tested this as well, and the used MAC address after enabling camouflage is ... 08:8F:C3:0E:F8:B8
Don't know where this comes from .
This is totally not camouflage, this is not even hiding.( hiding is looking exactly as the client)
Maybe all traffic may now be with that MAC address, but that's not different from the normal working, without camouflage, by using a different MAC address than the setup client
EDIT
Well actually this is some form of camouflage.
The first 6 hex-digits (vendor ID) are the same of my ethernet MAC address of my laptop.
Which is 08-8F-C3-01-xx-xx. Even the hostname in the DHCP request is the same.
The next 6 are different however. Worse they change when switching camouflage off and back on. Then the DHCP server leases a new address.
Clicking "MAC Mode" as "Clone" indeed removes the Camouflage option and uses my laptop MAC address but DHCP-client-host name is "*" now.
I'm seeing the same thing - the first six hex digits match my original device, the last six appear to be coming from thin air.
On the upside Aruba central has identified my router as an iPhone, and it's seeing hostname of my iPhone not the router. So some magic there.
As what I'm doing is MAC locked hopefully if I don't disable camo mode it hopefully won't ever change the address. Should power cycle it I guess. If I lose that MAC I'm going to lose my device license on the MSC side. And have to pay for another device.
Edit: Pulled power on the router, still using the same fake MAC after the reboot.
If this option is enabled, this router camouflage itself as the same device as the client device you are now using.
If you enable camouflage mode, the device automatically emulates the MAC address based on the client device you are using
When I read that, my expectation is that the MAC address is being cloned. That's not what's happening. The router isn't a clone of the original device as it's using a different MAC. It identifies as a device similar to the original.
I think this is where the disconnect is. It's fine, it's just had I in the MSC case connected with my actual client device first, burned my device license ($$), then used the GL-MT3000 and camo mode I'm pretty sure I'd find out it wouldn't work as the MACs don't match. Now armed with this knowledge, I'll be sure not to do it that way.
So we need both : "MAC mode clone" and "Enable Camouflage".
The GUI didn't let me do that. "MAC mode" selection disappeared when "Enable Camouflage" is selected.
this router camouflage itself as the same device as the client device
this router camouflage itself as a similar device as the client device
It can work without clone and with only camouflage, but the iPhone should ONLY connect through the travel router, not directly to MSC. And the MAC address should not change on the travel router.
So the next issue is if the router ever loses that fake MAC address for the MSC SSID I'm probably in trouble. I can take note of the fake MAC it came up with originally, but I can't force it back to that value without disabling camouflage mode, which potentially disables other features I need for it to work on that network.
I'm not sure why enabling camouflage mode takes away the ability to manipulate the MAC address.
