hashrack wrote
There must be a URL that should work, regardless of what device is used.
Just tried it with an old laptop and the voucher portal: every site URL (even a non-existing one) causes the EAP to redirect the browser to this portal URL (placeholders used for sensitive MAC addresses):
http://192.168.5.15:8088/portal/entry?cid=00:17:XX:XX:XX:XX&ap=AC:84:YY:YY:YY:YY&ssid=WLAN-name&t=1571447614&rid=0&u=some-site.com%2F
where:
192.168.5.15 is the controller's IP
:8088 is the port number for Omada software controller / replace with :80 for OC200
cid is the client device's ID (MAC address)
ap is the access point's MAC address
rid is the radio ID (0 = 2.4 GHz, 1 = 5 GHz)
t is the current time
u is the URL which triggers the redirect
Try this:
- check that the smartphone receives a valid IP via DHCP when associating with the WLAN
- ping the EAP from the phone (or enter the EAP's IP into a web browser's address field) to test basic connectivity
- make sure to have mobile data turned off ¹
- make sure phone doesn't switch to another nearby WLAN to which the phone was associated once before ¹
- then enter an URL (http://some-site.com/)
- if this doesn't work, try the URL as shown above, make sure to insert actual MAC addresses
- if this fails too, there happens some other weirdness with the phone
¹ Some »smart« phones have kind of a (not so smart or too smart, however you view this) failover mechanism: if they don't get Internet access instantly when associated to a WLAN, they automatically switch to another type of connection which is known to have worked before such as a mobile data link.