@clemens, did you also try the example_SIM800L.py which worked for @poesel (it formerly was a fn call example_usage()) ? What does this script say on your T-call ?
Your connection to https://swarm.hiveyes.org failed, while https://postman-echo.com/post succeeded on poesel’s tests, which should be investigated first: you both have a TTGO Tcall from the same production run - therefore it’s not very likely that a different firmware in the modem is the reason.
Do we know that? We bought the devices seperately.
That came from the line:
#print(‘Modem info: “{}”’.format(modem.get_info()))
in example_SIM800.py. If there is anything else I can take a look at the board this evening.
Unfortunately I got the old and limp salat:
Modem: SIM800 R13.08
Think I bought the T-Call last summer in the time it was announced here at hiveeyes while @poesel ordered it in the last weeks.
Hmm, is this a hardware issue or can it be updated via firmware?
@poesel you may have a look at the “firmware version” or whatever it is via AT+CGMR I did it with the TinyGSM lib but it should be possible via the pythings code, you may supplement it here:
Volodymyr Shymanskyy the author of TinyGSM writes at
https://github.com/vshymanskyy/TinyGSM/issues/29#issuecomment-328802556
On my
SIM800 R14.18it works fine.
The other one,SIM800 R13.08reports that SSL is not supported.
So we should make steps in this direction. Btw. is there a date in SIM800L16_20141031_1027 and has my 2019 device a SIM800 module from 2014-10-31 or does it only look like a date by chance?
@clemens, @poesel: OK, I somehow thought you were buying this within a same order, apparently no: even very different fw versions.
But this is one more reason to switch over to PPP when running on an ESP32 and no longer depend on this old IP stack on the SIM800.
…but sadly only without PPP.
well, this is the only way to overcome the limitations of the inbuilt IP stack of the SIM800L in terms of reasonable transport layer security: this stack only “features” SSL2, SSL3 and TLS 1.0, and the firmware is about six years old. The three mentioned cryptographic protocols are considered deprecated; SSL2 and 3 are dead, TLS 1.0 ist dead by the BEAST attack also since at least six years, within this spring 2020 all major browser will switch off their support for TLS 1.0 (and even TLS 1.1).
Even if one gets a SIM800 fw updated, it then will only be able to run outdated ‘secure’ protocols and ciphers. So there no other chance remains to update to decent security except via PPP usage and having the ESP32 IP stack doing the work. This way, it even doesn’t matter what particular fw a respective SIM800 has, as its ‘secure’ features are simple not used (it simply of course needs PPP support in its fw).
Here is how loboris does this (w/ a SIM800L ;) ):
@weef sorry I must have mis-explained myself: I meant that the idf4 which is without PPP should work with this AT-based driver for the SIM800, but I was not sure about the benefits of using firmware idf4 over idf3 in general.
I fully agree on the benefits of using PPP (and therefore idf3) instead of relying on SIM800 internal SSL stack via AT commands, also because the SIM800 internal SSL stack does not perform certificate validation, which is something that should be possible to do at least in a not too far future. Agreed also on the protocol version concerns.
The main problem with what loboris does is that as far as I understood it is not a “pluggable driver” but requires an an entire firmware build + patches. Also, its Micropython fork [1] has diverged from the main repo [2], making it not much usable IMHO.
Having an AT-based, almost hardware-agnostic implementation allows for excellent porting across different boards and microcontrollers, this is why I followed this way even given the limitations.
I guess it depends on the use case, for sensitive data the SIM800 internal SSL implementation it is definitely not OK, for sending a bunch of metrics on a cloud service it might be a reasonable compromise.
This said, it would be great to have the Esp32 + SIM800 work out of the box with a vanilla MicroPython and proper SSL stack 
[1] GitHub - loboris/MicroPython_ESP32_psRAM_LoBo: MicroPython for ESP32 with psRAM support
[2] Integrating Loboris port back to official uP ESP32 port - MicroPython Forum
Hi again,
thanks for having a fruitful discussion around that topic here. My proposal is to improve non-SSL communication for the AT-command-based driver through [SIM800] Problems with AT+HTTPSSL commands · Issue #3 · pythings/Drivers · GitHub and – quoting @sarusso here
– to look into PPP over Serial (PPPoS) support for SIM800 within ESP-IDF for ESP32 for gaining real PPPoS based on the current ESP-IDF.
With kind regards,
Andreas.
P.S.: There’s not much additional information in there, but just to list it as a reference: SIM800 Series_SSL_ApplicationNote_V1.02.
P.P.S.: While this is not specific to the ESP32, I would also like to point out to Driver for Adafruit GSM FONA module - MicroPython Forum (Archive) and https://github.com/adafruit/circuitpython/issues/250 here.
For this application I take security if its there and works. If it does not I don’t care. If someone would like to know how much my hives weigh he can take a look at the Grafana dashboard. No need to hack protocols. 
Revision: 1418B05SIM800L24
I’ve made some updates to the driver which should now gracefully fall back to not use SSL at all if the modeminfo string is smaller than SIM800 R14.00.
I’ve outlined the rationale to actually prefer modeminfo (retrieved by ATI) over the firmware revision (retrieved by AT+CGMR) within [SIM800] Problems with AT+HTTPSSL commands · Issue #3 · pythings/Drivers · GitHub.
thanks for explaining your intentions on your library approach. - Citing the loboris fork here by me is a bit unfair as it does not take care on backward compatibility to µpy mainline. I benefit from this fork while using it on an Odroid Go and don’t have to care about compatibility and hence ‘proprietary’ extensions … ;)
I liked it actually. Credit whom credit is due. I believe Boris already brought some good things related to PPPoS support into ESP-IDF the other day.
Interesting that my firmware version number ist totally different from the structure. Must be very old! ;-)
Good to know that it works, on this issue someone reported problems ander the TinyGSM lib with https and the same number also: SIM 800L - HTTPS · Issue #235 · vshymanskyy/TinyGSM · GitHub
It looks like one can update the firmware in the SIM800L. After a bit of googling it looks like I have the latest firmware version. Unfortunately, I haven’t found it anywhere for download. Only hint was here:
It may also be that the firmware update tool can download the firmware itself. Isn’t clear to me.
Simcom also has an official downloads directory with lots of files:
https://simcom.ee/documents/
Dear Stefano,
This is our first attempt of adding support for PPPoS we have been discussing here and investigated further within PPP over Serial (PPPoS) support for MicroPython on ESP32. Please note this is still untested as I don’t have respective hardware on my workbench.
On Genuine MicroPython, this might work out-of-the-box. However, there definitively will be dragons.
With kind regards,
Andreas.
If someone wants to use PPP-based networking on Pycom MicroPython, there are now updated firmware images on https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/.
This adds PPP networking from Genuine MicroPython in order to support PPP over Serial (PPPoS), which has not been included on Pycom devices up to this date.
Hi guys,
could you also share the output of "AT+CIPSSL=?" with us? It might be better than going for "modem_info".
Thanks,
Andreas.
– SIM 800L - HTTPS · Issue #235 · vshymanskyy/TinyGSM · GitHub
‘+CIPSSL: (0-1)’
Nicht so der Bringer…
Man findet die Dokumentation bei 2.4.AT +CIPSSL Set TCP to Use SSL Function auf Seite 9 der SIM800 Series_SSL_ApplicationNote_V1.02. Damit kann man dann wohl abfragen, ob SSL angeschaltet wurde (1) oder nicht (0).
Vergessen wirs einfach und lassen die Implementierung so wie sie ist. Nur bei Lust und Laune… Wenn dann bräuchten wir beide Ausgaben – von Dir von @clemens – um diese vergleichen zu können.
so, zum Vergleich mal eine ‘alte’ firmware rausgekramt; vielleicht könntest Du, @Clemens, auch noch mal schauen - Du müßtest beim letzten Befehl das gleiche bekommen:
ati
SIM800 R13.08
OK
at+cgmr
Revision:1308B08SIM800L16
OK
at+cipssl=?
ERROR
Danke! Wenn das bei @poesel “OK” ausgibt, wollen wir das dann als extra Roundtrip zur Capability Detection einbauen, statt – wie momentan implementiert – auf die ati Zeichenkette zu schauen?
Wie schon geschrieben, die Antwort auf
at+cipssl=?
ist
+CIPSSL: (0-1)