Bitácora de diagnóstico — consumo de GetUserToken (Recurso Confiable)

Prestador GPS: GpsNetic / GpsFollowme (proveedor 10653) · Sesión de diagnóstico: 25-ago-2026, 11:00–12:10 hrs CDMX · IP de origen en todas las pruebas: 207.244.239.84 · Complemento del "Expediente técnico" (resumen ejecutivo)
📋 Qué es este documento: el registro paso a paso de TODO lo que se probó, con el comando exacto y la salida íntegra de cada prueba, en orden cronológico. Cualquier ingeniero puede re-ejecutar cada paso con copiar/pegar y validar los resultados. Las contraseñas aparecen enmascaradas (NSTT_•••••••$2 = la compartida el 25-ago 11:02, wNQx_•••••••$9 = la generada el 25-ago 11:36); el equipo de RC las conoce completas.
1Punto de partida: credenciales aplicadas y verificadas carácter por carácter
Objetivo
Descartar errores de copiado (espacios, tabs, caracteres invisibles, homóglifos Unicode) en las credenciales recibidas por WhatsApp.
Método
Auditoría de código de carácter (charCode) de cada byte de usuario y contraseña tal como quedaron cargados.
Salida íntegra
WM_USER: 16 caracteres · codigos [119,109,95,49,48,54,53,51,95,102,111,108,111,119,109,101]
         = w m _ 1 0 6 5 3 _ f o l o w m e   ← una sola L, tal como llegó en el JSON
         espacios/tabs/invisibles/no-ascii: NINGUNO ✓
WM_PASS: 14 caracteres · todos ASCII imprimibles (incluye _ = cod.95 y $ = cod.36)
         espacios/tabs/invisibles/no-ascii: NINGUNO ✓
✔ Las credenciales están cargadas byte por byte exactas a lo compartido. No hay carácter oculto de nuestro lado.
2Verificación del endpoint contra el WSDL público del servicio
Objetivo
Confirmar que la URL y el SOAPAction que usamos son exactamente los que el propio servicio declara.
Comando
curl -s 'http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc?wsdl'
Salida íntegra (fragmento relevante)
<wsdl:binding name="BasicHttpBinding_IRCService" type="tns:IRCService">
<soap:operation soapAction="http://tempuri.org/IRCService/GetUserToken" style="document"/>
<soap:operation soapAction="http://tempuri.org/IRCService/GPSAssetTracking" style="document"/>
<wsdl:port name="BasicHttpBinding_IRCService" binding="tns:BasicHttpBinding_IRCService">
<soap:address location="http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc"/>
✔ Endpoint y SOAPAction idénticos a los usados. Coincide además con la pág. 3 del Documento de Integración.
3Verificación de red: DNS, proxies y conexión
Objetivo
Descartar que estemos llegando a un servidor distinto/viejo (caché DNS) o a través de intermediarios.
Comandos y salidas íntegras
$ dig +short gps.rcontrol.com.mx A            → 136.119.36.152   (resolver local)
$ dig +short @8.8.8.8 gps.rcontrol.com.mx A   → 136.119.36.152   (Google)
$ dig +short @1.1.1.1 gps.rcontrol.com.mx A   → 136.119.36.152   (Cloudflare)
$ env | grep -i proxy                          → (vacío: sin proxies configurados)
Conexión y cabeceras completas de una petición real
* Connected to gps.rcontrol.com.mx (136.119.36.152) port 80
> POST /Tracking/wcf/RCService.svc HTTP/1.1
> Host: gps.rcontrol.com.mx
> User-Agent: curl/8.5.0
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://tempuri.org/IRCService/GetUserToken"
> Content-Length: 395
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/xml; charset=utf-8
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-XSS-Protection / X-Frame-Options / CSP ... (cabeceras de la aplicación WCF, sin CDN/WAF intermedio)
< Date: Tue, 25 Aug 2026 18:08:46 GMT
✔ Tres resolvers independientes coinciden en la IP. Conexión directa, sin proxies, respuesta directa de la aplicación.
4Réplica byte por byte del envelope de SoapUI del equipo de RC
Objetivo
Eliminar cualquier diferencia de formato: se tomó el XML compartido por el equipo de RC (con todo y comentarios <!--Optional:--> de SoapUI) y se envió idéntico, sin reformatear.
Comando
curl -s http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc \
 -H "Content-Type: text/xml; charset=utf-8" \
 -H 'SOAPAction: "http://tempuri.org/IRCService/GetUserToken"' \
 --data-binary @envelope_soapui_rc.xml     # el archivo tal cual lo compartió RC
Variantes probadas con el mismo envelope (todas con idéntico resultado)
· SOAPAction sin comillas          → mismo error
· SOAPAction con comillas (estándar SoapUI) → mismo error
· Content-Type "text/xml;charset=UTF-8" (formato SoapUI, sin espacio) → mismo error
· User-Agent "Apache-HttpClient/4.5.5 (Java/12.0.1)" + Accept-Encoding gzip,deflate
  + Connection Keep-Alive (firma completa de SoapUI)  → mismo error
✖ El mismo XML que en la red de RC devuelve token, enviado desde internet devuelve USERUNK. El formato queda descartado como causa.
5Prueba de la URL https (pág. 3 del documento)
Objetivo
La documentación lista la URL con https; verificar ese camino.
Comandos y salidas
$ curl -sk -X POST https://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc (con envelope)
→ HTTP 404   (el binding del servicio no está publicado en 443)

$ curl -sk 'https://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc?wsdl' | grep address
→ address location="http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc"
  (el propio WSDL servido por https declara que la dirección real del servicio es la http)
✔ Confirmado que el consumo debe ser por http — el binding BasicHttpBinding solo escucha ahí. No es la causa.
6Matriz completa: 2 usuarios × 2 contraseñas
Objetivo
Cubrir las cuatro combinaciones posibles de las credenciales compartidas (correo 21-ago, WhatsApp 11:02 y JSON 11:36 del 25-ago), incluida la variante de escritura del usuario con doble L.
Resultado íntegro (25-ago-2026, 11:45–11:50 CDMX)
userId enviadopasswordkeycodelayer
wm_10653_followme (doble L)NSTT_•••••••$2CGI:USERUNK4020CGI
wm_10653_followme (doble L)wNQx_•••••••$9CGI:USERUNK4020CGI
wm_10653_folowme (una L)NSTT_•••••••$2SQL:USERUNK2004SQL
wm_10653_folowme (una L)wNQx_•••••••$9CGI:USERUNK4020CGI
🔍 El hallazgo central: solo la combinación wm_10653_folowme (una L) + contraseña NSTT_••• cambia el error de la capa CGI (rechazo en la entrada) a la capa SQL (el servicio SÍ ejecutó la búsqueda del usuario en base de datos). Esa es la forma de usuario que el sistema reconoce — y aún así la base responde "no encontrado".
7La respuesta clave, íntegra y sin editar
Petición (25-ago-2026 12:00 CDMX, desde 207.244.239.84)
POST http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/IRCService/GetUserToken"

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
 <soapenv:Header/><soapenv:Body><tem:GetUserToken>
  <tem:userId>wm_10653_folowme</tem:userId>
  <tem:password>NSTT_•••••••$2</tem:password>
 </tem:GetUserToken></soapenv:Body></soapenv:Envelope>
Respuesta íntegra del servicio
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>
<GetUserTokenResponse xmlns="http://tempuri.org/">
<GetUserTokenResult xmlns:a="http://schemas.datacontract.org/2004/07/IronTracking" ...>
<a:exception xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
  key          = SQL:USERUNK
  code         = 2004
  severity     = User
  layer        = SQL
  message      = Autentificación incorrecta (Usuario, Contraseña o Token).
  message_args = wm_10653_folowme   ← el servicio devuelve el usuario TAL CUAL le llegó: íntegro
</a:exception>
<a:token i:nil="true"/>
</GetUserTokenResult></GetUserTokenResponse></s:Body></s:Envelope>
Prueba de integridad de extremo a extremo: message_args demuestra que el usuario llegó al servicio sin ninguna alteración. La petición es correcta; la búsqueda en base no lo encuentra.
8Lectura contra la documentación oficial de la interfaz
ReferenciaLo que diceCómo aplica
Pág. 13 — tabla de erroresSQL:USERUNK = "Usuario 'usuario' no encontrado" (clave distinta a "Contraseña y/o usuarios incorrectos")Nuestro caso exacto: el servicio buscó wm_10653_folowme y no lo halló
Pág. 6 — ejemplo de credenciales incorrectasEstructura de respuesta con message_args devolviendo el usuario consultadoCoincide con la respuesta recibida — comportamiento estándar del servicio
Pág. 3 — URL del serviciogps.rcontrol.com.mx/Tracking/wcf/RCService.svcLa usada en todas las pruebas (por http, según el binding real del WSDL)

Conclusión y petición concreta

La petición del prestador llega íntegra hasta la capa de datos del servicio (demostrado por message_args). El servicio busca el usuario wm_10653_folowme y responde SQL:USERUNK — "usuario no encontrado" según la propia tabla de errores de la documentación. Del lado del prestador no queda ninguna variable por revisar: endpoint, DNS, red, formato, protocolo y credenciales fueron auditados y se documentan arriba con comandos reproducibles.

Petición: revisar por qué la base de datos que consulta el servicio público no encuentra al usuario wm_10653_folowme — posible alta sin activar/sincronizar en ese ambiente, o restricción por origen. Los intentos del prestador pueden ubicarse en logs de RC: 25-ago-2026, 11:05–12:10 hrs CDMX, IP 207.244.239.84.

Para re-ejecutar la prueba principal (copiar y pegar)
curl -s http://gps.rcontrol.com.mx/Tracking/wcf/RCService.svc \
 -H "Content-Type: text/xml; charset=utf-8" \
 -H 'SOAPAction: "http://tempuri.org/IRCService/GetUserToken"' \
 --data '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/"><soapenv:Header/><soapenv:Body><tem:GetUserToken><tem:userId>wm_10653_folowme</tem:userId><tem:password>LA_CONTRASEÑA</tem:password></tem:GetUserToken></soapenv:Body></soapenv:Envelope>'
💡 Sugerencia: correr este mismo comando una vez dentro de la red de RC y una vez desde internet (hotspot de celular). Si el resultado difiere, la variable es el origen; si coincide en error, la variable es el estado del usuario en base.