2022-01-10 02:19 PM
2022-01-10 02:31 PM
I have an STM32L494 discovery board with cellular BG96 modem and trying to connect to Google IOT core with the provided project example design. (GCP v1.0.0)
On application launch, first thing it asks is the connection string which I can enter successfully now.
It then asks for the TLS root CA certificate which I have found in comodo_google.pem. I paste the two certificates. Program continues.
I created a private and public key, uploaded the public key in Google Cloud IoT, and the enter the private device key on the terminal. Program continues and starts the SSL/TLS handshake.
However, the handshake fails at Client State 3, where shortly after it prints the following (Attached the entire log)
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: serial number : 77:BD:0D:6C:DB:36:F9:1A:EA:21:0F:C4:F0:58:D3:0D
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: issuer name : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: subject name : C=US, O=Google Trust Services LLC, CN=GTS Root R1
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: issued on : 2020-06-19 00:00:42
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: expires on : 2028-01-28 00:00:42
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: signed using : RSA with SHA-256
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: RSA key size : 4096 bits
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: basic constraints : CA=true
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: key usage : Digital Signature, Key Cert Sign, CRL Sign
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: value of 'crt->rsa.N' (4096 bits) is:
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: value of 'crt->rsa.E' (17 bits) is:
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: 01 00 01
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4643: x509_verify_cert() returned -9984 (-0x2700)
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4180: => send alert message
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4181: send alert level=2 message=48
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2764: => write record
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2907: output record: msgtype = 21, version = [3:3], msglen = 2
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2912: dumping 'output record sent to network' (7 bytes)
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2912: 0000: 15 03 03 00 02 02 30 ......0
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 7, out_left: 7
ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed
OK
ERROR: net_sock_send_tcp_c2c L#332 Send failed.
ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=7
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2922: <= write record
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4193: <= send alert message
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4730: ! Certificate verification flags 208
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4740: <= parse certificate
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake
ERROR: net_sock_open_mbedtls L#279 Server verification:
! The certificate is not correctly signed by the trusted CA
! The certificate validity starts in the future
ERROR: net_sock_open_mbedtls L#286 failed
! mbedtls_ssl_handshake returned -0x2700
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7542: => free
STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7607: <= free
ERROR: GcpIoT_connect L#596 Could not open the socket at mqtt.googleapis.com port 8883.
ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.
Is this an incorrect mbedtls configuration, in the project settings it seems to use this one:
MBEDTLS_CONFIG_FILE=<googleiot_mbedtls_config.h>
Or still something wrong with certificates/keys?
When I set authmode to optional in the mbedtls wrapper file mbedtls_ssl_conf_authmode(&tlsData->conf, MBEDTLS_SSL_VERIFY_OPTIONAL);
then the ssl handshake continues to client state 12, then jumps to client state 17, but then can't write either.
2022-01-10 04:34 PM
OK so I those 2 issues were
It passes server verification now, but I still see the issue where it enters Client State 12 ( MBEDTLS_SSL_SERVER_CHANGE_CIPHER_SPEC), and then jumps to state 17 (MBEDTLS_SSL_SERVER_NEW_SESSION_TICKET) and when in state 17 it just keeps looping there, and still with those occasions C2C_SendData errors 572 : Operation not allowed.
No idea what can still be missing at this point
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45
ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed
OK
ERROR: net_sock_send_tcp_c2c L#332 Send failed.
ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=45
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2922: <= write record
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:5398: <= write finished
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 12
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45
ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed
OK
ERROR: net_sock_send_tcp_c2c L#332 Send failed.
ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=45
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3277: => parse new session ticket
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:3809: => read record
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2252: => fetch input
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2412: in_left: 0, nb_want: 5
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2436: in_left: 0, nb_want: 5
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6754: => handshake
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 17
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45
ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed
OK
2022-01-10 06:30 PM
Reducing the debug threshold in mbedtls again, actually shows that the google ssl handshake appears to have succeeded, though below would suggest something is still not quite right.
The code now fails at the first mqtt_write which also calls net_sock_send and mbed_ssl_write
onfiguring the RTC from Date: Tue, 11 Jan 2022 01:58:25 GMT
Creating socket... done.
Creating jwt... done.
Opening socket... done.
Opening MQTT connection to client projects/My First Project/locations/us-central1/registries/ww-gateway/devices/ww-edge
ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed
OK
ERROR: net_sock_send_tcp_c2c L#332 Send failed.
ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=353
MQTT Connection failure... retrying... ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.
Network link may be down. Trying to reconnect.
2022-01-11 01:13 AM
Hello
what kind of private key are you using for the device ? is it ECC ? if yes, could you try with RSA key ?
2022-01-11 01:22 AM
I created private/public ES256 keys as per page 17/29 of the GCP documentation v1.0 using openSSL
Entered the private .pem key's contents on the console, and configured google cloud back-end with the public key.
2022-01-11 01:37 AM
OK so now I just did the same thing, but then for RSA256, still exactly the same problem
Higher debug threshold mbedtls:
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 15 -> THIS IS GOOD
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2483: <= flush output
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake
done.
Opening MQTT connection to client projects/My First Project/locations/us-central1/registries/ww-gateway/devices/ww-edge
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7330: => write
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2764: => write record
then some write records/read records...
....
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6940: => read
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:3809: => read record
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2252: => fetch input
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2412: in_left: 0, nb_want: 5
C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2436: in_left: 0, nb_want: 5
MQTT Connection failure... retrying... ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.
Network link may be down. Trying to reconnect.
ERROR: gcp_main L#412 Netif re-initialization failed.
*** Cloud connectivity demonstration ***
Cloud connectivity demonstration completed
2022-01-11 08:26 PM
OK so I have this up and running on the evaluation board.
It was simply an incorrect string for the google cloud project ID...but some cryptic debug messages for something so easy.
Next step is now to port this onto our board, which has an STM32F103-G device, so 1M of memory.
The entire cellular stack builds (apart from some items below), the modem is up and running on our board and is connected to the AP...
However there is a problem with STM32F1xxx in that it does not include the stm_hal_rng library for random number generators, which is needed during the handshake and creation of the JWT web token.
Right here (jwt.c)
ret = mbedtls_entropy_add_source(&entropy, mbedtls_rng_poll_cb, (void*)&hrng, 1, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0 )
And also in net_mbedtls_net.c
(ret = mbedtls_entropy_add_source(&tlsData->entropy, mbedtls_hardware_poll, (void*)&hrng, 1, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0 )
So how do I get around this issue on our STM32f1 device?
2022-01-12 02:39 AM
Hello
I'm glad you managed to make X-CUBE-GCP 1.0.0 work on STM32L496G-Discovery board with BG96 cellular modem.
I remember there were problems with EC256 certificates but apparently it works for you.
You say you want to switch to STM32F103 with the Quectel BG96 cellular modem.
As you say, STM32F1 doesn't have hardware Random Number Generator IP used in mbedTLS. It is used as an entropy source for mbedTLS software random number generator . It's always more secure to have an hardware entropy source. I'll try to find a way to use software entropy generator if possible and publish it in another post but no guarantee.
Also note that even if STM32F103 can have up to 1 MByte flash memory, it is limited to 96 KB RAM. mbedTLS uses a lot of RAM so it could be tight. In theory, in TLS standard you can receive up to 2 "records" (packets) of 16 KB each. So 32 KB would be used out of 96KB RAM on STM32F103. You can decide to reduce the size of records you are able to receive but there's no guarantee that the server will send you less than 16KB.
As a general remark here are some details about X-CUBE-GCP:
X-CUBE-GCP 1.0.0 :
X-CUBE-GCP 2.0.0:
Note that SBSFU requires more Flash memory. There must be an additional Flash section available for firmware update.
Normaly we only support the latest version.
2022-01-12 10:09 AM
Thanks for the clarification. So in theory I think it should work in the combo STM32F103 + BG93 using GCP 1.0 open source SW, just need the SW entropy generator.
Memory usage at the moment on the STM32F103 looks likeSo that should be fine.
It was my initial idea to port the GCP2.0 code using Google SDK on our board, or even the STML496 discovery first, but was having issues with it. It was not until later I realized that GCP v1.0 actually had support for the STML496 discovery board, so it obviously made sense to see this working first.
The BG96 modem is already integrated with our STM32F103 and works well, I mean it attaches to the network), but now we just need to see about getting the GCP1.0 code to run on it as well..
As mentions, it compiles etc...just have the issue with the RNG