BGS5T HTTP Post Problem | Thales IoT Developer Community
June 24, 2020 - 8:44pm, 6638 views
We are making the transision from a BGS2T to BGS5T in one of our products and are experiencing problems when trying to POST data to one of our clients' URLs.
The issue is that when configuring for a GET, we are designated an IP address when starting the session
AT^SISO? .......
^SISO: 1,"Http",4,1,0,0,"10.234.15.70:0","---:443"
When configuring for a POST, we are NOT designated an IP address when starting the session
AT^SISO? .......
^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008","--:443"
There is a full trace of commands and replies from the BGS5T when attempting the GETs and POSTs below (url and token have been modified for the purpose of this forum)
When running these command sequences on a BGS2T (same SIM card - not that it should make a difference), both the GET and POST result in an IP address being designated.
Any ideas regarding whatis going on here?
Looking at the BGS5T command manual the only relavent difference between BGS5T and BGS2T is the use of AT^SISS=1,hcMethod,1 and AT^SISS=1,cmd,"post" to setup the REST call type.
We are really stuck here - help!
*************************GET****************************************
AT^SICS=0,conType,"GPRS0"
OK
AT^SICS=0,"inactTO", "240"
OK
AT^SICS=0,user,"USER"
OK
AT^SICS=0,passwd,---
OK
AT^SICS=0,apn,"ESEYE.COM"
OK
AT^SISS=1,"srvType","HTTP"
OK
AT^SISS=1,conId,0
OK
AT^SISS=1,cmd,"get"
OK
at^siss=1,hcRedir,0
OK
at^siss=1,"address","https://---"
OK
at^SISS=1,"hcProp","x-token: ---"
OK
AT^SISS?
^SISS: 0,"srvType",""
^SISS: 1,"srvType","Http"
^SISS: 1,"conId","0"
^SISS: 1,"address","https://---"
^SISS: 1,"tcpMR","10"
^SISS: 1,"tcpOT","6000"
^SISS: 1,"cmd","get"
^SISS: 1,"hcProp","---"
^SISS: 1,"hcContLen",""
^SISS: 1,"hcMethod",""
^SISS: 1,"hcRedir","0"
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"
srvType",""
OK
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---:443"
^SISR: 1,1
AT^SISO?
^SISO: 0,""
^SISO: 1,"Http",4,1,0,0,"10.234.15.70:0","---:443"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
************************POST************************************
AT^SISC=1
OK
AT^SICS=0,conType,"GPRS0"
OK
AT^SICS=0,"inactTO", "240"
OK
AT^SICS=0,user,"USER"
OK
AT^SICS=0,passwd,---
OK
AT^SICS=0,apn,"ESEYE.COM"
OK
AT^SISS=1,"srvType","HTTP"
OK
AT^SISS=1,conId,0
OK
AT^SISS=1,cmd,"post"
OK
at^siss=1,hcRedir,0
OK
at^siss=1,"address","https://---"
OK
at^SISS=1,"hcProp","x-token: ---"
OK
AT^SISS?
^SISS: 0,"srvType",""
^SISS: 1,"srvType","Http"
^SISS: 1,"conId","0"
^SISS: 1,"address","https://---"
^SISS: 1,"tcpMR","10"
^SISS: 1,"tcpOT","6000"
^SISS: 1,"cmd","post"
^SISS: 1,"hcProp","x-token: ---"
^SISS: 1,"hcContLen",""
^SISS: 1,"hcMethod",""
^SISS: 1,"hcRedir","0"
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"
srvType",""
OK
AT^SISO=1
OK
^SIS: 1,0,2200,"Http ---:443"
^SISW: 1,1
AT^SISO?
^SISO: 0,""
^SISO: 1,"Http",4,1,0,0,"0.0.0.1:8008","--:443"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
Hello,
I've got your point now. Each command must return a result which is OK or ERROR. And before that you can't execute any other command. In case of some long lasting commands you can break the execution by sending some data before OK (like AT+COPS=?). So in this case it is correct that you can't send any command before you get ^SISW: 1,0,0 and OK. But as the module opens the connection and sends the within this command execution it seems that it can be a problem in case it takes longer than expected. But there should be some internal timeout in case the data can't be sent. I believe it should be no more than 2 minutes. Have you tried to wait for a few minutes to test it?
Regards,
Bartłomiej
Hi,
After sending AT^SISW=1,0,1 and not getting a HTTP 200 response , I get the following after approximately two-three minutes:
SIS: 1,0,2200,"HTTP POST: https://---"
^SIS: 1,0,8002,"HttpHTTP POST: IllegalArgumentException Socket-Error:3"
I guess this network related. The problem is that the BGS5T seems completely locked up to that point.
Waiting so long seems very inefficient.
Is there any way to exit after the AT^SISW=1,0,1 command when no response arrives?
As mentioned previously, the only method seems to be to power the modem down.
Hello,
It seems like this is related to network communication. However to debug this further we'd have to trace the module, see network traffic etc.
As for the lock-up from the AT interface perspective it is correct that you can't execute any new command until the previous one is finished. The network issues can sometimes take long due to TCP layer retransmissions etc. BTW you could try to modify tcpIrt, tcpMr, tcpOt parameters to see if it can improve the situation anyhow or not.
So from this perspective I agree that it is unfortunate that this whole server communication takes place inside the command. However if an attempt to send another command does not break this particular one, there's no other way to interrupt it. You can either reboot the module or try to do something on another interface like GPRS detach. You may also report this issue to your distributor. There is currently revision 2 of BGS5 module available. However you can't update the rev1 hardware, new HW is needed.
Best regards,
Bartłomiej
Hi,
Thanks for the reply.
I have asked for a network trace from our SIM supplier, but I am not sure this will help me as debugging at network level could take a lot of time and I need a working solution as soon as possible.
You mentioned that my BGS5T module might be an 'old' version and it has been superceeded.
Is there any way I can establish this from the module before asking my supplier to replace it?
Also, what is the procedure for establishing the latest available version of firmware for the module I have?
I have seen some discussion regarding firmware versions on this forum and there does not seem to be any reference on the Gemalto website to firmware upgrades and how to obtain them.
Incidently, the issues I have seem to accur when usndertaking REST calls via HTTPS. When I make calls using HTTP I have yet to experience the problem.
The module locking-up for 2-3 minutes is a major issue as my application requires that I make a POST once every minute.
Hi,
We now have a network trace (pcap file for Wireshark) and this is showing a very large number of TCP Retrasmissions during a session where we had issues with our POST.
I guess this could confim why the modem is stalling as you mention above?
I am not an expert of TCP, so I have hit my limit of what I an do get the BGS5T to operate reliably.
Do you know if there is any application engineering level support available from Gemalto beyond this forum?
I see there is a Gemalto office in Munich - this is close to our office where we are undertaking the testing on the BGS5T...
Hello,
For the new hardware you should find A200 instead of A100 as part of the ordering number printed on the module or terminal.
I can't see any update for your version.
As for retransmissions configuration you may try to modify tcpIrt, tcpMr, tcpOt parameters - you'll find detailed descriptions in the AT commands specification.
As for the support if you don't have access to SalesForce system you can report the problem to your distributor who most probably has. Or you can ask your local Gemalto/Thales M2M technical sales how to get it.
Best regards,
Bartłomiej
Hi,
Thanks again for the reply.
We looked into the network traffic from our modem using Wireshark and saw a high number of TCP re-transmits which confirmed a network problem as mentioned a number of time previosly in this post.
We are now testing an alternative SIM card provider (native home network in Germany where the modem is located, rather than roaming with a non German SIM card) and this seems to have resolved the problem without changing the default tcpIrt, tcpMr, tcpOt settings.
Our problem was complicated by the fact that the roaming SIM worked reliably in the BGS2T, but in this case we were POSTING to a diffrerent URL because the BGS2T does not support HTTPS.
As such, I think the problem has been resolved.
I do have one final question - is it possible to set multiple HTTP POST Header parameters via the AT commands?
The AT command manual states for hcprop (AT^SISS) "Multiple settings can be given separated by "\0d\0a" sequences within the string, do not put them at the end. " Does this mean that the string containing the header parameters should actually contain the \0d\0a characters, e.g.
at^SISS=1,"hcProp","Content-Type: application/json \0d\0a x-token: a token goes here"
Hello,
Thank you for this information. It's a good news that the operator change has hepled.
Yes, you can add settings to http header in hcProp parameter. The overall length is limited to 254 characters. The separator is \0d\0a without spaces. So your example could liik like:
AT^SISS=1,"hcProp","Content-Type: application/json\0d\0ax-token: a_token_goes_here"
Best regards,
Bartłomiej