MT300N-V2 won't find hotel WiFi networks

@MrGrizzly Does it can solve your problem? This solution is for IHG as well. Because it hidden its SSID.

When I started this thread in April 2019, I had stayed at the Kimpton Hotel in downtown Toronto, and found that my Mango router was unable to see the hotel’s WiFi networks. That property has two networks intended for hotel guests: the SSIDs are “IHG Connect” and “Kimpton”. The Mango SCAN command would not find either of them.

I’ve just returned from a stay at another IHG hotel in Toronto. (IHG is a global chain including Holiday Inn, Crowne Plaza, Indigo, Intercontinental, Staybridge, and others). I encountered the same problem - the Mango router could not find the hotel’s “IHG Connect” network. My iPhone, my MacBook Pro, my wife’s iPad and my wife’s iPhone could all find and connect to “IHG Connect”. (NB - I suspect that all the Apple devices were associating with the hotel’s 5GHz base stations. As you’ll read below, the hotel is running radios on both frequency bands).

Last things first. In a recent post, @kyson-lok suggested adding an option line to the /etc/config/wireless configuration file. I tried doing so, rebooting the router after adding the autoch_skip option to the mt7628 section. That made no difference - Mango would still not find the IHG Connect base stations.

Using the WiFi Explorer utility on my MacBook Pro, I scanned the local WiFi environment. I found that the hotel has a fairly complex WiLAN environment, all running on Cisco-Meraki base stations. See the spectrum scan below.

  • I found a number of 5GHz beacons, broadcasting SSID “IHG Connect”. Most of them are in the UNII-3 band. They are not really relevant here, since the Mango doesn’t support 5 GHz.
  • I found a number of 2.4 GHz beacons, broadcasting SSID “IHG Connect”. The IHG IT department has configured the radios to use channels 1, 6 & 11.
  • I also found an extensive network of 2.4 GHz beacons broadcasting SSID “bartech”. These are used to communicate with the in-room bar fridges. Each fridge is instrumented to communicate with the hotel’s Property Management System when beverages are removed from the fridge, so that the guest’s bill can be charged.

By examining the BSSIDs of the bartech and IHG Connect beacons, it’s apparent that the same Meraki base stations are employed for both WiLAN networks.

For example, on Channel 11, WiFi Explorer shows:
IHG Connect on Meraki:2F:B8:C7
bartech on Meraki:2F:B8:C8

Here’s a screenshot of the Advanced Details pane for the above IHG Connect beacon on Channel 11. Note that the SSID is not hidden, which has been suggested by others as being the root cause of Mango’s difficulties in finding these radios.

Having scoped out the WiFi environment at the hotel, I then SSH’d into the Magno and did an iwinfo scan. Note in particular Cell 12:

root@GL-MT300N-V2:~# iwinfo ra0 scan
Cell 01 - Address: 8A:15:04:9A:37:C8
ESSID: “bartech”
Mode: Master Channel: 1
Signal: 29 Quality: 29/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 02 - Address: 60:5F:8D:F4:AC:93
ESSID: “TWN1”
Mode: Master Channel: 1
Signal: 29 Quality: 29/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

Cell 03 - Address: 02:18:4A:59:F7:B8
ESSID: “bartech”
Mode: Master Channel: 1
Signal: 47 Quality: 47/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 04 - Address: 02:18:4A:5A:1F:D8
ESSID: “bartech”
Mode: Master Channel: 1
Signal: 81 Quality: 81/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 05 - Address: A2:3D:CF:F0:2E:27
ESSID: “ORBI45”
Mode: Master Channel: 4
Signal: unknown Quality: 0/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

Cell 06 - Address: 02:18:4A:5A:35:98
ESSID: “bartech”
Mode: Master Channel: 6
Signal: 23 Quality: 23/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 07 - Address: 84:A1:D1:95:E0:30
ESSID: “BELL452”
Mode: Master Channel: 6
Signal: 15 Quality: 15/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

Cell 08 - Address: 02:18:4A:5A:64:18
ESSID: “bartech”
Mode: Master Channel: 6
Signal: 10 Quality: 10/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 09 - Address: 02:18:4A:59:AF:08
ESSID: “bartech”
Mode: Master Channel: 6
Signal: 23 Quality: 23/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 10 - Address: C8:CD:72:CD:99:CA
ESSID: “BELL310”
Mode: Master Channel: 10
Signal: 5 Quality: 5/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

Cell 11 - Address: 28:C6:8E:B3:AC:D9
ESSID: “twn1”
Mode: Master Channel: 11
Signal: 13 Quality: 13/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

Cell 12 - Address: 02:18:4A:2F:B8:C8
ESSID: “bartech”
Mode: Master Channel: 11
Signal: 44 Quality: 44/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 13 - Address: 02:18:4A:2F:B2:08
ESSID: “bartech”
Mode: Master Channel: 11
Signal: 91 Quality: 91/100
Encryption: WPA2 PSK (TKIP, AES-OCB)
HT Capabilities: UNKNOW

Cell 14 - Address: 34:8A:AE:66:30:EE
ESSID: “BELL484”
Mode: Master Channel: 11
Signal: 7 Quality: 7/100
Encryption: WPA2 PSK (AES-OCB)
HT Capabilities: UNKNOW

It’s apparent from the Cell 12 report that the Mango found the bartech beacon on the Meraki radio at 02:18:4A:2F:B8:C8. But it did not find the IHG Connect beacon 02:18:4A:2F:B8:C7 coming from the same base station on the same channel. The signal level is the same, the SNR is the same. But the Mango scan of ra0 doesn’t find it.

My next troubleshooting step was to do a site survey using the iwpriv apcli0 command:


Note the two highlighted lines. The 6th record from the bottom reveals the bartech radio on channel 11 (Meraki:2F:B8:C8). The 7th record from the bottom is the IHG Connect beacon (Meraki:2F:B8:C7), but the SSID is blank.

I think it’s evident from the WiFi Explorer results that the SSIDs of the IHG Connect radios are not hidden. The reason that the Mango router can’t scan & then associate with them is something else. I suspect it might be related to the fact that the Cisco-Meraki base stations are configured for multi-SSID operation. That might be tripping up the Mango WiFi stack.

1 Like

Thanks for your detailed analysis.

I am curious, both of “IHG Connect” and “bartech” use Cisco-Meraki, and has multi-SSID, why mt300n-v2 only can scan bartech, but not IHG Connect.

The different thing seems only is encryption.

@kyson-lok
You are correct that the bartech SSID is configured with encryption, but the IHG Connect SSID is not. Perhaps that difference is the root cause of failure to scan. If Mango’s WiFi stack is unable to scan networks that are running with no encryption, that should be easy for you to verify.

I’ve done a little more digging, and examined the Advanced Details of the two SSIDs, as captured by the WiFi Explorer utility. There are some other differences evident between the two SSIDs.

The bartech SSID is configured for 802.11b/g/n.
IHG Connect only supports 802.11g/n.

There are differences in the “HT Operation” information element, subset 2 of 3.
The bartech parameter is 0x0004. The IHG Connect parameter is 0x0015.

Here are the details of this information element.
bartech:

IHG Connect:

This is way beyond my pay grade, so I consulted with Ms. Google. She found this article.
https://www.cwnp.com/802-11n-protection-mechanisms-part-1/
I’m guessing that the reason the IHG Connect SSID is announcing 0x0015 for this information element is because it can operate with 802.11n protocol.
Probably has nothing to do with the Mango problem in hotels.

Follow-up to my previous post.
My hypothesis that a network with no encryption can’t be found by Mango network scan doesn’t hold water. Looking back at an earlier post by @sleuth (#33), I see that his MT300N-V2 scanned and found a network with no encryption (Cell 02, SSID = “Free Internet HFC”, Encryption = none). So the fact that there’s no encryption on “IHG Connect” network is not the root cause. Perhaps no encryption in combination with something else (such as 11g/n)?

@kyphos
I have bought the WAP561 device, set the wireless to 11gn mode, and use the MT300N-V2 to scan the wireless SSID, as shown below:


I will continue to look at this problem, specifically caused by that configuration.
Can you send me a copy of the data packet you have fetched?

I didn’t capture any packets while at the IHG hotel. What I did capture was a scan of the entire WiFi environment using the excellent WiFi Explorer utility. The saved scan result file can only be opened by WiFi Explorer, so it won’t be much use to you unless you have the WiFi Explorer program, and a Mac to run it on. (it’s a macOS utility).

I used omnipeek to capture the data in cisco 11gn mode. Indeed, as you analyze it, it may be related to HT Protection and OBSS parameters, but the WAP561 router I bought cannot set these two parameters. I am currently looking for a new device test. If there is a result, I will give it to you.

Do you still go to that hotel? If you still go, we can send you a router of other models, and you can use it to try whether you can find the hotel wifi. We are currently unable to replicate the hotel environment.

No firm plans, but I expect to return to one of the two IHG hotels mentioned in this thread in the fall. The Cisco-Meraki environment at those hotels is quite odd.

Red herring there with OBSS and HT Protection Mode…

Cisco-Meraki stuff is indeed odd… one thing to note with Cisco-Meraki is their rouge AP detection stuff, which can knock the heck out of repeaters, or things that might look like repeaters.

What would be most useful is to use something like Airtool (Mac) or similar and catch the wireless PCAP.

Might be something with the Mediatek drivers - has anyone tried an Atheros based device like AR150 or AR300M?