Azure IoT Central
Uma plataforma de aplicativo de IoT (Internet das Coisas) hospedada no Azure.
20251110 Log ConectaAzure - conn_and_discon.txt
Follow attached the Log file as requested.
[URGENT] RE: Request for Support – Intermittent IoT Device Connection to Azure IoT Hub
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 54%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECE%3C/text%3E%3C/svg%3E)
CEPE Energia
5
Pontos de reputação
Dear Microsoft Azure Support Team,
I am reaching out to kindly request your assistance in identifying the exact cause of an intermittent connection issue between my IoT device and the Azure IoT Hub.
I am currently developing firmware for a board called LilyGo, which includes an ESP32-WROVER microcontroller and a SIMCOM A7670SA modem.
At the moment, for example, the device is successfully connected; however, at any given time, the modem disconnects unexpectedly. Even if I revert to the original firmware code (without any modifications), the modem often fails to reconnect afterward.
My initial suspicion is that the issue may be related to the SAS token expiration, but after conducting several tests — generating new tokens and attempting reconnection — all attempts have failed.
To give you an idea, I haven’t changed a single line of code since last Friday, and today, after simply updating the SAS token, the board connected successfully again. At this moment, the modem is connected and functioning normally.
Do you understand what might be happening? For some reason, the modem suddenly loses connection and is unable to reconnect for a period of time. Then, after a few days, it reconnects successfully without any code changes.
I need to understand what is causing this behavior. My impression is that the IoT Hub, after a few failed connection attempts, starts rejecting further connections from the device, reporting a connection failure — even when using a valid, non-expired SAS token.
Could you please help me understand what is happening and how I can resolve this issue?
Device Information:
- Device ID: dispositivo_beta01-4G
- Host name: REDACTED__.azure-devices.net__
- Microsoft Account: ******@outlook.com__
P.S.: Attached to this message are two logs to help analyze the issue: the first shows a successful connection, and the second shows an unsuccessful connection after the modem disconnects and is unable to reconnect, even when reverting to the original firmware code. Thank you very much for your support.
Best regards, Kopelvski A. M.
20251031 Log ConectaAzure20251031 Log ConectaAzure - COMErros.txt - semErros.txt
Note: Observação: Email e nome do host foram removidos no lado do suporte
Azure IoT Central
2 respostas
Classificar por: Mais Novo
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(204.8, 15%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMR%3C/text%3E%3C/svg%3E)
Manas R Mohanty 17,270 Pontos de reputação Moderador2025-11-06T18:39:19.09+00:00 Ola' CEPE Energia
Aqui está a análise e a recomendação com base nos logs.
Sessão bem-sucedida — 20251031 Log ConectaAzure - semErros
PDP e IP estabelecidos (+NETOPEN, +IPADDR: 10.9.181.240).
Sincronização de horário via NITZ (offset -12).
Contexto TLS configurado (sslversion=4, authmode=0). Configurações de SNI/hostname retornam ERROR, mas a sessão continua.
Conexão MQTT com token SAS bem-sucedida: +CMQTTCONNECT: 0,0, seguida de publicações com PUBACK repetidos. [20251031 L…- semErros | Txt]
Sessão com falha — 20251031 Log ConectaAzure - COMErros
Bring-up de rede semelhante; sincronização via NITZ (offset -12).
Contexto TLS igual ao anterior; SNI/hostname ainda retornam ERROR.
Conexão MQTT falha durante TLS: +CMQTTCONNECT: 0,31 seguido de ERROR e mensagem “Falha em CMQTTCONNECT (handshake TLS)”. [20251031 L…- COMErros | Txt]
Informações do dispositivo
O dispositivo é ESP32-WROVER + SIMCom A7670SA, conectando-se a CEPEHub.azure-devices.net com ID dispositivo_beta01-4G. Relata falhas intermitentes de reconexão após desconexões, suspeitando de token SAS ou rejeição pelo Hub. [learn.microsoft.com]
Causa provável (e por que parece intermitente)
Incompatibilidade de handshake TLS/cifra no modem O Azure IoT Hub aplica TLS 1.2 + cifras fortes desde 31/08/2025. Muitos módulos celulares usam modos “auto” que podem tentar cifras não suportadas ou TLS 1.3, causando falhas esporádicas. O erro +CMQTTCONNECT: 0,31 indica falha no handshake TLS.
Confiança na CA raiz no modem O IoT Hub migrou para certificados DigiCert Global Root G2. Se o modem não tiver essa CA carregada (ou validação desativada via authmode=0), o comportamento do handshake pode variar.
SNI não configurado / não suportado O IoT Hub usa SNI para seleção de hostname. Logs mostram AT+CSSLCFG="sni",0,1 e AT+CSSLCFG="hostname",0,"CEPEHub.azure-devices.net" retornando ERROR.
Por isso parece “aleatório”: depende da rota da célula e combinações de cifra/SNI.
Plano passo a passo para solução
Objetivo: atender aos requisitos TLS 1.2 + DigiCert G2 do IoT Hub e seguir especificações MQTT.
A. Forçar TLS 1.2 no modem
Configure versão TLS para 1.2 apenas (não “auto”).
Ex.: AT+CSSLCFG="sslversion",0,(valor para TLS 1.2).
Ajuste timeout: AT+CSSLCFG="negotiatetime",0,60 e ignorelocaltime: AT+CSSLCFG="ignorelocaltime",0,1.
B. Carregar e usar DigiCert Global Root G2
Baixe e configure CA: AT+CCERTDOWN=cacert.pem AT+CSSLCFG="authmode",0,1 AT+CSSLCFG="cacert",0,"cacert.pem"
C. Habilitar SNI/hostname (ou atualizar firmware)
Comandos: AT+CSSLCFG="sni",0,1 AT+CSSLCFG="hostname",0,"CEPEHub.azure-devices.net"
D. Seguir requisitos MQTT do IoT Hub
Username: CEPEHub.azure-devices.net/dispositivo_beta01-4G/?api-version=2021-04-12
Password: token SAS renovado a cada reconexão.
Client ID = dispositivo_beta01-4G.
E. Estratégia de reconexão
Backoff exponencial (1s → 2s → 4s … máx. 1–2 min).
Sempre gerar novo token SAS.
cleanSession=1.
Espero que ajude.
Nota: Desculpe se encontrar alguma anomalia na tradução.
Obrigado.
-
Manas R Mohanty 17,270 Pontos de reputação Moderador
2025-11-11T12:35:53.98+00:00 Ola' CEPE Energia
Por favor, nos informe se você achou minha resposta útil ou se tem dúvidas adicionais sobre o mesmo assunto.
Obrigado
-
CEPE Energia 5 Pontos de reputação
2025-11-11T20:01:38.1033333+00:00 Dear Manas,
Thank you very much for your support.
Regarding the SAS token expiration, I currently generate the token dynamically; therefore, the expiration itself is not the only point that needs to be verified.
I agree with all the points mentioned, and there are several other important aspects that need to be adjusted. The fact is that the SimCom modem I’m using (model A7670SA) lacks some essential features — for example, uploading DigiCert Global Root G2 certificate, enabling TLS 1.2, and enable SNI. Due to these limitations, I really need to simplify the connection process to Azure as much as possible.
I understand that this modem is not exactly a new model, but my goal is to establish a functional connection to Azure using the simplest method available, even if that means reducing some security features, as long as I can successfully access Azure IoT Central.
Attached you’ll find one of the latest debug logs generated on the device side for your reference. In it, you can see that a new SAS token is created with each connection attempt, as well as the moment when the connection is lost. After that, the device is only able to reconnect if I try again the next day (after approximately 24 hours).
Do you have any suggestions or recommendations regarding this?
Best regards,
Kopelvski M.A.
-
Manas R Mohanty 17,270 Pontos de reputação Moderador
2025-11-12T13:19:28.1433333+00:00 Ola CEPE Energy
Você esqueceu de adicionar os logs. Por favor, compartilhe novamente. Vou revisar com o grupo de Produto internamente conforme solicitado e retorno para você.
Obrigado.
-
Manas R Mohanty 17,270 Pontos de reputação Moderador
2025-11-17T11:20:00.3566667+00:00 Ola CEPE Energy
Revisei os logs com o grupo de produto aqui. Eles mencionaram o seguinte:
2025-10-31 19:12 - 19:36 o cliente foi desconectado devido a uma nova conexão e, depois, ocorreram várias desconexões devido ao token SAS expirado. Talvez tenha sido nesse momento que o cliente mencionou: 'após realizar vários testes — gerando novos tokens e tentando reconectar.
Aqui está uma lista de verificação com base nos problemas acima:
Uma identidade de dispositivo → uma conexão ativa por vez. Encerre qualquer cliente/teste duplicado usando o mesmo DeviceId. [learn.microsoft.com]
Sincronize o horário (NTP); registre o UTC atual e o parâmetro
seem cada conexão. [learn.microsoft.com]Renove o SAS antes da expiração (80–90% do TTL); use backoff exponencial + jitter na reconexão. [learn.microsoft.com]
Validação do formato do token: audience, string de username, URL‑encoding, epoch seconds no
se. [learn.microsoft.com]Configurações MQTT:
cleanSession=false,keepAlive=30–60s. [learn.microsoft.com]TLS 1.2: verifique firmware do modem/SNI/pacote de CA raiz; atualize se necessário. [Intermitte...0040004166 | Outlook]
Observabilidade: assine o Event Grid
deviceConnected/deviceDisconnected; adicione alertas do Azure Monitor para churn. [learn.microsoft.com]
Entre para comentar -