Comportamiento notificaciones automáticas
PUSH NOTIFICATIONS
A continuación se detalla el análisis de ingeniería realizado para estudiar la causa por la cual “no se muestra la notificación al usuario sobre la necesidad de una acción en la red wifi, luego de la finalización de la sesión”.
Protocolo de prueba
Se realizan pruebas cuya finalidad es: “Entender el comportamiento de las notificaciones al usuario sobre finalización de sesión en portal cautivo”. Para esto se fijan 7 dispositivos test así:
Dev1: Macbook pro 2017. Big sur
Dev2: Redmi note 8, Android 9
Dev3: Samsung S3, Android 7.1
Dev4: IPhone 6, iOS 12.4.5
Dev5: Samsung M12, Android 11
Dev6: Xiaomi Redmi Note 9S, Android 11
Dev7: Laptop HP, Windows 11
Como variables controlables del entorno de pruebas se fijan:
Origen del portal cautivo web (servidor web interno meraki, servidor web externo Datawifi)
Autenticación (interna meraki, externa RADIUS datawifi)
Prueba 1
Portal cautivo Meraki
Autenticación interna de meraki
SSID: #Pruebas_Click
Todos los 7 dispositivos autenticados exitosamente:
Se esperan 30 min a finalización de tiempo de sesión de Meraki.
Los siguientes dispositivos presentaron eventos de notificaciones de portal cautivo después de la finalización de la sesión:
Dev3: Samsung S3, Android 7.1. Aproximadamente 5 minutos después de finalizar la sesión.
Dev5: Samsung M12, Android 11. Aproximadamente 5 minutos después de finalizar la sesión.
Dev7: Laptop HP, Windows 11. Pocos segundos después de finalizar la sesión.
Los siguientes dispositivos no mostraron notificación alguna de portal cautivo después de la finalización de la sesión:
Dev1: Macbook pro 2017. Big sur
Dev2: Redmi note 8, Android 9
Dev4: IPhone 6, iOS 12.4.5
Dev7: Laptop HP, Windows 11
Conclusión previa de prueba:
El comportamiento de las notificaciones de usuario de presencia de portal cautivo, luego de finalización de la sesión, no tiene características comunes que se puedan estandarizar. Bajo las mismas condiciones de red, y en un escenario 100% controlado por Meraki, el comportamiento de dichas notificaciones no es estándar y varía de acuerdo a cada dispositivo.
Prueba 2
Portal cautivo Datawifi
Autenticación externa Datawifi
SSID: #Pruebas_Test
Attributos RADIUS usados:
"groupname" "attribute" "op" "value"
"test_app@Datawifi" "Session-Timeout" "=" "180"
"test_app@Datawifi" "Maximum-Data-Rate-Downstream" "=" "10000000"
"test_app@Datawifi" "Maximum-Data-Rate-Upstream" "=" "10000000"
Registros Radius Accept Satisfactorios. Copia de paquetes Start y Stop de RADIUS:
Los siguientes dispositivos presentaron eventos de notificaciones de portal cautivo después de la finalización de la sesión:
Dev3: Samsung S3, Android 7.1. Aproximadamente 5 minutos después de finalizar la sesión.
Dev5: Samsung M12, Android 11. Aproximadamente 5 minutos después de finalizar la sesión.
Dev7: Laptop HP, Windows 11. Pocos segundos después de finalizar la sesión.
Los siguientes dispositivos no mostraron notificación alguna de portal cautivo después de la finalización de la sesión:
Dev1: Macbook pro 2017. Big sur
Dev2: Redmi note 8, Android 9
Dev4: IPhone 6, iOS 12.4.5
Dev7: Laptop HP, Windows 11
Conclusión previa de prueba:
El comportamiento de las notificaciones de usuario de presencia de portal cautivo es igual al de los escenarios de prueba 1, luego de finalización de la sesión no tiene características comunes que se puedan estandarizar. Bajo las mismas condiciones de red, y en un escenario 100% controlado por Meraki, el comportamiento de dichas notificaciones no es estándar y varía de acuerdo a cada dispositivo.
Adicionalmente, se verifica que el servidor Web donde se presenta el portal cautivo, y el servidor de autenticación donde se validan las credenciales, no tienen incidencia en la presentación de las mencionadas notificaciones.
Prueba 3
Portal cautivo Mikrotik
Autenticación interna mikrotik
SSID: ROUTEROS_DW
Resultados
Evidencia VIDEO 1 https://youtu.be/fegWcOwh3GI
Evidencia VIDEO 2 https://youtu.be/W4rU0SYTC3Q
Los siguientes dispositivos presentaron eventos de notificaciones de portal cautivo después de la finalización de la sesión:
Dev3: Samsung S3, Android 7.1. Aproximadamente 5 minutos después de finalizar la sesión.
Dev5: Samsung M12, Android 11. Aproximadamente 5 minutos después de finalizar la sesión.
Dev7: Laptop HP, Windows 11. Pocos segundos después de finalizar la sesión.
Los siguientes dispositivos no mostraron notificación alguna de portal cautivo después de la finalización de la sesión:
Dev1: Macbook pro 2017. Big sur
Dev2: Redmi note 8, Android 9
Dev4: IPhone 6, iOS 12.4.5
Dev7: Laptop HP, Windows 11
Conclusión previa de prueba:
El comportamiento de las notificaciones de usuario de presencia de portal cautivo, es similar a los escenarios 1 y 2, luego de finalización de la sesión no tiene características comunes que se puedan estandarizar. Bajo las mismas condiciones de red, y en un escenario 100% controlado por Mikrotik, el comportamiento de dichas notificaciones no es estándar y varía de acuerdo a cada dispositivo.
Se evidencia nuevamente que el servidor Web donde se presenta el portal cautivo, y el servidor de autenticación donde se validan las credenciales, no tienen incidencia en la presentación de las mencionadas notificaciones.
DISCUSIÓN
La razón del comportamiento similar de las 3 pruebas lo explica la Wireless broadband Alliance:
The connection process for the CPMB (Captive Portal Mini-Browser) usually involves the following steps:
Network/Access Point Association
Checking connectivity state (detection of Captive Network)
Pop-up of a notification (in some cases)
Waiting for device activation (if device is in a blocked state)
Opening CPMB or waiting for the activation of the notification
Checking current connectivity state based on user’s action while CPMB is open
Closing CPMB after authentication process is completed (automatically or manually)
Figura. Flujo de presentación de notificaciones de portal cautivo.
En donde la notificación Pop-up depende directamente del estado de verificación de conectividad.
La Verificación de conectividad (Checking connectivity state) la realiza autónomamente el sistema operativo del dispositivo cliente, de acuerdo a sus lógicas internas que varían en tiempos y procedimientos de control exclusivo del sistema operativo cliente. Las URL de verificación de conectividad por medio de las peticiones HTTP documentadas por la Wireless Broadband Alliance:
List of captive portal check URLs
Apple iOS
captive.apple.com
apple.com
Apple MacOS
captive.apple.com
Google Android
clients3.google.com
clients4.google.com
android.clients.google.com
connectivitycheck.android.com
connectivitycheck.gstatic.com
Samsung Android
d2uzsrnmmf6tds.cloudfront.net
HTC Android
clients3.google.com
Windows
msftncsi.com
Estas URL son usadas en a verificación de conectividad de la siguiente forma según a WBA (caso Chrome OS):
Connection manager for Chrome OS attempts to retrieve the web page http://clients3.google.com/generate_204. This well known URL is known to return an empty page with an HTTP status 204. If for any reason the web page is not returned, or an HTTP response other than 204 is received, then shill marks the service as being in the portal state.
La lógica de ejecución de esa verificación, cantidad y frecuencia de requests, son autonomía del sistema operativo Cliente, no controlables desde elementos externos.
CONCLUSIONES
Dado a lo argumentado en la discusión, y apoyado en los resultados parciales de cada prueba, es posible evidenciar completamente que:
La función de notificación Pop-up sobre estado de portal cautivo, en cualquiera de las fases de uso de la tecnología de portales cautivos, depende exclusivamente de 1) la ejecución continua de verificación de conectividad y 2) las lógicas internas del sistema operativo cliente.
Para que las verificaciones de conectividad sean exitosas, se requiere que ninguna de las URL informadas en este documento, hagan parte del Walled Garden de los Access Points.
La función de notificación Pop-up sobre estado de portal cautivo, no depende de ninguna medida de la presentación web del portal cautivo, que en el flujo documentado por la WBA se ejecutan en una fase posterior llamada “Opening CPMB or waiting for the activation of the notification”.
La función de notificación Pop-up sobre estado de portal cautivo, no depende de ninguna medida de la autenticación del usuario, ni la ubicación de su servidor de autenticación (local o remoto), que en el flujo documentado por la WBA se ejecutan en una fase posterior llamada “Checking current connectivity state based on user’s action while CPMB is open”. Los atributos RADIUS en particular no afectan de ninguna forma la verificación de conectividad (Checking connectivity state), ni la lógica de funcionamiento interna de los sistemas operativos de cliente, que son los predecesores de las notificaciones Pop-up sobre estado de portal cautivo en cualquiera de sus fases.
No hay medidas que puedan tomarse desde el servidor Web o servidor RADIUS de Datawifi o cualquier otro vendor, que permitan modificar las lógicas de funcionamiento de las notificaciones Pop-up sobre estado de portal cautivo luego de finalización de una sesión previa.
ANOTACIONES ADICIONALES
Se pudo evidenciar que el comportamiento de las notificaciones Pop-up sobre estado de portal cautivo luego de finalización del tiempo de sesión, no tiene un estándar completamente comprensible, ya que se pudo notar que en situaciones donde algunos sistemas operativos cliente se encuentran sin usar aplicativos que demanden funciones de red, la generación de la notificación pop-up toma mucho más tiempo (hasta 15 minutos). Los videos relacionados reflejan las situaciones que más comunes que pudimos evidenciar, aunque por el comportamiento no controlable de esta situación es difícil siquiera replicar las mismas notificaciones, en el mismo escenario.
También se evidenció algunos casos muy difíciles de replicar, como dispositivos que usualmente no muestran notificaciones pop-up, pero que en momentos de usar aplicaciones, disparaban el CPMB llamando a portal cautivo.
Por lo anterior, sugerimos que para profundizar en análisis posteriores, se involucre a los equipos de fábrica de las soluciones de red y también de los dispositivos móviles, quienes podrán hablar con más propiedad sobre las lógicas internas de estos procesos en los sistemas operativos clientes.
Related Articles
Comportamiento del portal cautivo
A continuacion se presenta el proceso funcional del Portal cautivo: "Wireless-broadband-alliance. Captive network portal behavior. Recuperado de https://captivebehavior.wballiance.com/" Las redes Wi-Fi públicas que ofrecen acceso temporal a Internet ...Notificaciones push
Es un informe que muestra cuantos mensajes fueron enviados por medio de la función PUSH y si reaccionaron a él haciendo clic sobre este. 1. Al informe se llega a través de la siguiente ruta ANALÍTICA > AVANZADAS > INFORME NOTIFICACIONES PUSH 2. Al ...Notificaciones web
Definición Este módulo sirve para enviar una notificación push web al usuario en la cual se invitara a acceder a una página web, una aplicación, a ver un video corporativo o informativo o una red social, o cualquier tipo de información que desee ...Configuración pruebas de velocidad automatizadas
En este modulo permite la visualización de las pruebas automáticas y la configuración de pruebas de velocidad programadas. 6. Clic la pestaña de “Pruebas de velocidad” 7. Clic en la fecha deseada y se desplegarán las pruebas que se han realizado ...Compatibilidad de Hardware Datawifi Flow Metrcis.
MARCAS HOMOLOGADAS En este apartado encontrará el conjunto de equipos homologados para nuestro producto de Smart Location con los cuales tendrá un seguimiento del comportamiento de sus usuarios, con georreferenciación mediante wifi, generado mapas de ...