C code server hacking - initial failures

[Peter Galbavy]

I am trying to get a lightweight C based server together that will run on my underpowered ReadyNAS NV+. The perl code by others (sorry, I am so crap at names) works fine but is very heavy on memory footprint even after converting it to use XML::Simple... 300MB for a 30MB RAW file kills the poor NAS.

So rather then ripping out the XML and HTTP modules from the perl script I started out with mongoose (a replacement for shttpd) as a web server and have build a small program to get the inital request and return the StartSession response. The credentials are correct - I test using a perl script that uses the core for eyefilistener.pl - and I have tried as hard as I can to emulate the precise HTTP headers and ordering that I have seen elsewhere. In the eye-fi log I simply get:

[35:05] Using probed IP address 192.168.234.234:59278 for agent.
[35:05] Starting to upload "/public/DCIM/100EOS1D/DCP_0075.JPG"...
[35:07] eyefilmGetPhotoStatus() SOAP RPC failed.
[35:07] Returning from upload function with error 357.

Can anyone point to perhaps a way of generating further debugging ?

Is anyone interesting in the PCAP files I have comparing the network traffic ? I even have the HTTP body part of the response the same size in bytes with only the credentials and the random snonce changed.

... I am going to give up now and watch some Blurays, my eyes are going blurred

[berend]

The credentials are correct - I test using a perl script that uses the core for eyefilistener.pl - and I have tried as hard as I can to emulate the precise HTTP headers and ordering that I have seen elsewhere. In the eye-fi log I simply get:

I would guess that there's something about the construction of your SOAP envelope that's incompatible with the firmware. I wish I could tell you that we have a very robust, fully standards-compliant XML and SOAP parser, but we don't, given the memory pressures within the card. That renders the error detection and reporting short of very robust. I can tell you that the issue here is not a credential mismatch, as that would be logged explicitly.

Have you looked at Michael's code at:

http://kin.klever.net/iii/

It's C++-based and lightweight, so it would probably server your purposes well.

Berend

[Peter Galbavy]

Thanks. C++ is not me... hence the C hacking. But I will take a look.

However, in terms of SOAP response, I have got to the point where the HTTP Body is *identical* byte-for-byte except for the hex digits in the credentials and snonce. The one difference is that the perl script seems to flush multiple packets while the mongoose response is delivered in a single 700-odd byte packet. I tried TCP_NODELAY to send each line in a packet in case it was TCP stack issues, but it's not.

I have given up for now, to save my brain, but I will revisit soon. I will check the C++ code out RSN.

[berend]

Peter,

I'll try to write more later, but I just noticed that it's the second of the "handshake" SOAP messages (GetPhotosStatus) that's failing, not the first one (which is StartSession), so your issue probably is not a fundamental transport and/or SOAP encapsulation issue.

Berend

P.S.: Is the server correctly honoring "Connection: Keep-Alive" header during the first request and allowing the second request to come in via that already-established TCP/IP connection?

[Peter Galbavy]

P.S.: Is the server correctly honoring "Connection: Keep-Alive" header during the first request and allowing the second request to come in via that already-established TCP/IP connection?

Probably not, now you mention it. I will have to look at how mongoose works to establish that. Once I get home, assuming the tube strike in London doesn't wear down what little energy I have at the end of the working day

[Peter Galbavy]

"D'oh!"

Big dumb me. Looking at the mongoose code quickly online, it becomes obvious that the *default* behaviour is no keep alives... http://code.google.com/p/mongoose/sourc ... mongoose.c

I will start again tonight with the "enable_keep_alive" option on

Thanks for that. I reserve the right to be stupid here in the future, however...

[Peter Galbavy]

OK, "enable_keep_alive" was the right thing to do - except this also uncovered a minor bug in the mongoose code (diff submitted there). Now it's getting onto the next request in the chain and I should be able to proceed quickly I hope.

[phedders]

Hey Peter how are you getting on with that code... more than justa little curios!

[kevint]

Hi Peter,

I have been working on a Java version for the past few days, that I can use as a standalone Java server, or embed into an Android application. I could not get past the SessionStart request/response until a few minutes ago, after reading this post. I changed to support connection keep alives, and all of a sudden I was getting to the next step in the protocol, which is GetPhotoStatus. It was a frustrating day yesterday trying to get past this part. So lesson learned...the connection keep-alive is definitely required.

Good luck...

-Kevin

[Peter Galbavy]

Going to start revisiting this soon, so if anyone has made any of their own advances (I am personally only interested in coding in C, but anything is good) please post!