Captive Portal Woes (Samsung Devices)

[cta102]

Hi Folks,

we have been suffering a bit with a subset of Samsung phones which simply shows the against the Wi-Fi No Internet connection. These seem to be recent phones a Note 9 and an A8 (or A9 the remote engineer was vague) running Android 8.1.0 from the brief test we were able to carry out.) 

The devices do receive an IP address and are pingable so we know it's not a regular connectivity issue.

However the Splash page is never displayed and phones devices which had authenticated some time before never pick up their prior authentication and therefore they are never granted access to the guest network.

I know in the past some versions of Android required the ability to access the URL http://connectivitycheck.gstatic.com/generate_204 before they would play nicely with some Captive Portals/Walled Gardens

Has anybody been through this already as this concerns a customer with a large number of outlets I can't simply bung the above URL into their Walled Garden range and see what happens, plus there is a slight geographic separation so I can't simply call in and do my own tests.

Logs show no issues

Also I was wondering if Samsung use their own check (can find no online reference) as every other android device seems to be fine.

The Wi-Fi authentication behaves for everybody else:

Bridge mode
Guest SSID has the following :

Dual band with Band steering

12MB minimum bit rate

DFS channels permitted

Client Balancing enabled

[jdsilva]

Hey @cta102 . I don't have a solution to your problem, but I have been doing a lot of work in this area recently so I thought I'd chime in with what I know.

The generate_204 url should be used to detect the presence of Internet. If the device receives anything other than an HTTP 204 (including nothing at all) when accessing that URL it should throw up the "sign in to this network" notification. But, having said that, every Android vendor seems to mess with this mechanism in their own way. I have LG, Motorola and Google devices in my lab and all behave slightly differently when faced with a captive portal. Very frustrating. 

If you add the generate_204 url to the walled garden it will have the opposite effect from what you want. You don't want this URL reachable so the device realizes it's access to the Internet is crippled.

Other than that, this really is kind of a mess in the industry. I really wish there was a standard captive portal detection process that all vendors used. Right now it's anyone's guess if it'll kick in or not on any given device. 

IOS devices also use their own method, and also give varying results. 

[cta102]

Funny enough I had realised the 204 URL thing soon after posting but it didn't seem to be worth editing the posting as others may get benefit from my original mistake (well that's my story anyway)

Stuff like this is the reason that I switch from Samsung to Google Nexus and Pixel products for personal use, Certain Samsung models simply cannot connect to our Aruba corporate Wi-Fi network and it's too annoying.

[PhilipDAth]

Samsung havent started using the mac randomisation privacy feature (pointless) have they? They might upset it.

https://source.android.com/devices/tech/connect/wifi-mac-randomization

[cta102]

They don't appear to as the mac address remained consistent, the device did receive a valid IP address and could be pinged from any Meraki device within the network.

It simply did not receive the splash page (WiFiSpark said they did see the request) but the handset simply sat there and said it didn't have internet connectivity.

Also requested the 'engineer' to try the usual browse to a http: site which sometimes kicks the splashpage on Aruba setups into life