Hello,

When using MT Hotspot, as soon as an iPhone goes to sleep (about 10 seconds after locking) iMessages and notifications fail. Once the screen is touched and phone wakes, notifications and messages arrive. The phone is not logged-out during the time when notifications fail.

Using hotspot - I ping the phone, I can see packets timeout once it sleeps, I send a message, it stays asleep, all messages and notifications fail.

Bypassing hotspot - I ping the phone, I can see packets timeout once it sleeps, I send a message, it wakes, pings resume, messages and notifications arrive.

All logical steps were taken for testing, fw's updated, phone network settings reset etc. Also tested with other iPhone with same result.

Can anyone help? Happy holidays!

You could add TCP port 5223 to the walled garden configuration, as that's the port used by the push notification system.

https://developer.apple.com/library/con ... CH1-TNTAG2

The above link is more focused on app development, but I would think that a little more digging around in there might reveal the best host names to use if you want to use IP-based walled garden rules to allow all communications to the push server(s) regardless of port number. I'd probably opt for this method as opposed to just opening TCP/5223 to the whole internet.

Users are not logged out of hotspot when this problem occurs. Keep-alives also fail..

Problem also occurs if phone is added to bypass list and can browse fine without traditional authentication steps.

Cheers man

Users are not logged out of hotspot when this problem occurs. Keep-alives also fail..

Problem also occurs if phone is added to bypass list and can browse fine without traditional authentication steps.

That's not the impression I got reading your original post:

Bypassing hotspot - I ping the phone, I can see packets timeout once it sleeps, I send a message, it wakes, pings resume, messages and notifications arrive.

How do you bypass the hotspot in this scenario?

Back to your more recent post....
When adding the phone to the bypass list fails, is the phone added to the bypass list by IP address or by MAC address? Does the phone still appear in the hotspot > hosts list in the same manner? Has its DHCP lease expired? (I'm assuming not since you're testing this, you're probably forcing it to go to sleep almost immediately, but I'm just trying to think of stuff to look at here)
Does the phone answer ARP requests when it is asleep? (I would assume that it must or else how would it ever work?)

Essentially, I've found that even hotspot bypass is not 100% in some cases. We used to have these Dell switches behind hotspots, and no amount of bypassing would ever make them reachable via their assigned NAT pinholes, once the hotspot entry disappeared. If you telnet into the switch from some other device behind the hostpost, and from the switch you would ping the default GW, then suddenly the device is reachable via the dstnat pinhole again. I was never able to figure out exactly what it was about the way these Dell switches behaved that caused this. Every other device we ever put behind a hotspot was always reachable via dstnat + hotspot bypass, even if the device's dynamic entry in the hosts table had timed out.

I would think that whitelisting the push servers in the walled garden may circumvent this enough to prevent the hotspot from interfering with it, even if the bypass doesn't fix it.

I apologise for not being clear in my original post - when I said "bypass" the hotspot, I actually meant not employing the hotspot at all.

The test was run using MT router with UBNT UAP. Two vlans on router associate with two ssids on AP. First vlan interface is for hotspot, second vlan is basic /24. I tested in this fashion to be sure it was the hotspot causing issues not the hardware. Both vlans work fine for browsing etc. Hotspot allows 5 devices to share.

During my attempts to remedy the problem when using the hotspot I did use the bypass feature by adding the phone's mac address, did not try IP.

Phone stays in host list, active list and dhcp is set to 24h. It never drops from auth during tests, and logging back into hotspot is never required once phone wakes. Idle and keep-alive both set to 45min. A shorter keep-alive will log phone out as soon as pings start timing out.

After locking it takes around 10 seconds for pings to start timing out. Before this 10 seconds is up all notifications arrive OK, but the second the pings start timing out, notifications will fail. A single touch on screen (iphonex) wakes the phone up enough for pings to resume, followed by all notifications immediately arriving.

When the hotspot feature is not in use (using the other vlan), the phone somehow wakes itself to receive the notifications, even if pings have been timing out for half an hour - I do not understand how this is working. Cellular data is always off during all tests.

I have not tested arp requests but as you say, it must, or wouldn't work once wake.

Many hotspot users are international students and often run out of cellular data, so when their phones lock they do not receive messages, emails or notifications etc.

I will try walled-garden as you suggest. I don't see how this would help, but if you think it may, I will try for sure.

Thanks for your time on this. I am at a loss as to why this is happening and how to fix it for my customers.

Personally, I'm not a fan of hotspots. They cause all sorts of things like this to happen. The biggest issue would probably be the increasing use of SSL everywhere, because transparent redirection of SSL causes warnings to pop up on the customers' screens if the devices aren't silently testing for hotspot + popping up a browser when detected.

One problem that plagued us for a while was CRL access - we still have to keep a hostname->IP dynamic walled garden entry for our certificate provider's CRL so that clients can verify our hotspot's certificate is not revoked. When that isn't open, strange things can happen.

My point is that something's being blocked by hotspot, and the easiest first thing to try is to just allow push server traffic. If this fixes it, then you can look into refining the solution. Otherwise, I'd suggest that you do some packet sniffing and analysis in Wireshark to see what's different about a sleeping / active phone. Also - if you DO get to the bottom of it in that activity, please post the results here so that the community may benefit.

If I had it to do over, I'd have two SSIDs: An open one with a hotspot network for signup only, where users can create uid/password for use on a WPA-Enterprise SSID, which is the one that actually has Internet access.

Ok I have an update. I believe the problem not to be caused by MT Hotspot.

Issue now fixed by the following simple steps.

- 'reset network settings' on iPhone
- connect to hotspot network FIRST and log into hotspot.

This resolved the issue. I know it seems simple, and it is. Previously I was connecting to the non-hotspot SSID first, testing notifications etc, then connecting to the hotspot nw where the issue would consistently happen. However, on connecting to the hotspot nw first after a reset, the issue does not arise.

I am putting this down to a bug in phones fw as I cannot see how this could be useful.

Testing - I reset network settings in phone, once it rebooted I connected to hotspot and tested notifications once pings had timed out, this worked. I then disabled cellular data and redid tests, pings would timeout, once notification sent phone would wake and pings would recommence.


Thank you Zerobyte for your suggestions.

ok thanx for the update.
BEWARE. for iphone users 'reset network settings' deletes all WIFI PASSWORDS that are saved in the phone.