Traduit de English par IA ·
Un cas un peu étrange. Nous déployons des capteurs de vibration dans notre usine britannique. Notre usine sœur aux États-Unis utilise déjà les mêmes capteurs sur Hermetry, alors leur responsable contrôle m’a envoyé son projet firmware et j’ai simplement remplacé les tokens par ceux de nos appareils.Tous les appareils échouent :
[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 sCe que j’ai vérifié :
- Tokens copiés directement depuis le tiroir Create device, vérifiés trois fois
- Nom d’utilisateur = token, mot de passe vide, comme indiqué dans la documentation
- L’onglet Log de l’appareil dans notre organisation n’affiche rien du tout, aucune connexion refusée
- Port 8883 ouvert en sortie, la négociation TLS réussit clairement
Notre organisation Hermetry a été créée en janvier par notre service informatique. La leur est plus ancienne. Y a-t-il un élément propre à l’organisation que je ne vois pas ? Je préfère ne pas rappeler leur responsable contrôle, il a déjà passé un après-midi sur ce problème.
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.
Traduit de English par IA ·
CONNACK 4 alors que l’onglet Log de votre propre organisation est vide est un indice important. Votre organisation n’a jamais vu ces connexions.
CONNACK 4 with nothing in your own Log tab is a big hint. Your org never saw those logins.
Traduit de English par IA ·
Peut-être que les tokens ont été renouvelés ? Nous avons déjà eu ce problème après qu’une personne a cliqué par erreur sur Rotate.
Maybe the tokens got rotated? We had that once after someone hit Rotate by mistake.
Traduit de English par IA ·
Les tokens sont tout neufs, personne n’en a fait la rotation. Tyler, que veux-tu dire par « jamais vu » ?
Tokens are brand new, nobody rotated anything. Tyler, what do you mean never saw them?
Traduit de English par IA ·
Regarde l’hôte dans ta ligne de journal. C’est l’hôte du broker issu du firmware américain.Hermetry fonctionne avec des déploiements séparés par région (EU, US, TR) et chaque organisation appartient à une seule région d’origine. Les appareils doivent se connecter à l’hôte de appareils de la région de leur propre organisation, celui qui figure sur la carte Connection details de chaque appareil. Je parie que l’organisation de l’usine américaine est dans la région US et que la tienne, créée par ton service informatique depuis le Royaume-Uni, est dans la région EU. Tes appareils britanniques frappent à la porte du broker américain avec des jetons qui n’existent que dans la région de ton organisation. Pour ce broker, ce sont des jetons inconnus, d’où le code 4. Rien n’atteint ton onglet Log parce que ton organisation n’a jamais été sollicitée.J’ai vécu exactement ça lorsque nous avons cloné un projet entre deux de nos fournisseurs d’énergie, un dans chaque région. Correctif :
- Ouvre n’importe lequel de tes appareils, onglet Credentials, Connection details. Note l’hôte du broker MQTT.
- Remplace l’hôte dans le firmware (et l’hôte HTTPS s’ils l’utilisent).
- Continue à te connecter par nom d’hôte. SNI est obligatoire, donc ne code pas en dur une IP obtenue par une recherche DNS.
Les propriétaires et administrateurs peuvent aussi voir la région d’origine dans les paramètres de l’organisation, Residency. La page est Regions and data residency.Et puisque tu reçois des 4 : le firmware attend 5 minutes, c’est bien. Garde ça. Des échecs de connexion répétés depuis une même adresse bloquent cette adresse pendant un certain temps, et toute l’usine est derrière un seul 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.
Traduit de English par IA ·
Bien vu. Il vaut mieux placer l’hôte dans un fichier de configuration plutôt que dans le build, afin que la prochaine usine ne copie pas un hôte codé en dur.
Good catch. Worth putting the host in a config file instead of the build, so the next plant doesn’t copy a hardcoded host.
Traduit de English par IA ·
Vérifiez aussi quel bundle de CA le firmware américain épingle. S’il a épinglé le certificat du serveur régional au lieu d’utiliser un magasin de CA classique, il peut échouer sur l’hôte UE pour une autre raison.
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.
Traduit de English par IA ·
Ha, nous avons eu la même chose avec deux hôtels, deux organisations dans deux régions, même firmware.
Ha, we had the same with two hotels, two orgs in two regions, same firmware.
Traduit de English par IA ·
C’était bien ça. La page Residency indique EU, alors que l’organisation du site US est US. J’ai remplacé l’hôte par celui de notre carte Connection details, et les 23 capteurs étaient tous en ligne en moins de dix minutes. Lewis, tu avais raison aussi, le firmware avait leur certificat serveur épinglé. Je l’ai basculé sur le bundle CA standard, sinon le handshake aurait été la prochaine erreur. L’hôte provient désormais d’une partition de configuration. Merci à tous.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.