Fantasmas en la flota: conocer el IMEI no es conocer al equipo
A principios de noviembre, en México, se pone la ofrenda para recibir a los que ya no están. A esas visitas se les espera: tienen su lugar, su foto y su vela.
A una plataforma de rastreo también pueden llegar visitas, pero sin invitación: un equipo que aparece en dos lugares a la vez, una sesión que sigue abierta aunque del otro lado ya no hay nadie, un vehículo que según el inventario ya no debería reportar, y reporta.
Antes de llamar “clon” a cualquiera de ellos, conviene saber qué clase de fantasma es.
El IMEI es una declaración
Cada equipo de rastreo se presenta con un identificador: el IMEI, o el identificador de terminal que defina su protocolo. El servidor lo lee y, desde ese momento, todo lo que llega por esa conexión se le atribuye a ese equipo.
Pero ese identificador lo declara el propio equipo. No es una prueba criptográfica de quién es. Por eso, que dos conexiones se presenten con el mismo IMEI puede significar cosas muy distintas:
- una reconexión legítima;
- una sesión anterior que todavía no se ha cerrado;
- una configuración incorrecta;
- o dos equipos que de verdad comparten identificador.
La plataforma tiene que distinguirlas antes de decidir nada.
No tengo documentado un caso en el que se haya confirmado que dos equipos físicos usaban a la vez el mismo IMEI, y no voy a contar uno. Lo que sí es real es el problema de arquitectura: el servidor puede recibir posiciones perfectamente válidas por una conexión TCP y, aun así, asociarlas a una identidad equivocada.
Tres fantasmas distintos
Conviene separarlos, porque cada uno deja evidencias distintas:
- De sesión: una conexión que el servidor todavía da por vigente, aunque ya no haya comunicación con el equipo. Es la conexión medio abierta de la nota de los sockets.
- De identidad: dos equipos, o dos sesiones, que se presentan con el mismo identificador.
- De inventario: un equipo que sí reporta, pero cuya asociación administrativa con un vehículo está mal o ya no está al día.
El primero es un problema de transporte; el segundo, de identidad; el tercero, administrativo. Tratarlos igual es la manera de acabar acusando de clon a un equipo que sólo perdió la cobertura.
Cinco señales, y lo que ninguna prueba sola
Esto es lo que haría hoy si diseñara el mecanismo desde cero. No puedo afirmar que todos los gateways con los que he trabajado tengan hoy estas políticas.
Inventario. Cada identificador, asociado a un equipo registrado, con su modelo, su estado administrativo y su historial de asignaciones. Así, un equipo dado de baja que sigue reportando se ve como lo que es. Pero el inventario sólo sabe lo que alguien registró.
Sesiones. Un registro de conexiones activas por identificador: la instancia del gateway, el identificador de sesión, la hora de conexión y la última actividad válida. Dos sesiones con el mismo IMEI son una condición de revisión, no la prueba de un clon. Puede ser, simplemente, que la vieja todavía no termine de morir.
Geografía. Posiciones consecutivas, comparadas con sus marcas de tiempo originales. Si el mismo identificador aparece en dos lugares que ningún vehículo puede recorrer en ese tiempo, hay una inconsistencia. Pero antes hay que descartar errores de GPS, datos históricos, relojes mal puestos y mensajes fuera de orden: la hora de llegada no es la hora del dato, como en la posición correcta en el momento equivocado.
Secuencias. En JT808, cada mensaje lleva un número de secuencia que el equipo va incrementando. Un salto, una repetición o un cruce llaman la atención, pero en muchos equipos el contador vuelve a cero en un reinicio, y una retransmisión suele repetir el número.
Correlación. No declararía un IMEI clonado por una sola anomalía. Buscaría que coincidan: sesiones simultáneas, trayectorias incompatibles, contadores que se cruzan, lo que el equipo declara de sí mismo y lo que dice el inventario. La salida debe ser una sospecha fundamentada, no una sentencia.
El detector
Para ver la diferencia hice un detector que corre en el navegador. Lee una jornada sintética de doce identificadores. Detrás de ocho hay un solo aparato:
- un día normal;
- una sesión que queda medio abierta tras dos minutos sin cobertura;
- una posición errónea, a 18 km de donde está el vehículo;
- veinte minutos sin cobertura en carretera, y los datos guardados llegando después, mezclados con los nuevos;
- un reinicio en marcha: el contador vuelve a cero y la hora sale del 1 de enero de 2000 hasta que el GPS fija;
- retransmisiones: cada mensaje tiene un 3 % de probabilidad de llegar dos veces;
- una actualización de firmware, que reinicia el equipo;
- un equipo que el inventario tiene dado de baja.
Detrás de los otros cuatro hay dos aparatos con el mismo identificador: un clon de otro modelo a 145 km; dos del mismo modelo que recorren la misma ciudad; un equipo de reemplazo configurado con el identificador del anterior, mientras el viejo sigue encendido en el almacén; y un segundo aparato idéntico que se enciende cuarenta minutos a 150 metros del primero, los dos estacionados.
Para simplificar, aquí el equipo declara su modelo y su firmware cada vez que inicia sesión. En JT808, según la versión del protocolo, eso viaja en el registro, en la autenticación o en una consulta aparte.
Dos detectores leen lo mismo que vería el gateway: las sesiones, el número de secuencia de cada mensaje, la hora que trae, la posición, y el modelo y firmware que declara el equipo. Nunca saben qué aparato mandó qué.
El ingenuo acusa de clon con una sola anomalía: un login mientras hay otra sesión abierta del mismo identificador, un salto imposible entre dos posiciones seguidas en el orden de llegada, o un número de secuencia que no sigue al anterior.
El correlacionado primero descarta lo que tiene otra explicación. Con lo que queda, habla de identidad duplicada sólo si hay evidencia de dos familias distintas: sesiones y contador (que cuentan como una, porque salen de las mismas conexiones), geografía, e identidad declarada.
Con el gateway configurado para que la sesión nueva cierre a la vieja:
| Ingenuo | Correlacionado | |
|---|---|---|
| Un solo aparato detrás (8): acusados de clon | 6 | 0 |
| Dos aparatos detrás (4): señalados | 4 | 4, uno sólo como “revisar” |
Con el gateway dejando que las dos sesiones convivan, las cifras son las mismas.
Por qué cae el ingenuo
Cada falsa alarma tiene su explicación, y es la que el correlacionado busca primero:
- La sesión medio abierta: el equipo vuelve con una sesión nueva. Si el login nuevo cierra la vieja, es una sola sustitución, no un vaivén. Si las dos conviven, la vieja ya no manda nada, y una sesión callada no es un segundo equipo.
- La posición errónea: es un punto suelto. No forma una trayectoria propia; se aparta y ya.
- Los datos guardados: en la jornada de inicio, las 40 posiciones guardadas se intercalan en el orden de llegada con las nuevas y dibujan 7 saltos imposibles. Ordenadas por la hora del equipo, los saltos desaparecen.
- El reinicio: el contador salta una sola vez, a cero, y la cadena nueva ya no se cruza con la anterior: eso no son dos contadores. Las posiciones con hora de fábrica se quedan fuera del mapa.
- Las retransmisiones: el mismo número con el mismo contenido, segundos después, es el mismo mensaje.
- La actualización: también reinicia el equipo, así que el ingenuo cae por lo mismo. Y el firmware declarado cambia una vez y no vuelve: es una actualización, no dos equipos que se alternan.
El equipo dado de baja, en cambio, el ingenuo ni lo ve: no tiene ninguna anomalía de comunicación. El correlacionado lo marca aparte, como fantasma de inventario, porque no es un problema de identidad.
Lo que el veredicto no dice
“Identidad duplicada” quiere decir que hay dos aparatos con el mismo identificador. No dice si uno es un clon o si alguien configuró mal un equipo: en el caso del reemplazo, la evidencia es la misma que en un clon. Eso se averigua en campo, no en el servidor.
Y el aparato de los cuarenta minutos queda en “revisar”. Las sesiones van y vienen, y hay dos contadores que se cruzan, pero los dos equipos están parados a 150 metros, más cerca que el kilómetro que el detector tolera como ruido del GPS, y con el mismo modelo y el mismo firmware: no hay geografía ni identidad declarada que confirmen. Con esa evidencia, “revisar” es la respuesta honesta. Una persona tiene que mirar.
Lo que este detector no demuestra
Los doce casos los hice a propósito, y los umbrales del detector los escogí viéndolos. Las pruebas del código corren cincuenta jornadas distintas, y en todas el correlacionado da lo esperado; eso es por construcción, no una medida de cómo le iría con datos reales. Con datos reales aparecerían casos que aquí no están: un clon que imita también el contador o el firmware, relojes que se adelantan poco a poco, equipos que pierden mensajes.
Cada caso de control tiene un solo evento, y los umbrales quedan justo encima. Con un solo aparato bastaría poco para llegar a “revisar”: tres reinicios en un día, o, con la política que cierra la sesión vieja, cinco cortes de un minuto en una hora.
También muestra cuánto depende de cada umbral. Con esa misma política, si el vaivén se declara con una sola sustitución de sesión por hora, la sesión medio abierta, el reinicio y la actualización pasan a “revisar”. Si la ventana de retransmisiones se pone en cero, las retransmisiones parecen un segundo contador.
Para ver cada caso por dentro, con su mapa, sus sesiones, su contador y la línea de tiempo de las evidencias, está el detector de fantasmas: corre en el navegador y no envía nada. Se pueden mover los umbrales y la política del gateway, y ver qué casos cambian de veredicto.
Ninguna anomalía basta sola
En una plataforma de rastreo, conocer el IMEI no significa necesariamente conocer al dispositivo. Por eso hay que distinguir entre identificación, sesión, ubicación e inventario.
Un salto imposible en el mapa es una anomalía. Dos conexiones con el mismo IMEI son una anomalía. Una secuencia inesperada también puede serlo. Pero ninguna demuestra, por sí sola, que existe un dispositivo clonado.
Un buen detector de fantasmas no debe encontrar clones donde solamente hay errores de comunicación. Debe reunir evidencia suficiente para distinguir una identidad duplicada de una sesión que todavía no termina de morir.
Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años haciendo que sistemas distintos funcionen juntos en condiciones reales: del sensor, el vehículo o la transacción al backend, los datos, la seguridad y la operación. Hoy, cada vez más, IA en el borde. Acepto proyectos por hora o por entrega: israel0negrete@gmail.com.