Wifly HTTP POST

Hello, I’m trying to POST some data to a web server but I’m not able to send the proper POST message and I was hoping someone could help me narrow the issue down because I’m stumped.

I’m using a wifly library I made in the past. But as you’ll see this isn’t really a library usage question, but a wifly hardware usage question (or maybe a Sc16is750 configuration question).

Things I’ve tried:

I can use telnet and send the HTTP POST message and everything works as expected so I know the text I’m sending is well formed and that my web server is working properly. When using the Arduino & Wifly shield I run into issues after I issue an open command (“open 192.168.1.101 80”). I do get a message saying the connection has been made (“Connect to 192.168.1.101:80”). It seems whatever path I choose after this results in failure. The wifly stays in command mode after the open command (which I assume is normal) so any text sent for the post message is interpreted as a command. And since “POST index.php HTTP/1.1” isn’t a command there is a syntax error. So I assume I need to exit command mode to send the POST message. But if I exit command mode to send the POST message it acts like my web server code never runs. I have my webserver create a dummy file when a connection is made and since no file is made I’m assuming the message never gets sent.

And I can successfully ping my webserver with the wifly using the “ping” command so I know the connection is not blocked.

Do I send the POST text while still in command mode? Ex:

<2.18> open 192.168.1.101 80
Connect to 192.168.1.101:80
<2.18> exit
EXIT
send_string( "POST /index.php HTTP/1.1\r\n" );
send_string( "Host: 192.168.1.101\r\n" );
send_string( "Content-Type: application/x-www-form-urlencoded\r\n" );
send_string( "Content-Length: 6\r\n" );
send_string( "\r\n" );
send_string( "Test=1\r\n" );

or

<2.18> open 192.168.1.101 80
Connect to 192.168.1.101:80
<2.18>
send_string( "POST /index.php HTTP/1.1\r\n" );
send_string( "Host: 192.168.1.101\r\n" );
send_string( "Content-Type: application/x-www-form-urlencoded\r\n" );
send_string( "Content-Length: 6\r\n" );
send_string( "\r\n" );
send_string( "Test=1\r\n" );

If the second how do I avoid the wifly from interpreting the “POST…” data as a command?

Do any of you have suggestions as to how I can debug what text is sent out of the wifly when not in command mode? Like some sniffer or something? I’ve no experience in using one, but I don’t mind, I just wonder if a sniffer will tell me anything.

A quick update: Apparently after cycling my wifly it is working as expected now. But there are still issues I’d like help with.

First to answer the question, as soon as the wifly makes a connection from the open command (should see OPEN) on the uart, then all data sent subsequently gets sent through the tcp connection. So there is no need to explicitly exit command mode before sending the data.

Now I’m able to use ncat and I can listen and verify that the wifly can connect to a local port on my laptop and send valid data. But my webserver (and posttestserver.com, and my true offsite server) is not picking up the data sent, saying its a bad request. I’m currently using a network analyzer to see if I can see any reason why the webserver isn’t picking up and processing the requests.

Ok, thanks to some packet analysis I’ve found my error. Turns out there was an optimization I was doing in my low level wifly library which was actually causing a ‘0’ to be sent before all my send_string() commands. This is solved now.

You have an old and quite buggy version of the firmware, so you are virtually guaranteed to run into more problems. It is up to 2.38, last time I checked.

jremington:
You have an old and quite buggy version of the firmware, so you are virtually guaranteed to run into more problems. It is up to 2.38, last time I checked.

Yeah, I’ve tried to update the firmware but it always times out. Back in August they changed the ftp server apparently and their new instructions for updating aren’t working for me (http://www.rovingnetworks.com/FAQs/I_ge … Fly_module). Both the default ip and their dns method are failing. I can’t even telnet to it or connect with a standard ftp client. Not sure if I’m hitting the wrong ip or what.

Do you know the current ftp location?

The instructions on that site worked for me a month or so ago. Call Roving Networks.

TylerRDev:
Yeah, I’ve tried to update the firmware but it always times out. Back in August they changed the ftp server apparently and their new instructions for updating aren’t working for me.

Things got pretty messy for a while after Microchip acquired Roving Networks. This is the commands the Microchip FAE's are currently recommending:
set ftp address 198.175.253.161
set ftp dir ./public
set ftp user roving
set ftp pass Pass123
ftp update wifly7-238.img