Traducido del English por IA ·
Un caso algo raro. Estamos desplegando sensores de vibración en nuestra planta del Reino Unido. Nuestra planta hermana en EE. UU. ya usa los mismos sensores en Hermetry, así que su responsable de controles me envió su proyecto de firmware y yo solo cambié los tokens por los de nuestros dispositivos.Todos los dispositivos fallan:
[mqtt] connecting to mqtt.<their host>:8883 ...
[mqtt] TLS ok, sending CONNECT
[mqtt] CONNACK rc=4 (bad user name or password)
[mqtt] backing off 300 sLo que he comprobado:
- Tokens copiados directamente del cajón Create device, revisados tres veces
- Nombre de usuario = token, contraseña vacía, según la documentación
- La pestaña Log del dispositivo en nuestra organización no muestra nada, ningún inicio de sesión rechazado
- Puerto 8883 abierto en salida, el handshake TLS se completa sin problemas
Nuestra organización de Hermetry la creó nuestro departamento de TI en enero. La suya es más antigua. ¿Hay algo específico de cada organización que me esté perdiendo? Prefiero no volver a llamar a su responsable de controles, ya ha pasado una tarde con esto.
Bit of a weird one. We’re rolling out vibration sensors at our UK plant. Our sister plant in the US already runs the same sensors on Hermetry, so their controls guy sent me his firmware project and I just changed the tokens to the ones from our devices.
Every single device fails:
[mqtt] connecting to mqtt.<their host>:8883 ...
[mqtt] TLS ok, sending CONNECT
[mqtt] CONNACK rc=4 (bad user name or password)
[mqtt] backing off 300 sWhat I’ve checked:
- tokens copied straight from the Create device drawer, triple-checked
- username = token, password empty, as per the docs
- the device Log tab in our org shows nothing at all, no refused logins
- port 8883 open outbound, TLS handshake clearly succeeds
Our Hermetry organisation was created by our IT in January. Theirs is older. Is there some per-organisation thing I’m missing? I’d rather not call their controls guy again, he’s already spent an afternoon on this.
Traducido del English por IA ·
CONNACK 4 con la pestaña Log de tu propia organización vacía es una pista importante. Tu organización nunca vio esos inicios de sesión.
CONNACK 4 with nothing in your own Log tab is a big hint. Your org never saw those logins.
Traducido del English por IA ·
¿Quizás se rotaron los tokens? Nos pasó una vez, después de que alguien pulsó Rotate por error.
Maybe the tokens got rotated? We had that once after someone hit Rotate by mistake.
Traducido del English por IA ·
Los tokens son totalmente nuevos, nadie los ha rotado. Tyler, ¿qué quieres decir con que nunca los viste?
Tokens are brand new, nobody rotated anything. Tyler, what do you mean never saw them?
Traducido del English por IA ·
Mira el host en la línea de tu log. Ese es el host del broker del firmware de EE. UU.Hermetry funciona con despliegues independientes por región (EU, US, TR) y cada organización vive en una única región de origen. Los dispositivos tienen que conectarse al host de dispositivos de la región de su propia organización, el que aparece en la tarjeta Connection details de cada dispositivo. Apuesto a que la organización de la planta de EE. UU. está en la región US y la tuya, creada por vuestro departamento de TI desde el Reino Unido, está en la región EU. Tus dispositivos del Reino Unido llaman al broker de EE. UU. con tokens que solo existen en la región de tu organización. Para ese broker son tokens desconocidos, por eso recibes un 4. Nada llega a tu pestaña Log porque nunca se le preguntó a tu organización.Me pasó exactamente esto cuando clonamos un proyecto entre dos de nuestras empresas de servicios públicos, una en cada región. Solución:
- Abre cualquiera de tus dispositivos, pestaña Credentials, Connection details. Anota el host del broker MQTT.
- Sustituye el host en el firmware (y el host HTTPS si lo usan).
- Sigue conectando por nombre de host. SNI es obligatorio, así que no fijes una IP obtenida de una consulta DNS.
Los propietarios y administradores también pueden ver la región de origen en la configuración de la organización, Residency. La página es Regions and data residency.Y como te aparecen 4s: el firmware espera 5 minutos, bien. Mantenlo así. Los inicios de sesión fallidos repetidos desde una misma dirección bloquean esa dirección durante un tiempo, y toda la planta está detrás de un único NAT.
Look at the host in your log line. That’s the broker host from the US firmware.
Hermetry runs as separate deployments per region (EU, US, TR) and every organisation lives in one home region. Devices have to connect to the device host of their own organisation’s region, the one on each device’s Connection details card. I’d bet the US plant’s organisation is in the US region and yours, created by your IT from the UK, is in the EU. Your UK devices are knocking on the US broker with tokens that only exist in your organisation’s region. To that broker they’re unknown tokens, so you get a 4. Nothing reaches your Log tab because your org was never asked.
I hit exactly this when we cloned a project between two of our utilities, one in each region. Fix:
- Open any of your devices, Credentials tab, Connection details. Note the MQTT broker host.
- Replace the host in the firmware (and the HTTPS host if they use it).
- Keep connecting by host name. SNI is required, so don’t hardcode an IP from a DNS lookup.
Owners and admins can also see the home region under the organisation settings, Residency. The page is Regions and data residency.
And since you’re getting 4s: the firmware backs off 5 minutes, good. Keep that. Repeated failed logins from one address block that address for a while, and the whole plant is behind one NAT.
Traducido del English por IA ·
Buena detección. Conviene poner el host en un archivo de configuración en lugar de en la compilación, para que la próxima planta no copie un host codificado de forma fija.
Good catch. Worth putting the host in a config file instead of the build, so the next plant doesn’t copy a hardcoded host.
Traducido del English por IA ·
Compruebe también qué paquete de CA fija el firmware de EE. UU. Si fijó el certificado del servidor de su región en lugar de usar un almacén de CA normal, puede fallar en el host de la UE por otro motivo.
Also check what CA bundle the US firmware pins. If they pinned their region’s server cert instead of using a normal CA store, it may fail on the EU host for a different reason.
Traducido del English por IA ·
Ja, nos pasó lo mismo con dos hoteles, dos organizaciones en dos regiones, con el mismo firmware.
Ha, we had the same with two hotels, two orgs in two regions, same firmware.
Traducido del English por IA ·
Eso era. La página de Residency indica EU, pero la organización de la planta de EE. UU. es US. Cambié el host por el de nuestra tarjeta Connection details y los 23 sensores estuvieron en línea en diez minutos. Lewis, tú también tenías razón, el firmware tenía anclado su certificado de servidor. Lo cambié al paquete de CA normal, si no, el handshake habría sido el siguiente fallo. El host ahora viene de una partición de configuración. Gracias a todos.
That was it. Residency page says EU, the US plant’s org is US. Changed the host to the one on our Connection details card and all 23 sensors were online within ten minutes. Lewis, you were right as well, the firmware had their server certificate pinned. I switched it to the normal CA bundle, otherwise the handshake would have been the next failure. Host now comes from a config partition. Thanks all.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.