I tried to test/check can I use WIPSoft AT commands for FTP/HTTP … on the Q2406B device.
I did not expect any problem … since I used simple/stright forward sequence … but I still cannot manage
to prove that it works
I’m using: Q2406B/E device and SDK V3.21 (including WIPSoft 3.10.1034)
I performed the following tests:
FTP download works, but ONLY when I set FTP server to PASSIVE mode.
In active mode … it seems that works (I am receiving CONNECT) … but there is no data received?
In one word, it seems that FTP DATA port it is not properly (or on proper time, since FTP connection must be created
first, and then to change option to active mode) negotiated with the FTP server.
For HTTP (using default HTTP 1.1) Get I am using the following AT sequence:
AT+WIPCFG=1
AT+WIPBR=1,6
AT+WIPBR=2,6,11,“apn”
AT+WIPBR=2,6,0,“user”
AT+WIPBR=2,6,1,“password”
AT+WIPBR=4,6,0
AT+WIPCREATE=5,1
AT+WIPFILE=5,1,1,“http://xxx.yyy.zzz.vvv:80”
CONNECT
… data (but NOT ALL)
OK
WIPFILE: 5,1,1,200,“OK” Everything seems fine … but problem is that data (about 300 bytes in this case, but also for the other different HTTP pages)
from the beginning are missed!!! In other words, starting X bytes of data are LOST!!! I am confusing, since I can
understand that something is wrong at the end/middle (because of buffers), etc …
Even my intention was not to “go inside” Open AT WIP development, in order to investigate this issue … I got
WIP http_get sample, compiled it (with my HTTP server IP) and ran. And it WORKED FINE, i.e. starting bytes
are RECEIVED (not lost) !!!??
Please help me - what I did wrong with AT commands???!! I cannot beleive that it would be a bug, since it is
basic functionality, very obvious during common testing process.
Please help me to use AT commands for this strightforward functionality …
I just tested the same HTTP Get method example, and I have the same problem : first bytes of the answer are lost. I’m still trying to figure out what happens !!! Did you finally find out ?
Unfortunately … I did not solve this problem
About 300 bytes (or so) at the beginning are just NOT transfered to the serial port. If I ‘hit’ longer page … rest of the page is received normally.
The FTP works, and HTTP get doesn’t work.
After some time without any replay and without new ideas … I tried HTTP GET example (included in WIP samples, using wip API commands - not AT commands) and it works normally.
According to this, my conclusion is:
there is some bug in wrapper functions (between wip API functions and wip AT command implementation), since used wip API commands works correctly
but unfortunately, I cannot fix this bug (WIP AT source files are not available) … and nice WIP AT plug-in that simplifies device usage … cannot be used.
I just contacted my manufacturer’s support, and they said it was the first time they hear about that problem. Now I must send them more infos and the example code so they will try to reproduce the problem on their side, and investigate.
Thank you. I am really interested to ‘see’ explanation, since (according to the behavior) seems that elementary HTTP GET connection
is never tested (never tried, because it is not some hidden detail)
I did not beleive that it is the case … and I spent a lot of time, trying to see what I did wrong.
Eh, thank you very much for that info !!! According to mkatic’s experience, I was suspecting a bug in the firmware, but I was still discussing that with my manufacturer’s tech support (they managed to reproduce the error, but seemed kinda puzzled)…
Well, now all I have to do is get the latest version of WIPSoft (I requested it to my manufacturer yesterday, still waiting for their answer)
The first of all, thank you for your kind words (that you belive me that it is bug)
Actually:
I really used V3.21 (of course it is OpenAT version) and WipSoft included there
Since it was blocking issue for this what I tried to do … and since there were no solution for a long time … I forgot
this, and move forward in other direction.
In any case, thanks a lot for your kind help.
P.S. Anyway, it will be nice to know what was the problem.
OK, once again I’m lost… Seems I’m easily confused when it comes to Wavecom !
mkatic, when you say you used v3.21, I guess you refer to the SDK version, as mentionned in your first message. This SDK includes WIPSoft v3.10.1034… When magnus talks about v3.21, he means WIPSoft v3.21 : don’t get confused between the version of SDK and the version of WIPSoft.
I just downloaded SDK version v3.21 from Wavecom’s website, installed it, and upgraded my modem’s firmware to version 6.57g00 : but this firmware still includes WIPSoft v3.11 (which is the version I had yet with my old firmware), and not WIPSoft v3.21. In the download section of Wavecom’s site, you can find the PDF about WIPSoft v3.21, but I didn’t manage to get the DWL to upgrade to that version.
Can anyone tell me where it’s hidden ? (most probably it’s just under my nose)
I was also confused with these numbers I saw that WipSoft V3.21 is mentioned on the web … but since I did not found it to download (like you), and since it is too big difference
between 3.21 and 3.10 (11 versions!) … I concluded that when they are talking about WipSoft V3.21 (in some documents) it is actually related with the WipSoft included in SDK version V3.21 (and WipSoft version is actually 3.10.1034 … or similar).
It’s very strange what happended to you, I was using WIP soft v3.11 on Open AT OS v3.13, and WIP lib v3a05 WIP soft v3a02. I think that I have older version and I get full html pages, even greater than 1kb.
The problem I got is that after sending 10 or 20 times GET Request I got: “+CME 846: internal FCM subscription failure”, but web page “counter” seems like I visited the web page, but not returning any html answer, the only way I repair this problem is making software reset sending AT+CFUN=1, not the better way but the only I found.
Maybe your WIPCREATE and your WIPFILE for HTTP GET is wrong. I’ve been working on it and I think this is wrong:
Maybe it’s the same result, but what I do is this:
AT+WIPCREATE=5,1,“http://xxx.yyy.zzz.vvv”,“80” (or “http://myurl.com”,“80”)
AT+WIPFILE=5,1,1,“http://xxx.yyy.zzz.vvv” (not with “:80”)
CONNECT
… data (I’m receiving long and full html pages, with all data I need)
OK
+WIPFILE: 5,1,1,200,“OK”
I think that maybe it’s not better, but you get more stability because WIPCREATE define the HTTP port, or remove it from WIPFILE because the default HTTP port is 80.
According to 
