Yapay zekâ tarafından English dilinden çevrildi ·
Biraz garip bir durum. İngiltere fabrikamızda titreşim sensörlerini devreye alıyoruz. ABD’deki kardeş fabrikamız aynı sensörleri zaten Hermetry üzerinde çalıştırıyor, bu yüzden oradaki kontrol sorumlusu bana firmware projesini gönderdi ve ben sadece token’ları kendi cihazlarımızın token’larıyla değiştirdim.Her bir cihaz başarısız oluyor:
[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 sKontrol ettiklerim:
- Token’lar doğrudan Create device çekmecesinden kopyalandı, üç kez kontrol edildi
- Kullanıcı adı = token, şifre boş, dokümantasyona göre
- Organizasyonumuzdaki cihazın Log sekmesinde hiçbir şey yok, reddedilen giriş yok
- 8883 portu dışarı doğru açık, TLS el sıkışması açıkça başarılı
Hermetry organizasyonumuz IT ekibimiz tarafından Ocak ayında oluşturuldu. Onlarınki daha eski. Organizasyona özgü gözden kaçırdığım bir ayar mı var? Kontrol sorumlularını tekrar aramak istemiyorum, zaten bir öğleden sonrasını bu konuya harcadı.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Kendi Log sekmenizde hiçbir kayıt yokken CONNACK 4 çok önemli bir ipucu. Organizasyonunuz bu girişleri hiç görmemiş.
CONNACK 4 with nothing in your own Log tab is a big hint. Your org never saw those logins.
Yapay zekâ tarafından English dilinden çevrildi ·
Belki token’lar yenilendi? Birisi yanlışlıkla Rotate’e bastıktan sonra bir kez bunu yaşamıştık.
Maybe the tokens got rotated? We had that once after someone hit Rotate by mistake.
Yapay zekâ tarafından English dilinden çevrildi ·
Token’lar yepyeni, kimse bir şeyi döndürmedi (rotate etmedi). Tyler, “hiç görmedim” derken ne demek istiyorsun?
Tokens are brand new, nobody rotated anything. Tyler, what do you mean never saw them?
Yapay zekâ tarafından English dilinden çevrildi ·
Log satırındaki host’a bakın. Bu, ABD firmware’indeki broker host’udur.Hermetry, bölge başına ayrı dağıtımlar üzerinde çalışır (EU, US, TR) ve her organizasyon tek bir ana bölgede bulunur. Cihazlar, kendi organizasyonlarının bölgesindeki cihaz host’una bağlanmak zorundadır; bu host, her cihazın Connection details kartında yer alır. Bahsederim, ABD fabrikasının organizasyonu US bölgesinde, İngiltere’deki BT ekibinizin oluşturduğu sizinki ise EU bölgesinde. İngiltere’deki cihazlarınız, yalnızca sizin organizasyonunuzun bölgesinde var olan token’larla US broker’ına kapı çalıyor. Bu broker için bunlar tanınmayan token’lardır, bu yüzden 4 alıyorsunuz. Organizasyonunuza hiç sorulmadığı için Log sekmenize hiçbir şey ulaşmıyor.Tam olarak bunu, her bölgede birer tane olan iki kamu hizmeti şirketimiz arasında bir projeyi klonladığımızda yaşadım. Çözüm:
- Cihazlarınızdan herhangi birini açın, Credentials sekmesi, Connection details. MQTT broker host’unu not edin.
- Firmware’deki host’u değiştirin (HTTPS host’unu kullanıyorsanız onu da).
- Host adıyla bağlanmaya devam edin. SNI gereklidir, bu yüzden bir DNS sorgusundan aldığınız IP’yi sabit kodlamayın.
Owner ve admin kullanıcılar, ana bölgeyi organizasyon ayarlarındaki Residency bölümünde de görebilir. Sayfa: Regions and data residency.Ve 4 hataları aldığınıza göre: firmware 5 dakika geri çekiliyor, iyi. Bunu koruyun. Tek bir adresten tekrarlanan başarısız girişler o adresi bir süre engeller, sizin tüm fabrikanız ise tek bir NAT arkasında.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
İyi yakalamışsınız. Sunucu adresini derlemede değil, bir yapılandırma dosyasında tutmak faydalı olur; böylece bir sonraki tesis sabit kodlanmış bir sunucu adresini kopyalamaz.
Good catch. Worth putting the host in a config file instead of the build, so the next plant doesn’t copy a hardcoded host.
Yapay zekâ tarafından English dilinden çevrildi ·
Ayrıca ABD firmware’inin hangi CA paketini sabitlediğini kontrol edin. Normal bir CA deposu yerine bölgesel sunucu sertifikasını sabitlediyse, AB sunucusunda farklı bir nedenle başarısız olabilir.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Ha, bizde de aynısı oldu: iki otelde, iki bölgedeki iki kuruluşta, aynı firmware ile.
Ha, we had the same with two hotels, two orgs in two regions, same firmware.
Yapay zekâ tarafından English dilinden çevrildi ·
Sorun buydu. Residency sayfasında EU yazıyor, ABD tesisinin organizasyonu ise US. Host’u Connection details kartındaki adresle değiştirdim ve 23 sensörün tamamı on dakika içinde çevrimiçi oldu. Lewis, sen de haklıydın; firmware onların sunucu sertifikasını sabitlemişti (pinned). Onu normal CA paketine çevirdim, yoksa el sıkışma bir sonraki hata olacaktı. Host artık bir config partition’dan geliyor. Herkese teşekkürler.
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.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.