BG96 post request to influxdata

Using a python script I can send data to my database on influxdata cloud without any problem
Now I want to send data from a RAK5010 (with BG96 and Arduino IDE) using AT+QHTTPOST command but I always get an error : CME ERROR 701
For information I can send data to azure cloud using the RAK and HTTPPOST command
Anyone encounterd this problem?
Thanks for help
Michel

I think you’ll need to tell us rather more about the out-of-the-ordinary
equipment you’re talking about here, for example:

  1. What is a RAK5010?
  2. If relevant, what is a BG96?
  3. AT+QHTTPOST looks like a modem command to me - is it?
  4. What software is giving you the error “CME ERROR 701”?
  5. Do you have any error table reference to find out what error 701 means?

Also, you say you can send data to Azure cloud using the RAK and HTTPPOST
command…

a. what software in Azure are you sending the data to?
b. what’s the difference between the command you use to send to Azure and the
command you use to send to Influx?
c. are you using the same Python script for both?

Finally:

It’s not just a spelling mistake in “HTTPPOST” causing this, is it?

Antony.

A RAK5010 is a simple board with a GB96 Quectel modem, some sensors and a SIM card.
All commands use AT command and AT+QHTTPPOST is the way to send a post request to a server
When I use a python script on windows to send the same request : all is OK
When I use AT+QHTTPPOST on the BG96 I get a return code : CME ERROR 701
Using AT+QHTTPPOST on other server than “eu-central-1-1.aws.cloud2.influxdata.com” works well

I don’t know how to help there, the problem has rather nothing to do with InfluxDB, but with how this modem implements the POST request.
Maybe better to ask in the forum of Quectel?
I suspect that https may not work?

I agree with Franky1 and you may find https://forums.quectel.com/t/failed/2995
useful / relevant.

Antony.

https works without any problem with a lot of sites. I can send data to azure, to webhook.site without any problem.
I get this error only with : eu-central-1-1.aws.cloud2.influxdata.com

I suspect a problem with TLS.
Maybe here are some more hints:
https://forums.quectel.com/t/bg96-http-works-but-https-does-not-work/2463

I have tried all theses solutions without any success!

Well, I still think you’re better off asking on a Quectel forum (since it’s
that device, or the driver for it, that’s producing the error) than here,
because Influx itself isn’t complaining.

Is there any way of running a packet capture on the communications between the
Quectel thing and the Influx server, so you can actually see what TLS
negotiation is taking place?

Antony.

unfortunatly the BG96 only give the CME ERROR and nothing more.
If I can’t a correction for this problem I will try with another database server.
Thanks for help

Well, it would be simple enough to set up an InfluxDB server of your own, on a
machine you can run the packet capture on, and then you could see what
negotiation is taking place.

If TLS gets negotiated without any problems, and then the CME error happens
later, you know that it’s not a TLS problem, and we can move on to other
reasons.

From the brief amount of Google searching I did, though, it seems that people
are getting this error because of encryption support mismatches between the
client and the server.

Antony.

I have done some more tests :

I created a second account on influxdata but on Azure (the first one was on AWS) but I get the same error.

Try to post on Thingsboard cloud : no problem!

The only way I founf to solve this issue is : https://forums.quectel.com/t/bg96-http-works-but-https-does-not-work/2463/14
Is there any body at InfluxData that could verify all ciphers are installed on InfluxData servers.

Thanks in advance for help

Michel

This might give some more ideas:

The easiest thing could be to use SSL Labs and compare the displayed ciphers from the AWS URL with those from the modem:

https://www.ssllabs.com

Thanks Franky : I analyse influxdata server and thingboard cloud server with sslabs:

Apparently BG 96 support theses ciphers with TLS1.2
https://usermanual.wiki/Document/QuectelBG96SSLATCommandsManualV10.9310271/view

(list on page 13)

Thingsboard cloud :
\ 14x14

TLS 1.2 (suites in server-preferred order)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ( 0xc014 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ( 0xcca8 ) ECDH x25519 (eq. 3072 bits RSA) FS 256P
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 ( 0xc061 ) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 ( 0xc060 ) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 ( 0xc077 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 ( 0xc076 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013 ) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
TLS_RSA_WITH_AES_256_CCM_8 ( 0xc0a1 ) WEAK 256
TLS_RSA_WITH_AES_256_CCM ( 0xc09d ) WEAK 256
TLS_RSA_WITH_ARIA_256_GCM_SHA384 ( 0xc051 ) WEAK 256
TLS_RSA_WITH_AES_128_CCM_8 ( 0xc0a0 ) WEAK 128
TLS_RSA_WITH_AES_128_CCM ( 0xc09c ) WEAK 128
TLS_RSA_WITH_ARIA_128_GCM_SHA256 ( 0xc050 ) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 ( 0x3d ) WEAK 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 ( 0xc0 ) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c ) WEAK 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 ( 0xba ) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35 ) WEAK 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA ( 0x84 ) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f ) WEAK 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA ( 0x41 ) WEAK

And Influxdata :

TLS 1.2 (suites in server-preferred order)

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256

Is a way to extend the ciphers used by influxdata servers?

Michel

This cipher suite should be supported both by the Modem and the Influxdata instance.

I don’t believe GCM is interoperable with CBC.

Antony.

I just make a test specifying the cipher to use with the command AT+QSSLCFG=“ciphersuite”,1,0xC02f but still get the same error

Is there a hope that the authorized list of cipher could be extended on influxdata servers?

Michel