Arduino Forum

Using Arduino => Networking, Protocols, and Devices => Topic started by: liuzengqiang on May 13, 2013, 08:02 pm

Title: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 13, 2013, 08:02 pm
As a very senior member of this forum, I usually refrain myself from ranting in a subforum other than the bar/sport but this is going to change for the Arduino WiFi shield R3. It is an expensive piece of DIY hardware but has so much unfinished business that has made my time very miserable. I tried to work around its limitations but would like to warn any newcomers of these before you make your purchase. If you have experience that is very opposite of mine, please be sure to share.

(1) Here we go. The version control of this product is horrible! The Arduino WiFi shield is not just a shield. It contains at least two (if not 3) microcontrollers that run programs just like Arduino itself, but more complex. The operation of the shield depends on the operation of these firmwares AND your Arduino WiFi library. I found that there are many versions floating around, both firmware (coming with the product and updates) and library (Arduino IDE 1.5, and other places). One library that dates 1/19/13 works with my shield R3 out of the box but the library in Arduino IDE 1.5 fails to work. Then I had taken a chance at updating firmware 3 weeks ago (late April) that crippled one shield. It was able to connect to router but can't contact any servers while the other one without upgrading was. Then I encountered a major hurdle described in (2) but I will deb into it here. There is a hard limit on the size of string you can send with client.print, being around 90 bytes. Anything longer will not make it to the server or client at all. I contacted Arduino team and was told it was already resolved while back and I just had to flash firmware and use the "latest" library. OK, as of today (5/13) I went to github and was only to download the entire arduino master (no button for just wifi stuff). The download yields the firmwares and library. Again there is no version number or which dated library is compatible with which dated firmwares. I tested the new library with known working code and server. It was a go for the upgraded shield but no go with original R3 shield. Notice the situation has entirely flipped. What the heck?! Can someone maintain library version numbers and post readme on what version of lib works with what version firmware? I guess answer is NO.

(2) As I said, the client.print has a hard limit at 90 bytes. I sent 92 bytes and more per print and it simply doesn't appear on the other side regardless which role Arduino assume (server or client). I was told it was solved with the latest stuff but not. How can I trust them with this firmware/library if the problems they claimed to have been solved is still there?!

(3) Firmware upgrade is difficult even for me, a "veteran", and no description on what the indicator leds should do and length of time taken to do the antenna firmware. It just needs to be rewritten or videotaped for clarity.

(4) Sample code not working. Just search forum for "wifi shield not present", you see too many of those popping up, why? Sample code is not working. All sample codes does one time check on wifi shield presence and if not presents, hangs the program. I don't know how quickly the wifi shield boots up but I had a very hard time pinpoint the solution to this problem until I added delays such as:

Code: [Select]
  // check for the presence of the shield:
  unsigned long start=millis();
  while (WiFi.status() == WL_NO_SHIELD)
  {
    if ((millis()-start)>30000)
    {
      Serial.println("WiFi shield not present");
      // don't continue:
      while(true);
    }
    delay(500);
  }


Shaky original code:

Code: [Select]
  // check for the presence of the shield:
  if (WiFi.status() == WL_NO_SHIELD) {
    Serial.println("WiFi shield not present");
    // don't continue:
    while(true);
  }


Maybe this problem is solved by "latest" updates but it was never mentioned anywhere that you may want to wait up on the shield. It normally takes a bit time to boot up from power cycle but maybe quicker from reset.

I have heard good things about other wifi products but thought I should stick with Arduino team due to their support and forum support. My while Arduino WiFi R3 experience is making me flip. Maybe the Team is hitting hard walls trying to maintain too many things? Maybe 3 microcontroller (arduino+2 on wifi shield) is the theoretical limit of open source hardware/software since three things and the result not working implies too many possible errors to solve as open source lacks paid technical support and enough competition?!
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: P18F4550 on May 13, 2013, 09:03 pm
Yay open source,

If time was taken to design and produce a reliable product someone else will rip it off and sell it cheaper, so, an idea is had, rushed into production with the idea of clearing up loose ends later with updates and bug fixes.

What is arduino anyway, it's really just the IDE, the boards are just carriers for the Atmega range of chips with the pins broken out into a standard form factor.

"Arduino" the concept should be for even the greenest of noobs to plug in the lcd shield and it work first time, even that doesn't happen with too many 3rd parties making shields with their own libraries and pinouts.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: JohnHoward on May 14, 2013, 01:36 am
Ouch, particularly for such a high-ticket item.  Is there not a formal test suite for pre/post release testing?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 14, 2013, 02:27 am
What I wish they had were function calls wifi.lib_version() and wifi.firmware_version()
They don't implement version control and don't announce when a new version is out then it will be a chaos. Think about how to help a newbie with "my wifi shield is not working " problem.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 15, 2013, 12:05 am
pylon found source of the 90 byte limitation:

http://forum.arduino.cc/index.php?topic=123824.msg1239932#msg1239932
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 15, 2013, 07:57 am
The reset circuit is also buggy. After the server crashes, you can't reset it with reset button. You need to yank the USB cord to power off the shield and then power it back on to detect it again. An the server does get screwed up from time to time. The arduino keeps running, it just no loner do you anything with WiFiClient client=server.available(); The return is no longer valid connection.

Also, after upgrading to the "latest" firmware and library, only my Arduino MEGA R3 with the extra headers (SCL SDA Vref) can detect the shield. My MEGA1280 and MEGA2560 are not able to detect the same shield with the same sample program. According to their diagram, none of these is connected to anything on the shield. Then it might have something to do with the different reset circuits across revisions?!
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on May 15, 2013, 03:27 pm

What I wish they had were function calls wifi.lib_version() and wifi.firmware_version()

^^This

I can't agree with the other points in your rant though.  The only problems I have had with my official WiFi shield, are of my own making.  It was very unreliable, until I read the manual properly and stopped trying to use the SPI pins for I/O.  My initial attempt to port Apache to the Arduino didn't go too well either.  I am used to coding for full sized servers.  Trying to overcome the challenges of processing indeterminate length strings, in just 2KB of RAM, has usefully reminded me how much protocol stacks are taken for granted.

Yes, I would agree the shield can appear to be fragile.  Any whiff of a buffer overrun and it will crash.  Whether there are other WiFi shields which are more resilient at similar cost, I can not say.  I have lost count of the number of times I read good things about something, only to find lots of bad things which had not been mentioned, after I shelled out.

I really disagree with the bad because it's open source propaganda.  Perhaps because I spend my day job running business critical web, e-mail and application servers, built on open source platforms.  I also have to deal with the commercial brands and they are, in my opinion, far worse when it comes to releasing unfinished products, relentless patches and imposing upgrades of dubious benefit.

With any Tom, Dick or Harry able to fork off their own prototype, publish it on Google with claims it will shift your paradigm, there are bound to be a few open source lemons around to avoid.  Such does not prevent World beating projects being open source projects.  I am too knew to Arduino to say which it is but I am extremely impressed to date.  I have no problem paying just a little more to support the Arduino project, above the cheapest boards I could find listed on e-bay.

YMMV.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 15, 2013, 05:44 pm
Hey Matt,

Thanks for your input. I'm glad that you're alright with your arduino wifi shield (no 90 byte limits?). I should modify my remarks on open source hardware/software a bit to point to the open source hardware that involves microcontrollers and their firmware as the software, plus supporting library. I never meant to point fingers to open source software in general but now realized I did do that with my statement. The open source software that you know of (I don't have your web server experience) is very different from Arduino. With Arduino, you hardly find any documentation of a library beyond basic function calls and simple examples. Most of the basis is not covered in any of their library doc. They don't use doxygen (like AVR library) or other methods like that to document functions so it is left for the users to figure that out. This is probably different in open source software in general. Lots of them are well documented to what each knob does when you turn it 90 degrees to the right under what condition (or state). Arduino has none of that. If you run into the grey area of undocumented states, you figure out the outcome yourself by reading their code. This is not very nice. If you then have the wifi shield or the like, where there are multiple firmware with none of these grey areas explained, you are bound to fail critically when not all stars are lined up in your night sky.

I admit I'm creating my share of problems with my programming, but when the wifi server is stuck and a push of reset button won't bring it back to square 1, then I'm out of ideas how to pragmatically prevent crashes. So I still speculate that the critical point of open source hardware/firmware is 3 microcontrollers, not in star topology but in hierarchy. Say MCU 1 commands/depends on MCU 2, which commands/depends on MCU 3, all of which run software/firmware. I speculate this as the breaking point of Arduino. It's like three lost buddies in the woods all wandering around to find one another. How often do they all show up at the same place? Say you have 95% chance to depend on MCU 1 to work correctly (world not perfect), then all these piled up to (0.95)^3=0.86=86% with 3 MCUs. If you only have 85% trust on any one of these pieces, from your own experience, the final is down to only 61%. My trust on this wifi shield is somewhere below 85% on the Arduino firmware, say 75%, maybe 95% on the antenna firmware, but maybe only 75% on my own code combined with the arduino side of library. My outcome is 50% so fifty-fifty. That is what I feel about my project overall. Reminder, all the undocumented grey areas, such as, if a client disconnects before the complete message is read with client.read(), will client.available() still be true since the shield has buffered more bytes of the message than Arduino has read? In Arduino world, only perfect situations are explained, but, what if I push the "X" on my browser to stop transmission/connection? I'm left to find that out myself.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 16, 2013, 03:14 am
I'd like to add the original WiFi shield R3 (unknown firmware version) and original library (dated Jan 2013, again no version number) are better. See what I got here:

http://forum.arduino.cc/index.php?topic=166592.0

The newest firmware and library seem very unstable especially with iOS clients. Crashes every time. With original version there is no more crashes described by that post.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: graynomad on May 16, 2013, 09:35 am
Documentation is one of the most neglected fields IMO, probably because not many people like doing it at any time much less at the end of a project when you want to get to the next fun thing.

I'm one of the few that actually enjoys documenting things.

______
Rob
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 16, 2013, 11:47 am

Documentation is one of the most neglected fields IMO, probably because not many people like doing it at any time much less at the end of a project when you want to get to the next fun thing.

I'm one of the few that actually enjoys documenting things.

______
Rob


Then we share more than just a hobby in Arduino! I recently started writing very detailed work log, well, not for money or contract or anything, but to document my learning process for my next big thing, arduino server project for a web based cross platform graphical user interface. I have grown to like documenting when I realized I can't possibly remember everything I did the day before. Lots of time I delay library release because docs aren't perfect ;)
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: sonnyyu on May 16, 2013, 05:57 pm
For people are looking for alternate for Arduino WiFi shield;-

We have few threads about it:

Replacement of Arduino WiFi shield - WIFI router(openwrt compatible), Pogoplug,  Raspberry Pi .

http://forum.arduino.cc/index.php?topic=146342.msg1110225#msg1110225 (http://forum.arduino.cc/index.php?topic=146342.msg1110225#msg1110225)

WIFI router Tp-Link  WR703N for Arduino

http://forum.arduino.cc/index.php?topic=149865.msg1126278#msg1126278 (http://forum.arduino.cc/index.php?topic=149865.msg1126278#msg1126278)

WIFI router Tp-Link  TL-WDR3600 for Arduino

http://forum.arduino.cc/index.php?topic=148392.msg1116815#msg1116815 (http://forum.arduino.cc/index.php?topic=148392.msg1116815#msg1116815)

Pogoplug for Arduino wifi and even housing and power supply

http://forum.arduino.cc/index.php?topic=158832.msg1191296#msg1191296 (http://forum.arduino.cc/index.php?topic=158832.msg1191296#msg1191296)

The bottom line is to start testing wifi with Arduino , all you need is used/junk PC plus few dollar wifi usb stick.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on May 17, 2013, 12:13 pm
Hi Luidr

Thanks for the welcome and my apologies for taking a whiles to get back to you.

Documentation, I think it is always a balancing act between too much information and too little, for the target audience.  I would prefer to see a little more detail but I am 40, not 14.  I might, being kind, describe the Arduino docs as refreshingly sparse ;)  The docs are too the point and they say, what they say, very clearly.  In some ways, that makes the documentation better than having reams of  distracting information to sift through.

Completely agree reflashing the WiFi shield is a pain in the behing and needs a method to verify which version is on the shield.   There is a function in the library but mine is still returning V1.0.0 after I thought I reflashed it.  I couldn't find any command for the Atmel DFU which would just report version either.  I guess I am just going to have to fork out for an FTDI cable, just to check the version.

As for the WiFi shield.  I very quickly lost any expectation that it would 'just work' after my first  experiments.  I could have blamed Arduino but instead, I sat back and had a little think about what I was asking my tiny Uno board to do.  I don't think it is so much the shield might be shoddy, as cramming a Wifi stack, IP stack and DHCP, DNS clients onto an MCU friendly board, is a fundamentally difficult thing to do.  When I bothered to think about it, it turns out implementing a web server on an MCU is a pretty big ask.

I can't really say why Arduino have arranged the hardware as they have but the hierarchal arrangement mirrors how network protocol stacks are implemented.  In a PC or Mac, the WiFi adapter only looks after the datalink and physical layers, with the rest of the stack residing within software drivers and APIs.  Even the cheapest of cheapest WiFi routers has much more RAM and a little more runtime available to it, than an MCU.

I had a quick scan through the code on the thread you posted.  I don't know whether this will help you but it is just what has worked for me.

I had some issues with the board crashing when I tried to run the serial at top speed.  I am guessing that the MCU is being starved of run time.  The crashes stopped after I dropped the serial rate to 9600.

The reset button has locked me out ,once.  When I looked at my code, it was entering a tight loop, polling a pin.  A rearrangement of the code, to avoid needing the loop and all is well.

The WiFi shield has occasionally refused to start but only immediately after uploading a relatively large sketch.  Press of the reset button and all is well.  I am not losing sleep over it, because it is a failure mode which should never happen in production.

By far the most common cause of my code crashing, has been buffer overruns.  If there is a 90 byte limit, I have yet to trip over it because I have been too busy learning to manage my Uno's memory more efficiently and dynamically.

The way the example web server sketch implements HTTP, is plainly wrong.  It works as a proof of concept but enters the realms of undefined behaviour, as far as the HTTP spec is concerned.  The example is all a bit confused really.  It declares a response as HTTP/1.1 and proceeds to behave as HTTP/1.0

To be perfectly honest, implementing a web server is probably the worse first network project anyone could pick, because there is so little RAM to buffer requests and responses.  HTTP is an extensible protocol but it is an extremely vague protocol because of it.  It would be much easier to write a raw sockets application with the application protocol designed to fit the limitations of the device.  That wouldn't suit what I have in mind though.


Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 17, 2013, 07:20 pm
Thanks Matt,

I have thought about making an MCU web server might be a difficult project but with my background using MCU and C++ I took on it and think I did it with acceptable results. The server will serve only .htm, .js, and .csv files. It translates .js files according to a rule I implemented so that the static web page gets dynamic contents through running the .js file :) I implemented all possible buffer overrun guards (so the server is easy to anger and spits out 404). Soon after I switched to the original R3 (no firmware upgrade) and kind of original library (I have no idea of the version, dated january 2013), the server has been running well for 3 straight days, serving static htm pages with .js files for dynamic content. I can even access it from external network using the router's external IP address. All is well (but the same can't be said with the "latest" firmware + library). I think by adding UDP service in the latest thing they created some issues in the firmware or library. Please take a look at this post, where I "solved" the problem of latest stuff won't work with iOS by reverting to original R3 and lib:

http://forum.arduino.cc/index.php?topic=166592.msg1241413#msg1241413

BTW, I am using MEGA 2560 (8K SRAM) and could slap on a QuadRAM for up to 512KB SRAM. I didn't. I have about 4.7K free ram at the moment, which can further increase after I auto-gen some code with strcmp_P to compare strings with ones in PROGMEM instead of SRAM :)

For you to see if the 90-byte limit exists, just do a long string like:
Code: [Select]

          client.println("HTTP/1.1 200 OK"\r\nContent-Type: text/html"\r\nConnnection: close\r\n\r\n<html>Just a test to see if wifi shield can send a message longer than 90 bytes.</html>");


The above message is about 160 bytes long. You would expect this will not work. According to member pylon, who looked at the firmware, there is a 100 byte buffer on the wifi MCU and it refuses to send if the message becomes longer than 90 (plus overhead will exceed 100).

BTW, the reason I use HTTP is the existing browsers in every mobile device. I don't have to write a GUI, just need to draft a web page. I think it eventually pays off, if I can make the server into a nice finite state machine.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on May 22, 2013, 11:15 pm
I agree that the WiFi shield is not ready for serious projects.  I bought three of the shields for a project that requires stability and reliability.  I run the webduino web server shell and the 1/19/2013 WiFi shield firmware.

One shield consistently runs 10 to 20 days and then crashes.  Another with the same software/firmware goes 3 to 5 days and crashes.  I bricked the third one trying to update the WiFi_dnld firmware and have not been able to figure out how to recover it.  When I run the procedure for updating the firmware from the Arduino web site everything seems to go successfully, but the shield only puts out a red error signal on its led instead of connecting to the LAN.

Also, if there is a power failure my LAN router takes longer to recover than my arduino/WiFi.  If the LAN is not ready when the arduino is powered up, the WiFi shield never connects to the LAN.  Likewise if the LAN drops out without a power failure the WiFi shield loses connection and never recovers.

Ditto on the comments regarding lack of revision control or even being able to figure out what the revision levels of the various softwares and firmwares are. I have to keep a notebook with the revisions since I cannot digitally read that information from the board.

Also, there seems to be no way to restart the WiFi shield with anything like a watchdog once it drops connection.  The only way to know it has failed is that it does not handle remote requests.  At that point I am 100 miles away and can't reboot.  So my simple fix is to reboot it once a day with a mechanical lamp timer.  Doing that, I cannot store any volatile variables in the SRAM for more than 24 hours.

Hopefully this mess will get straightened out by crowd action.  In the meantime my project is on hold because the WiFi shield does not operate stably.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 23, 2013, 12:01 am
fpga6,

Thanks for sharing your experience with me. I for a while I thought I was the only one bothered by various things around this hardware and everyone else is happy.

If you try the basic web server sample code, how long will it take to crash/fail to accept incoming connection? I have not tested that long of a period. I only tested my own web server code for up to 3 days with occasion access from my mobile devices and various PC browsers. I wonder if there is any instability within webduino, which I have not used yet. Plus, have you noticed that once the call to server.available() takes more than a millisecond, rather 25ms, the server has failed to accept any incoming connection? I found that to be very consistent but that was with the "latest" firmware. I was successfully updating the firmware, not so lucky during the first few tries.

What about your experience with wifi shield being a client? My work depends on the wifi shield being a client, not yet server.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on May 23, 2013, 01:54 am
liudr,

I am somewhat new to WiFi shield, but here are my observations:

I have only run in server mode, not client.

1. I tried sample code and had a lot of trouble when I created my own simple denial of service attacks.  I have three computers and would hit the send button simultaneously.  Usually I could lock up the WiFi shield in a few tries.  That code uses server.available() but I did not do any real time testing of that call.

2. I found an forked wifi version of webduino on github and used it as my basic webserver.  Then I modified the webduino web server code examples in the webduino repository for WiFi instead of ethernet.  This was very easy.  This setup was much more robust, but still crashed after a day or so.

3. Then I reflashed the shields with the WiFiHD.hex update that went on github on or about 1/19/2013.  I thought there was some improvement.

4. In the third week of February 2013, the webduino code got a bug fix that also improved the crashing.  Now I am able to get 10 to 20 days of operation with my best setup.  That's great, but I have not figured out how to debug something that only fails every 20 days!  I don't know if my remaining problem is webduino related or shield firmware at this point.  I have been sitting it out for the last two months to see if something else popped up in the community that might be the final fix.

5. I have not gone back to the basic sample code to see if the firmware update improved crash frequency on that.  I picked webduino because it did a good job of handling "post" inputs which I wanted for remote control of some lights.  I can't use a static server that only returns data.  Also, webduino is a "black box" shell that isolates me one level away from having to deal with the ins and outs of controlling the WiFi shield directly.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 23, 2013, 05:04 am
fpga6,

If I have time I will test my own server code with the original R3 shield. I only had 3-day test periods. Any chance that you are using String class? I think webduino is not using String class. From a quick glance, it seems to be a library you can use to dynamically construct a web page that embed your arduino input values and control arduino outputs. I have a totally different approach to arduino web server so I won't be using webduino much. What I do is a bit of a place-and-switch. I will create a static web page in an HTML editor, then ID all key elements that may be filled with values determined by arduino readings. I then embed a JavaScript to update key element values at the end. It's a huge time saver when it's initially set up. I'm still testing though :)
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on May 23, 2013, 05:38 pm
liudr-

I believe webduino does support string function.

They have these two inclusions in the source code:
#include <string.h>
#include <stdlib.h>

I have read that there were some bugs when using strings in the arduino IDE, but I don't know if that has been fixed.

My code uses simple strings and I have not had any problems with them.

My web page is pretty simple and therefore easy to directly write in HTML.  I have tried using a web page editor, but they put out so many lines that I would have had to implement in a way that webduino could handle that I thought direct writing of HTML is easier.

Currently I am running mega2560 arduino because my program code is 44K size.  I have lots of libraries for real time clock, webduino, and other functions.  have not tried to squeeze it down for Uno because I also wanted the additional pins of the mega for future expansion of the project.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 23, 2013, 09:43 pm
The string.h is entirely C-string so should be safe. You want to watch out for the String objects with a capital S.

Just curious, if you hit refresh, how long does it take to reload the page? A second or two, or tens or seconds?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on May 24, 2013, 12:27 am
Refresh = 5 seconds from 100 miles away.

Thanks for the advice on strings.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on May 24, 2013, 12:54 am
Thanks. That is pretty acceptable delay. Mine is in local network and takes up to 4 seconds.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: rsweeten on Jun 18, 2013, 11:57 pm
Glad I found this thread. I've been googling "arduino wifi shield [replace with some form of fail language here]" all day. I'll read the whole thread in a bit, but suffice to say, my new WiFi shield simply will not accept clients in server mode or establish client.connect() when in Client mode using the examples that come with the IDE. ever.

Updated the firmware, using 1.05 version of the IDE, and have been scouring the source code for clues as to how the Libraries are actually working since none of it is in the docs really, but if it's really just about stabbing around in the dark for several more days, I think I might just try another system. I think I saw some links up there somewhere.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Jun 19, 2013, 02:37 pm
This may show the limits of open sourced products.  Unlike a commercial product nobody is responsible of an arduino product does not function.  So they can continue to sell these wifi boat anchors for $90 without risk of market or legal forces.

I have three of these boards.  The most recent one has been flashed to current firmware.  When I compile a web server using the 1.05 environment it just does not work, even using the demo sketches from the arduino web site.  It connects to my LAN, but does not respond to any way to a browser connection.

Since nobody is responsible for making the product work, nobody has to fix it.  I think the original intentions were good, but the wifi shield is just beyond the capabilities of the arduino team.  They have no real support for the wifi shield and no channel for real reporting of customer issues.

Let the buyer beware.  Arduino is a product for hobbyist toys, not serious projects.  We should think of it that way. 
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: sonnyyu on Jun 19, 2013, 03:17 pm
An other alternate for Arduino WiFi shield;-


I really like the price and form-factor of the CC3000 WiFi module   http://www.ti.com/product/cc3000

and I REALLY link the concept of SimpleLink for a headless embedded device  http://www.ti.com/ww/en/simplelink/

...


http://www.ti.com/product/cc3000#samplebuy (http://www.ti.com/product/cc3000#samplebuy)

Can't beat price, free sample.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Jun 19, 2013, 06:02 pm
I think Arduino team should learn a bit from Adafruit forum. There they have support sub forum for their products so you post there to get some help and the help often comes in time for me. I am currently happy enough with wifi shield R3's stock firmware (not upgrading anymore).

fpga6,

If your server sketch fails, will a client sketch work? If the client sketch doesn't work either, you may need to re-flash (instructions were not given 100% clear on flashing). I did that and broke one shield but later fixed it by flashing properly. You first flash the antenna firmware and then remove flash jumper and power up the shield and wait a few minutes (hopefully enough to get the firmware to flash the antenna firmware. Then you put the jumper in and flash with wifiHD firmware. Did you miss the step to remove the jumper and power up?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Jun 19, 2013, 06:07 pm
fpga6,

From a different point of view, you may want to try a raspberry pi. The pi is a full-scale computer running linux (had to learn from beginning 2 weeks ago). You are taken care off by the vast open source software community with linux and supported wifi hardware list is long and detailed. Programming is more involved (depending on your background, certainly is more involved for me with no unix programming experience other than a school project to write an FTP server). On the other hand, you reduce the number of open source firmware to 1:
pi runs standard linux software well supported by huge community. You just rely on arduino firmware and some libraries. The total cost is likely less than getting arduino + wifi shield. If I had more unix programming experience I'd switch away from arduino + wifi model and just slave an arduino with a pi. You let arduino do all time critical work and pi process stuff and connect to internet.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: jacksons on Jun 19, 2013, 08:17 pm


Code: [Select]
  // check for the presence of the shield:
  unsigned long start=millis();
  while (WiFi.status() == WL_NO_SHIELD)
  {
    if ((millis()-start)>30000)
    {
      Serial.println("WiFi shield not present");
      // don't continue:
      while(true);
    }
    delay(500);
  }


Shaky original code:

Code: [Select]
  // check for the presence of the shield:
  if (WiFi.status() == WL_NO_SHIELD) {
    Serial.println("WiFi shield not present");
    // don't continue:
    while(true);
  }



even better code:
Code: [Select]

void setup () {
     Serial.println("WiFi shield not present");
     while (1) {}
}
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Jun 19, 2013, 10:44 pm
To be fair, Arduino detects wifi on my systems almost every time since I implemented the 30 second wait. I have 6 identical systems using stock R3 firmware. I could make it more stable if I single out the wifi reset pin and drive it with an arduino pin so if the server is stuck when wifi signal is lost, arduino can reset wifi shield.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Jun 20, 2013, 12:29 am
liudr,

I have been using the procedure for Windows that appears on the official arduino web site at:

Quote
http://arduino.cc/en/Hacking/WiFiShieldFirmwareUpgrading


It does not mention any power up / insert jumper step between flashing wifi_dnld.elf and then flashing wifiHD.elf.

Is it possible that the official directions for flashing the shield left out a step??   :)

How are you applying power to the shield?  Are you just leaving the usb cable plugged in while jumping and removing the jumper?

fpga6
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Jun 20, 2013, 12:42 am
I followed those steps and didn't get a working shield afterwards :)

I then inserted that extra step and the flashing worked. I use usb cabel to power my shield and disconnect it from arduino. It works like this:

1) flash the "antenna firmware" with jumper wire in place
2) remove jumper and power cycle the shield (now the firmware in the shield MCU actually flashes the antenna firmware) just kind of wait for some minutes to be safe.
3) insert jumper again and flash the wifiHD firmware
4) remove jumper and connect shield to arduino.

Please confirm you can get your shield working with the above 4 essential steps.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Jun 20, 2013, 03:07 pm
liudr-

Your procedure worked well for reflashing.  I got a blue light on the wifi shield when I did the power cycle between the two actual reflashing steps.

I still do not have a shield that works.  It connects to the LAN (shows 192.168.2.4 in both serial debug readout and on the LAN router), but does not respond to a browser input.  I am using a known good program that works on my 2 other wifi shields.  I think my wifi shield is probably just defective.

I don't understand why that would be because the at32uc responds properly to FLIP program and verify, and the network sees the wifi radio working at the proper address.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Jun 20, 2013, 03:30 pm
liudr-

Have you noticed that the MAC address that is printed on the sticker attached to your wifi shield does not match the actual MAC?  When I look at the MAC on the router it is totally different than the sticker.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Jun 20, 2013, 05:02 pm

liudr-

Have you noticed that the MAC address that is printed on the sticker attached to your wifi shield does not match the actual MAC?  When I look at the MAC on the router it is totally different than the sticker.


The MAC address is different from the sticker. I think the sticker is just a serial number. I have 10 shields that I documented both MAC addresses and stick values. One of my shields always returns EE:EE:EE:EE:EE:EE as MAC address with any sample code and connection conditions and I was able to return it for an exchange at sparkfun. One other shield also had a broken inductor and I returned it for exchange. Your shield may be defective as well. I am not ranking the wifh shield Quality Control process very high. 2 defective against 10 working out of a dozen shields is a bit too high to be good quality on my book. What I have been doing the last week or so is to find a way to compile projects to run on raspberry pi. Took a lot of hacking and code borrowing to get serial port to work. I still can't get the millis() to work yet. I was able to run this camera on my Debian box so I will test it on pi too. Wifi is cheap with a dongle when there is driver for the pi. The pi has much better network connectivity. What type of project are you using the wifi shield in? Maybe try a pi + arduino combo?

http://learn.adafruit.com/ttl-serial-camera/overview
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Aug 25, 2013, 06:09 pm
Liudr-

I've been gone but not forgotten!  I have been working with my three wifi shields over the last two months.

I requested an exchange of my one totally dead wifi shield.  That one had been DOA.  It connected to the LAN but never had responded to the browser.  The vendor verified that the shield was not working and arranged an exchange with Arduino.

When I received the exchanged unit it worked, but still had reliability problems

On all of my shields I have been running the firmware that is currently in the GitHub repository that is linked from the Arduino official web site page that documents the update procedure.

From a poster on another topic I learned about the new firmware needed for IDE 1.0.5.  As near as I can tell the only place to find these versions is in the hardware folder that comes with the IDE 1.0.5 install package.  The old stuff seems to still be up on GitHub in the firmware repository.

I updated wifiHD.elf and still had poor reliability on all three shields.  Then I found somewhere in the documentation that BOTH wifi_dnld.elf and wifiHD.elf should be reflashed with the versions of IDE 1.0.5.  I did that and have seen a significant improvement in reliability.

Reliability is much better, but not good enough.  I put two shields on life test in server mode using the 1.0.5 firmware.  Both did much better than with previous firmware.  Previously both repeatedly failed within two days.  With the new firmware I have gotten 5.5 days on one shield and it is still operating.  The other shield ran 3.1 days and then failed.  The symptom is the same as previously, browser timeout and it never recovers.

I think the new firmware is a big step in the right direction.  I will keep the still operation shield on life test to see how long it goes.  I could have variation of reliability between shields due to manufacturing tolerances.  If so, one should consistently do better than the other.

How is your project going?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Sep 03, 2013, 09:33 pm
The old good news / bad news story:

I put two shields on life test using IDE 1.0.5 after reflashing both wifi shields with the firmware that came in the IDE "hardware" folder when I downloaded version 1.0.5.  They performed far longer than any tests I have done before.

One stayed up for 14.5 days and handled 190 hits.  The other stayed up 8.8 days and processed 169 browser hits.  The bad news is that they both locked up almost simultaneously.  Since they were both on the same power strip and on the same LAN I think there was a glitch either in the AC power or the LAN.  My uninterruptable power supply did not record any anomalies.  Whatever happened it did not knock them off the LAN, but caused both to stop responding.

These tests results were much better than any I recorded previously.  Most of the previous tests failed within a few hours or a couple of days.  So the firmware upgrade did make a big difference.

There is still one thing that the shields don't do: They don't restart themselves after they have become non-responsive.  As near as I can tell they continue to be connected to the LAN, but they just stop responding to a browser connection.  I have a routine in the sketch that loops on reconnecting if the arduino powers up after a power failure, but in this case the power did not fail.

Once I had held the arduino cpu reset buttons down for 5 seconds, both shields began responding normally.

It seems that the wifi shield should have something like an internal watchdog test in its firmware that can determine that the shield is not responding.  Then it could reinitialize itself if there is a problem. 

I don't know of any other device that I have hooked to my LAN that just goes off line and cannot become responsive on its own.

My analysis:  Things are considerably better with the new firmware (good news), but still Thumbs Down because the wifi shield does not have trustworthy reliability on a network (bad news).  This is still just a toy until further improvements are made.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Sep 04, 2013, 04:29 pm
Here is a cost-effective alternative to WiFi shields for wireless Internet connectivity:

embeddedcoolness.com (http://embeddedcoolness.com)

Some code examples, too, to see how to write an Arduino webserver, send emails, tweets, updates to Xively etc...
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pietkuip on Sep 08, 2013, 11:22 pm

This may show the limits of open sourced products.  Unlike a commercial product nobody is responsible if an arduino product does not function.  So they can continue to sell these wifi boat anchors for $90 without risk of market or legal forces.

I do not agree. Arduino must be responsible for the Arduino WiFi shield that I bought recently. Yes, it worked, but only with 1.0.2. So I need to update the firmware if I want it to work with the Due.

The instructions for updating at http://arduino.cc/en/Hacking/WiFiShieldFirmwareUpgrading are terrible. Macports was a huge problem - I only managed to install dfu-programmer after removing all the other ports. The script does not work - keeps complaining that I am not root. Even though the instructions say that the Mac version does not require root and even when I believe that I am root. I gave up and try to borrow a Windows computer, using the Flip program by Atmel.

But was not the whole point of Arduino that it did not require familiarity with Unix and all that?

PS: Problem solved, thanks to Jamel Abiadh: https://plus.google.com/105267239702578406691/posts/7G7D2ra3pQe
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: fpga6 on Sep 17, 2013, 02:06 am
Another update:

Running life test on three shields.  One runs for about 10 days before crashing.  Another makes 3 days usually.  The third has never made it more than 36 hours.  All tests were done in server mode.

This is running the latest wifi_dnld.elf and wifiHD.elf firmware and then compiling with IDE 1.0.5.  By the way, after loading the firmware, you must compile with 1.0.5.  Using 1.0.4 will not work.

I would have to say that even with the latest firmwares the official wifi shield is still thumbs way down due to reliability issues.  It does work fine if you only need to run your project for a few hours and then restart it.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: cyrillo on Nov 17, 2013, 05:36 pm
I absolutely agree with liudr that the thumbs way down. For me there are to many limitations by the Arduino WiFi Shield. I bought two of them and I will sale them. But I think it is not fair to resale my Shield to a other person with the knowing about all this limitations and my own bad experience. 
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 17, 2013, 06:14 pm
Quote
Running life test on three shields.  One runs for about 10 days before crashing.  Another makes 3 days usually.  The third has never made it more than 36 hours.  All tests were done in server mode.

That sounds like the complaints about the ethernet shield until just recently. Both my client and server sketch examples work good now, even subjected to brutal internet attacks. Read this thread.
http://forum.arduino.cc/index.php?topic=197103.0.

Quote
I bought two of them and I will sale them. But I think it is not fair to resale my Shield to a other person with the knowing about all this limitations and my own bad experience.

How much would you sell one for if you knew it was going to someone who had at least a chance of getting it up and running?  :)

edit:...and is willing to share with everyone how to do it.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Nov 18, 2013, 04:10 am
Running the wifi client is not too bad but this is no industrial solution :) I bet raspberry pi can handle longer stretch of time since it runs a full OS. If anything goes wrong, the OS would attempt to restart service, right?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 18, 2013, 11:05 am

Running the wifi client is not too bad but this is no industrial solution :) I bet raspberry pi can handle longer stretch of time since it runs a full OS. If anything goes wrong, the OS would attempt to restart service, right?

I don't know about that. With the full OS, you have all those services running that can be hacked and crashed. With the Arduino, there is no full OS to expose vulnerabilities to hackers.

The ethernet shield is no problem for the Arduinos, especially the Mega 2560. Mine has been running exposed to the internet for over two weeks now without a problem. If programmed correctly, I imagine the wifi shield could be as reliable.

The advantage of the Raspberry Pi would be in security like SSL, but that does not guarantee a hack-free system if you are not a sharp programmer. The more complexity, the more security holes.

edit: I have been offered a wifi shield as a loan to test with by a forum member. I guess we will find out about the reliability of the wifi connection. While we are waiting, feel free to try to crash my Mega/ethernet shield. My only request is if you crash it, please tell me how you did it so I can patch that bug.
http://68.99.58.119
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 18, 2013, 01:37 pm
Sorry, what I am about to say may sound picky and I don't want to be disparaging, but your code has issues.

First of all.  When I look at what your shield is doing in Wireshark, most of the packets are ~50 to 60 bytes.  Your shield is framing data,  1 character per TCP packet, most of the time.  I got a couple 118 byte packets, so it is possible for the shield to be more efficient.

Second.  You are playing fast and loose with the HTTP protocol.  Most modern browsers are very tolerant but some user-agents are not.
Code: [Select]

//HTTP Request
GET /index.htm HTTP/1.1
Host: 68.99.58.119
Connection: keep-alive
Accept: text/html

//HTTP Response
HTTP/1.1 200 OK
Content-Type:
text/html

<HTML>// etc...<HTML>


Issue 1.  You declared a HTTP/1.1 response but this is not a HTTP/1.1 response. If it were, you would have to include
Content-Length:exact_number_of_bytes_following\r\n
Connection: close\r\n
Because the user agent sent you
Connection:keep-alive\r\n

If you include those headers, you should not immediately close the session but rather, provide the client some time to close the connection gracefully.  If the client does not close the session gracefully, you may then presume it is dead and forcibly close the session.  

The behaviour of your server, closing the session immediately after servicing the request, is much closer to HTTP/1.0  So why don't you declare that ?

Issue 2.  You should not be putting line breaks in your headers.  Headers are name:value pairs with the syntax
header_name: value_1;value_2 \r\n

There is an interesting point about protocol interpretation to be made here.  From what I recall, the RFCs don't specifically say you can not put a line break in a header.  They do not say you should either.  By including the line break, you create an edge case - A scenarios outside of the protocol specification.

I am impressed that you have made your server as robust as you have.  If I can help you with the nuts and bolts of the protocol stuff, feel free to ask.   I would not want to compare the Ethernet shield with a WiFi shield just yet though.  The WiFi shield has some additional failure modes and a nasty 2 Second delay inherent in servicing the transmit buffer.  2 Seconds is an age in network terms.

The WiFi shield is not entirely without merit though.  My NTP clock has been running about 2 weeks now and is happy to roam across non-overlapping access points.   The WiFi shield seems perfectly suitable for blatting a few 100 bytes per minute around using UDP, as far as I can see.

Whether simplicity is it's own security is an interesting debate, verging on being a thought experiment.

On the one hand, for your simple approach, you are having to write bespoke code with, limited trial and error testing, to serve a very simple page.  Your code does not conform with the protocol standard.  You are almost at the limit of your resources and there may still be edge cases you have yet to come across.  So yes, there is not much chance of your Arduino leaking data but there is quite a chance of it not being very robust.  It is robust in the scenarios you have tested, for which I congratulate you.

On the other hand, utilising a Linux SoC provides access to Apache, lighttpd, php, perl, python and all sorts of other sophistication.  Of course one does not have to use all that one could use.  Stopping/uninstalling unnecessary daemons will ensure they don't get hacked.  What packaged code is used, will conform to protocol specifications and is extremely well tested.  Should an exploit come to light in say Apache, it will be found, patched and retested by the Apache team, very quickly.

I am not saying either way is wrong, you understand.  Just you need to make a choice appropriate to the purpose.  For now, I feel the the SoC route is more appropriate to my purposes.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 18, 2013, 01:51 pm
Nice catch on the \r\n in the Content-Type. That was my bad. I am fixing that right now.

You correct about fast and loose. But I am working with very limited resources, so...

It returns "file not found" when the correct response should be "bad request", and vice versa.
It can be DoSed easily, but it doesn't crash.

edit: It is fixed.
If the w5100 is sending smaller packets than it should, that would be in the firmware. The SD page uploads should load the tx buffer with 64 bytes, then send the w5100 an exec command to send that packet. ??
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 19, 2013, 12:31 pm
Thanks to PaulS, I will have a wifi shield arriving at the end of this week. Thanks, Paul. You do more than your share here on the forum.

The first code I plan on running is this. It is a firmware version check. I would like some input from those whose shields work, and those whose shields fail. Which version do you have and does it work?
Code: [Select]
#include <WiFi.h>

int status = WL_IDLE_STATUS;     // the Wifi radio's status

void setup() {
 //Initialize serial and wait for port to open:
 Serial.begin(9600);
 
 // check for the presence of the shield:
 if (WiFi.status() == WL_NO_SHIELD) {
   Serial.println(F("WiFi shield not present"));
   // don't continue:
   while(true);
 }

 // check firmware version
 Serial.print(F("Firmware version: "));
 Serial.println(WiFi.firmwareVersion());
}

void loop() {
}


edit: From another post here on the forum, that should return V1.1.0 if you have completed the firmware upgrade included with IDE v1.0.5.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 19, 2013, 09:00 pm
Quote from: SurferTim

You correct about fast and loose. But I am working with very limited resources, so...

So.  You could respond with HTTP/1.0 and conform with the HTTP protocol standards using no more resources.  It takes more resource to conform with HTTP/1.1 and the protocol offers no benefits (I can think of) for low powered devices.

Quote
If the w5100 is sending smaller packets than it should, that would be in the firmware. The SD page uploads should load the tx buffer with 64 bytes, then send the w5100 an exec command to send that packet. ??

The single character packets are down to your use of println when you could be using write.

For a few days only, you can reach my Arduino Ethernet shield on
http://212.159.25.45
If you look at the response in Wireshark, you will see it arrives in a single packet.  I am short of time tonight but I will post the sketch tomorrow.

Great news on the WiFi Shield donation by the way.

I have two WiFi shields, both R3.
They worked OK with the firmware they shipped with and reported V1.0.0
They went flaky when I upgraded to the firmware development snapshot on Github and continued to report V1.0.0
They worked reliably again when I upgraded to the firmware in the Arduino master branch on Github but continued to report V1.0.0
They stopped working when I upgraded to Arduino IDE 1.0.5
They are working OK again since I upgraded them using the firmware files shipped with the IDE [edit] and they report V1.1.0

When I say, work OK, I mean they work within the limitations that they have.  Learning what those limitations are has taken me quite some time though.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 19, 2013, 11:22 pm
The client.println() calls should not be sending single character packets. Only client.write(char) should do that. The client.write(char*,int) calls should send int number of characters (64 for my code) per packet (edit: except the last one if the file was not an even multiple of 64).

I will consider switching to HTTP/1.0 tho. That makes sense.

So you never show v1.1.0 on the wifi shield firmware?

edit: I tried you server. It works ok through the PuTTY test. It responds like zoomkat's code. It does not wait for the blank line, only the first line feed, and disregards the rest of the request.

I gotta know how you are servicing more than one socket at a time. Would you be ok with posting your server code?
edit: Never mind. I just found out by testing mine. I just learned something about the w5100 and ethernet library.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 20, 2013, 12:58 am
Quote
For a few days only, you can reach my Arduino Ethernet shield on
http://xx.xx.xx.xx

Did you terminate your test early? Or did I get all your sockets? I can crash mine too.  :(
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 20, 2013, 09:01 am

The client.println() calls should not be sending single character packets.


:smile:  Wireshark is your friend.  Whatever println should do, here is what it is doing.
Code: [Select]

//This is the result of a println()
   00000000  48                                               H
   00000001  54                                               T
   00000002  54                                               T
   00000003  50                                               P
   00000004  2f                                               /
   00000005  31                                               1
   00000006  2e                                               .
   00000007  31                                               1
//...snip...
//And this is what a write() looks like
   0000003F  3c 48 54 4d 4c 3e 0a 3c  48 45 41 44 3e 3c 6c 69 <HTML>.< HEAD><li
   0000004F  6e 6b 20 72 65 6c 3d 22  73 74 79 6c 65 73 68 65 nk rel=" styleshe
   0000005F  65 74 22 20 74 79 70 65  3d 22 74 65 78 74 2f 63 et" type ="text/c
   0000006F  73 73 22 20 68 72 65 66  3d 22 64 65 66 63 73 73 ss" href ="defcss
   0000007F  2e 63 73 73 22 3e 3c 2f  48 45 41 44 3e 0a 0a 3c .css"></ HEAD>..<
   //...snip


Quote
I will consider switching to HTTP/1.0 tho. That makes sense.

You would not be the first developer I had to try to explain HTTP version numbers to.  Outside of HTTP, version numbers typically refer to compatibility.  e.g. V2 may not be compatible with V1.  HTTP was designed to be inherently backwards compatible.  So a V1.1 request remains compatible with a V1.0 response.  HTTP/1.0, infers fewer expectations.  For instance, a server declaring a V1.0 response may still support pipelining but does not have to.  A server declaring a HTTP/1.1 response, should support pipelining.

Quote
So you never show v1.1.0 on the wifi shield firmware?

An oversight, corrected.   My shields are reporting V1.1.0 since the latest upgrade.  The latest firmware version is the most stable and complete, in my opinion.   People appear to be having issues upgrading and that appears to have created some myth and legend about earlier versions being better.  

The latest firmware version still has issues though.  The 2 second latency between transmit cycles  being the most serious, in my view.
http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51
I would love to have a crack at the WiFi shield's MCU firmware but would not know where to start with compiling and debugging.

Quote
edit: I tried you server. It works ok through the PuTTY test. It responds like zoomkat's code. It does not wait for the blank line, only the first line feed, and disregards the rest of the request.
My server is not really a server.  It's a couple house spend on a proof of concept.  The sketch started out as a simple client throughput test.  I added just enough server code to send a response to a browser.

Quote
I gotta know how you are servicing more than one socket at a time.

I didn't know I was!  This is the first time I have tried to do anything with the Ethernet shield and I am still trying to fathom the relationship between the library and the socket structures it is abstracting.  To be honest, I would be more comfortable working directly with the sockets.

Quote
Would you be ok with posting your server code?
edit: Never mind. I just found out by testing mine. I just learned something about the w5100 and ethernet library.

My sketch will be in the next post but the server code is non-existent.  Please do share what you know about the library.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 20, 2013, 09:26 am
Sketch as promised.  
It is intended to be a demonstration of using Client.write() to avoid using Client.println().
It started as a throughput test with the sendData() function.  
Naturally progressed to utilising program memory to send HTML over HTTP.
Then I had a what the heck, can I send this to a browser moment.

Code: [Select]

#include <avr/pgmspace.h>
#include <stdio.h>
#include <stdlib.h>
#include <Streaming.h>
#include <SPI.h>
#include <Ethernet.h>
#include <EthernetClient.h>
#include <EthernetServer.h>
#include <Dns.h>
#include <Time.h>

byte mac[] = { 0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x02 };

//EthernetClient client;
EthernetServer server(80);

void setup()
{
Serial.begin(9600);
Serial << F("Setup...\r\n");

Ethernet.begin(mac);

IPAddress ip = Ethernet.localIP();

Serial << F("Arduino IP ");
for (uint8_t i =0; i <4; i++) {
Serial << ip[i] << ".";
}
Serial << "\r\n";

server.begin();
}

uint16_t responseCount = 0;
uint16_t timeoutCount = 0;
boolean idle;

void loop()
{
if (!idle) {
Serial << F("Responses ") << responseCount
<< F("\tTimeouts ") << timeoutCount
<< F("\tFree Ram ") << ramTest()
<< F("\r\nListening\r\n");
idle = true;
};

EthernetClient client = server.available();
if (client.connected()) {
idle = false;
char* page = getPageM(0);

uint16_t bytes = sendResponse(&client, 200, page);
Serial << "\r\nSent " <<  bytes << " bytes to host\r\n";
free(page);

boolean wait = true;
uint16_t startWait = millis();
do {
client.flush();
wait =(millis() - startWait) < 2000;
} while(client.connected() && wait);
client.stop();
responseCount++;
if (!wait) timeoutCount++;
}
}

char* getPageM(uint8_t pageNumber) {
char* page = NULL;

switch(pageNumber) {
case 0:
page = (char*) malloc(95);
sprintf_P(page,
(char*) F("<HTML><BODY><h1>Matt's Arduino</h1><p>Up Time %02d:%02d:%02d</p><p>Ram Free = %d</p></BODY></HTML>"),
hour(), minute(), second(),
ramTest()
);
}
return page;
}

uint16_t sendResponse(Client* client, uint16_t status, char* page) {
uint16_t sent = 0;
char* response = (char*) malloc(64);

switch (status) {
case 200:
sprintf_P(response,
(char*) F("http/1.1 %d OK\r\ncontent-length:%d\r\ncontent-type:text/html\r\nconnection:close\r\n\r\n"),
200,
strlen(page)
);
strcat(response, page);   //probably not safe!
break;
}
sent = client->write((byte*) response, strlen(response));

Serial << response;
free(response);
return sent;
}

uint16_t sendData (Client* client, uint16_t dataLen, uint8_t maxLoop ){

byte* data = NULL;
uint32_t bytesSent = 0;

data = (byte*) malloc(dataLen);
for (uint16_t i = 0; i < dataLen; i++) {
data[i] = 'A';
}

for (uint8_t l = 0; l < maxLoop; l++) {
bytesSent += client->write(data, dataLen);
}
free(data);
return bytesSent;
}

IPAddress hostByName(char* hostName) {
IPAddress hostIP;
DNSClient resolver;
resolver.begin(Ethernet.dnsServerIP());
resolver.getHostByName(hostName, hostIP);
return hostIP;
};

uint16_t ramTest() {

uint16_t freeRam = 0;
byte* buffer = NULL;

do {
buffer = (byte*) malloc(++freeRam);
if (buffer != NULL) {
free(buffer);
}
} while (buffer != NULL);

return freeRam + sizeof(byte*) + sizeof(uint16_t);
}
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 20, 2013, 11:40 am
@MattS-UK: Thanks for that update on client.println(). I had checked it before several IDE versions ago, and I am almost certain it was not breaking up the packets then. So you use client.write(char*) and it doesn't break up the packets into single bytes?

But that is not my big problem today. I can crash my server code. I must find a way to fix that.
http://forum.arduino.cc/index.php?topic=197103.0

edit: I tried client.write(char*) and it does not like the F() function. So I guess my choice is single character packets or run out of SRAM.  :(

Update on the client.write(char*).  It apparently does not move program memory strings into SRAM like client.print() does, at least that is the result of my preliminary tests. I use less SRAM with client.write(char*) than client.print(F(char*)). ??

BTW, thanks for your input. This is what I was looking for.  :)
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 20, 2013, 12:43 pm
Ethernet Shield conversation moved
http://forum.arduino.cc/index.php?topic=197103.msg1475328#new
Reply #67
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 20, 2013, 12:48 pm
I read your code. I tried client.write(char*) compared to client.print(F(char*)) and found that the write uses less SRAM than the print. See the server thread. This part belongs there. I have been "thread hopping" (wish the Arduino could thread hop!).

Thanks for that!
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: liuzengqiang on Nov 20, 2013, 06:37 pm
The FLASH string helper F() uses String object to allocate memory so it takes more SRAM. The write(char*) simply calls write(char) repeatedly.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Nov 21, 2013, 01:04 am

The FLASH string helper F() uses String object to allocate memory so it takes more SRAM. The write(char*) simply calls write(char) repeatedly.


No it does not!

F(), uses PSTR
Code: [Select]
class __FlashStringHelper;
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))


This writes byte by byte to 'write'.
Code: [Select]
size_t Print::print(const __FlashStringHelper *ifsh)
{
  const char PROGMEM *p = (const char PROGMEM *)ifsh;
  size_t n = 0;
  while (1) {
    unsigned char c = pgm_read_byte(p++);
    if (c == 0) break;
    n += write(c);
  }
  return n;
}
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 22, 2013, 12:57 pm
Just an update. I received the wifi shield from PaulS yesterday. He does more than average for this forum. Thanks, PaulS!

I have a R2 Mega and a R3 wifi shield. For those not familiar with interfacing these two, you must jumper 5v to the IOREF pin, or the wifi shield will not respond, and the test code shows "wifi shield not present".

It is using firmware v1.0.0 as I suspected. However, I found this morning that I do not have a mini-usb cable to program the wifi shield with the new firmware. That will probably be Saturday before I can get one.

edit: I found a cable and updated the firmware to v1.1.0. It was not as easy as I thought it would be. It connected to my wifi network right away and got an ip. So far, so good.

Don't have time today, but will try a sketch or two tomorrow.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 22, 2013, 07:27 pm
So much for 2 second delays between sends. My first try was my basic UDP packet send. I have it set to 48 byte packets at 10 packets per second, and it is doing fine!  :)

Next will be TCP client.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 23, 2013, 12:42 pm
I converted my playground web client sketch for the ethernet shield to wifi. It took only a few minutes and it is working fine.

BTW, all these are "Perfect World" sketches so far. I will move them to "Real World" (start torturing them and add fail recovery) when I determine they work ok.

Next is web server.

edit: I just finished converting my new web server code for the ethernet shield to the wifi shield. It works ok, but is a bit more sluggish than the ethernet shield. It takes about twice as long to download the images.

The email client code has been completed for a while.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 23, 2013, 10:14 pm
I found a bug in the wifi library while using the tcp client sketch. If the wifi radio connection fails and the client code tries to make a client connection and it fails (which it will because the radio connection failed), the socket is not released. If that happens 4 times, you are out of sockets.

This will show the status of all the wifi sockets.
Code: [Select]
void ShowSockStatus() {
 for(int x = 0; x < MAX_SOCK_NUM; x++) {
   Serial.print(F("Socket #"));
   Serial.print(x,DEC);
   if(WiFi._state[x] == -1) Serial.println(F(": available"));
   else Serial.println(F(": used"));
 }
}


FYI: If you disable the wifi router radio (my test), wait a bit, then turn it on again, the wifi shield reconnects to the radio without a problem. No need to reconnect manually. The only problem is the failed TCP connections depleting the sockets.

I am using this as a temporary "shotgun" patch. If the connection to the server fails, I call this to reset the sockets.
Code: [Select]
void SetSockStatus() {
  for(int x = 0; x < MAX_SOCK_NUM; x++) {
    WiFi._state[x] = -1;
  }
}
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 25, 2013, 11:55 am
Here is my example web client sketch for the wifi shield. It has been running for a while without a fail.
http://forum.arduino.cc/index.php?topic=200784.0

I have tried all I know to get it to fail, and it is still running. At 30 seconds per request, it has sent over 4300 requests. I have disabled the wifi router radio, broken the connection with the ethernet to the router, stopped the server, etc. It still runs fine.

If you could try that code and let me know how it works for you, that would help me out. If it works for more users than just me, I will add it to the playground.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 25, 2013, 07:39 pm
Quote from: SurferTim

So much for 2 second delays between sends.

Sigh:  I sometimes wonder about the attitude displayed on these forums :(

Quote
My first try was my basic UDP packet send. I have it set to 48 byte packets at 10 packets per second, and it is doing fine!

Did you consider perhaps your test failed to find the 2 second latency. 
I note your web server is not responding very quickly.  Why would that be, do you think?

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 25, 2013, 10:18 pm

Quote from: SurferTim

So much for 2 second delays between sends.

Sigh:  I sometimes wonder about the attitude displayed on these forums :(

Quote
My first try was my basic UDP packet send. I have it set to 48 byte packets at 10 packets per second, and it is doing fine!

Did you consider perhaps your test failed to find the 2 second latency. 
I note your web server is not responding very quickly.  Why would that be, do you think?

You can't just say "2 second latency" without being a bit more specific. If it is only the send on the server, then you may be correct about a delay, but I don't see 2 seconds. And certainly no latency on UDP.

Did you find the socket error in the wifi server library yet? I have. I haven't had time to correct it yet. I'll get to it after the client sketch is debugged.

I also found a socket error in the client library, but have a patch for it already. It is working ok. I'm up to 5500+ requests and no socket loss and still running fine, no matter what I do to it. No 2 second latency there.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 26, 2013, 11:41 am
Enough testing of the client sketch. Over 7000 requests without a socket problem. That is good for me.

Here is the server socket problem. The first socket check is correct, but all others are not. If the socket shows -1, the socket is available. If the socket shows the socket number (0-3), it is used by the server.  It appears it is using only one socket, and after the first request, there is no socket used by the server to listen on port 80.
Quote
Starting SD..ok
Firmware version: 1.1.0
Attempting to connect to open SSID: OhSh
You're connected to the networkSSID: OhSh
BSSID: 0:C:42:2B:B8:B4
signal strength (RSSI):-44
Encryption Type:4
IP Address: 192.168.0.9
192.168.0.9
MAC address: 7A:C4:E:1C:AF:F8
NetMask: 255.255.255.0
Gateway: 192.168.0.1
Ready
// this is correct.
0  80
-1  0
-1  0
-1  0


Client request #1: GET / HTTP/1.1
file = /
file type =
method = GET
params =
protocol = HTTP/1.1
Home page SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
//this is bad. No socket listening.
-1  80
-1  0
-1  0
-1  0


Client request #2: GET /defcss.css HTTP/1.1
file = /DEFCSS.CSS
file type = CSS
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// and this is bad. Still no socket listening.
-1  80
-1  0
-1  0
-1  0



This is how it should look. Note there is always an active socket listening on port 80.
Quote
Starting SD..ok
Firmware version: 1.1.0
Attempting to connect to open SSID: OhSh
You're connected to the networkSSID: OhSh
BSSID: 0:C:42:2B:B8:B4
signal strength (RSSI):-44
Encryption Type:4
IP Address: 192.168.0.9
192.168.0.9
MAC address: 7A:C4:E:1C:AF:F8
NetMask: 255.255.255.0
Gateway: 192.168.0.1
Ready
// socket 0 listening
0  80
-1  0
-1  0
-1  0


Client request #1: GET / HTTP/1.1
file = /
file type =
method = GET
params =
protocol = HTTP/1.1
Home page SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// socket 1 listening
-1  80
1  80
-1  0
-1  0


Client request #2: GET /defcss.css HTTP/1.1
file = /DEFCSS.CSS
file type = CSS
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// socket 0 listening
0  80
-1  80
-1  0
-1  0


It appears it is using only one socket, and after the first request, there are no sockets used by the server.

edit: I highlighted the socket checks in bold type so they are easier to see.

The first thing the server should do when detecting a client connected to the active socket is start another socket listening for the next client on the first available socket.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 26, 2013, 04:45 pm
Quote from: SurferTim

You can't just say "2 second latency" without being a bit more specific.


I agree, which I guess is why I was pretty specific about it.
http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51
I don't mind that you might not read it or might not understand it.  I only mind you presumed to know better.

Quote
If it is only the send on the server, then you may be correct about a delay, but I don't see 2 seconds. And certainly no latency on UDP.


I disagree with your use of the word 'only.' 

You will not see the 2 second delay using 10 x 48 byte packets.  Write an uninterrupted stream > ~2.75KB and the delay becomes evident.  The transfer speed is effectively throttled at ~12Kbps, about the same as a 17 year old modem.

Quote
Did you find the socket error in the wifi server library yet?


Was I supposed to be looking for it?  I pretty much decided an SoC with a 5 Euro WiFi adapter is a less expensive fix.

Quote
I also found a socket error in the client library, but have a patch for it already. It is working ok. I'm up to 5500+ requests and no socket loss and still running fine, no matter what I do to it. No 2 second latency there.


To be fair  to you, I thought I better have a go with your client.   Admittedly I got a bit bored waiting out the 30 second polling interval and changed it to 15 seconds.  I also added a byte counter and sampled the time the client spent in the receive loop.

Of those 5500 requests, did you check the byte count on all of them?  I suspect not.

Code: [Select]

Ready
Socket #0: available
Socket #1: available
Socket #2: available
Socket #3: available
connecting...connected
Socket #0: used
Socket #1: available
Socket #2: available
Socket #3: available
HTTP/1.1 200 OK
Date: Tue, 26 Nov 2013 14:46:53 GMT
Server: Apache/2.2.24 (PCLinuxOS 2011/PREFORK-1pclos2013)
Last-Modified: Sun, 24 Nov 2013 10:49:09 GMT
Accept-Ranges: bytes
Content-Length: 43
Connection: close
Content-Type: text/html

<html><body>test server page</body></html>
TotalBytes = 290 in 1341 ms

disconnecting.
Pass 1
Socket #0: available
Socket #1: available
Socket #2: available
Socket #3: available
connecting...connected
Socket #0: used
Socket #1: available
Socket #2: available
Socket #3: available
TotalBytes = 0 in 1091 ms

disconnecting.
Pass 2


So that's one uncaught failure and a one successful 290 bytes in 1.341 Seconds; a whopping 1.75Kbps!

A 16 character payload is not what I call a fair test.  Small pages will reduce throughput and you don't come across them too often in real life.  So I thought I might try against one of my own web servers, on my local net.  Your client took 4.253 Seconds to read 4109 bytes at 7.73Kbps!  The default Apache page, 5240 bytes in 4901 ms at 8.6Kbps. 

Still not breaking that 12Kbps bottleneck then.

A 404 not found proved interesting, 470 bytes in, between 1022ms to 2065ms. The 404, a small page like your test page, failed more times than it succeeded, returning 0 bytes in ~1700ms.

Hmm, it looks very much to me as if the shield's buffers might be ~ 2.75KB, are serviced at ~2 second intervals and when the connection is stopped before the buffers have been serviced, data is silently discarded.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 26, 2013, 05:18 pm
Actually, my first download test was Google's home page. It is rather large, and downloads at just about the serial bus speed.

The WiFi.getSocket() call is dependent on the values in the WiFi._state array. That is the array affected in the server code that I described above. If you fire up the server code and make one request, from then on out, the WiFi.getSocket() function call will return 0, at least the first call. That is due to the socket malfunction I also described above. Since the server does not reserve a socket for the listener, it gets the first socket with the WiFi._state[] value of -1. That will be socket 0, since all the sockets are showing a state of -1 (available) in that array after the first client request.

I will check that to verify the getSocket() return value, but it should always be socket 0 the first call. I will check what happens when the server is running and calling that function.

edit: I looked at the getSocket() and server code again. It is the WiFi._server_port[] array that is used by getSocket(). Then that verifies the server uses only one socket. The only socket that has a non-zero WiFi. _server_port[] is socket 0, no matter how many requests are made.
Code: [Select]
uint8_t WiFiClass::getSocket()
{
   for (uint8_t i = 0; i < MAX_SOCK_NUM; ++i)
   {
       if (WiFiClass::_server_port[i] == 0)
       {
            return i;
       }
   }
   return NO_SOCKET_AVAIL;
}

I checked with my server code,and WiFi.getSocket() always returns 1.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 27, 2013, 12:10 pm
@MattS-UK: I see the delay now, but only on large file transfers, and not 2 seconds in my case. More like a second, but that is still too long. According to my tests, this is where the delay happens. This function is in /utility/server_drv.cpp. If it waits for a timeout, it could be 2.5 seconds (delay(100) x 25)
Code: [Select]
uint8_t ServerDrv::checkDataSent(uint8_t sock)
{
const uint16_t TIMEOUT_DATA_SENT = 25;
   uint16_t timeout = 0;
uint8_t _data = 0;
uint8_t _dataLen = 0;

// it happens in this do-while loop.
// Uncomment the 3 Serial.print() commands to check it.
// It prints an exclamation point before the loop, and an asterisk after the loop.
// The last character printed on the serial monitor is an exclamation point during the delay.

//   Serial.print("!");
do {
WAIT_FOR_SLAVE_SELECT();
// Send Command
SpiDrv::sendCmd(DATA_SENT_TCP_CMD, PARAM_NUMS_1);
SpiDrv::sendParam(&sock, sizeof(sock), LAST_PARAM);

//Wait the reply elaboration
SpiDrv::waitForSlaveReady();

// Wait for reply
if (!SpiDrv::waitResponseCmd(DATA_SENT_TCP_CMD, PARAM_NUMS_1, &_data, &_dataLen))
{
WARN("error waitResponse isDataSent");
}
SpiDrv::spiSlaveDeselect();

if (_data) timeout = 0;
else{
++timeout;
delay(100);
// Serial.print("+");
}

}while((_data==0)&&(timeout<TIMEOUT_DATA_SENT));
//   Serial.print("*"');

   return (timeout==TIMEOUT_DATA_SENT)?0:1;
}


Here is the function called in that loop. It is in /utility/spi_drv.cpp. I'm not sure I understand the CHECK_DATA calls.
edit: They are probably a define somewhere, but I don't have time to search for them right now.
Code: [Select]
int SpiDrv::waitResponseCmd(uint8_t cmd, uint8_t numParam, uint8_t* param, uint8_t* param_len)
{
   char _data = 0;
   int ii = 0;

   IF_CHECK_START_CMD(_data)
   {
       CHECK_DATA(cmd | REPLY_FLAG, _data){};

       CHECK_DATA(numParam, _data);
       {
           readParamLen8(param_len);
           for (ii=0; ii<(*param_len); ++ii)
           {
               // Get Params data
               //param[ii] = spiTransfer(DUMMY_DATA);
               getParam(&param[ii]);
           }
       }        

       readAndCheckChar(END_CMD, &_data);
   }    
   
   return 1;
}


edit: I added a comment in the code to show how I checked it if you are interested.
edit2: I also added a Serial.print("+") inside the do-while loop. During the delay, I get a string of "++++++++++++++++++".

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 28, 2013, 12:24 pm
@MattS-UK: I changed the code in the library as in the post above and did a new test, and found we are both correct. The delay is 1 second and 2 seconds, depending on which side of the router's masquerade the client is on.

If I request the page from a local interface on my router (ethernet), the delays are 1 second (10 to 12 '+'). If I request the page from the internet interface, the delays are 2 seconds (19 to 20 '+').

edit: Whoa! Here is a shocker! Somebody just downloaded the waterfal.jpg image from the internet, and the delays were minimal (2 to 3 '+'). And it was fast enough to not timeout on the favicon.ico.

Same client just downloaded the soccer image (wolver.jpg) with the same 2 to 3 cycles in the delay, and fast enough to get the icon. ??
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 28, 2013, 02:27 pm
Somebody just downloaded the soccer image in record time. Only one 100ms delay where everyone else is 1 to 2 seconds. Who are you? Could this be browser related?

edit: Again somebody downloaded the waterfall image with only one 100ms delay at what is 1 to 2 seconds for others. ??
And another downloaded the soccer image with only 100ms delays.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 28, 2013, 04:35 pm
Another user is downloading the images well. This time the first delay is about a second, but the following delays are only 100ms each. Who are you ? What browser are you using?

edit: Each waterfall image download has about a dozen separate delays during the download. The soccer image has a few more that that. 12 times 2 seconds (24 seconds delay) is horrible. 12 times 100ms (1.2 seconds) is bearable.

Here is what I see on the serial monitor. Each "!*" pair is a packet. Each "+" is a 100ms delay. Here is the last request/download.
Code: [Select]
Client request #44: GET /IMG/WATERFAL.JPG HTTP/1.1
file = /IMG/WATERFAL.JPG
file type = JPG
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6075
file found..opened..!*send..!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!
*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!
*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*
!++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!
*!*!+*!*!*!*!*closed
disconnected


Here is what my download looks like.   :(
Code: [Select]
Client request #50: GET /IMG/WATERFAL.JPG HTTP/1.1
file = /IMG/WATERFAL.JPG
file type = JPG
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6075
file found..opened..!*send..!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++
+++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!+++++++++++*!*!*!*!*!*!*!*!*
!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!
*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*
!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+
+++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*closed
disconnected
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 28, 2013, 07:25 pm

@MattS-UK: I changed the code in the library as in the post above and did a new test, and found we are both correct. The delay is 1 second and 2 seconds, depending on which side of the router's masquerade the client is on.


I have benchmarked the damn thing enough times now, I tend to think that if you are not seeing a delay in the order of 1500 to 2000ms after the buffers are saturated, you might not be measuring it right.

Quote
If I request the page from a local interface on my router (ethernet), the delays are 1 second (10 to 12 '+').


You are measuring the delay at the sending end.  How do you know the data which was purportedly sent, exited the interface and reached the other end?  My measurements were verified by benchmarking all three points.  The sending end, on the wire in between and at the receiving end.  Wireshark is by far the most revealing.

Masquerading should have nothing to do with it.  I say should, because there is something very odd going on with the session management and I haven't quite worked out all the implications of it.  In a nutshell, the shield appears to not be honouring TCP state transitions.  You touched on it in an earlier post.  I had a poke around with the ServerDrv class.  It looks very much like the shield enters a bogus state, where  a single socket is both ESTABLISHED and LISTENing. 
Refs, ServerDrv::getClientStatus, ServerDrv::getServerStatus, ServerDrv::startServer.

ServerDrv is not documented, so I could be short circuiting something but you also noted that out of the four socket structures the shield is supposed to maintain, it apparently only ever uses one.

Quote
edit: Whoa! Here is a shocker! Somebody just downloaded the waterfal.jpg image from the internet, and the delays were minimal (2 to 3 '+'). And it was fast enough to not timeout on the favicon.ico.


How do you know the data was served?  The throughput would be ~20 times the mean.  The likely hood is, it did not happen as you think.  If it did happen, it is more fuel for the fire.  An interface with throughput varying by so much for no explicable reason, is as good as broken.

Quote
Each "!*" pair is a packet.


Do you mean a packet or do you mean a write to the SPI bus?

Your server is down BTW.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 29, 2013, 03:04 am
Yes, it appears it was down. That was the first fail since I started experimenting with it. The Windows computer is was connected to crashed. It should be up again now. It is a holiday over here and I was visiting my family.

"!*" is a packet or SPI write. I send what I calculate as 7 packets using client.write(), and I see "!*!*!*!*!*!*!*". It may be sent by the wifi shield as one packet. That I cannot guarantee. The "+" is a 100ms delay. That I can guarantee. Any way you look at the math, delay(100) is a 100ms delay. One times that (+) is 1/10th of a second. Ten times that (++++++++++) is a second. Twenty times that (++++++++++++++++++++) is two seconds. I think that works the same on both sides of the Atlantic. I can watch the serial monitor and see how fast the downloads are happening. The timing on all three computers here are showing that timing as correct. However, the internet computers that surprised me downloaded the files fast, noticeably faster than mine. It is not difficult to tell the difference when talking about 20+ seconds difference.

If I start a download with one computer, then try to download with another computer, I get a "connecting" message until the current download is finished, then I get a "connected" message and the download starts. Using the ethernet shield, I get "connecting", then almost immediately "connected" but no download starts on the second connection until the current download is finished. I can see that with the socket status monitors I use. According to them, the ethernet shield does use all 4 sockets, and the wifi shield uses only one.

You seem to be the only other person here besides PaulS and myself that really cares anything about this. Nobody else has responded, so it is difficult to tell how it is actually working on the client end. Check with your wireshark and let me know what you see.

edit: If other users would like to help with this, the ip of the wifi server is http://68.99.58.119. Try the image downloads and watch this thread. I may have to leave today for a while, but I will be here for the next couple hours.

It appears here it may be the web browser, not the masquerade/nat. I tried with Chrome on local interface, and got the 1.2 second delays every delay. I tried with IE on the same computer, and the delays were short (++) about half the time (every other delay). Tried with Firefox remote (WAN) interface, and got the 2 second delays consistently. ??
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 29, 2013, 01:18 pm

Yes, it appears it was down. That was the first fail since I started experimenting with it.


It's down again.  Looks like I can crash it on demand.  Sorry about that.

Quote
"!*" is a packet or SPI write. I send what I calculate as 7 packets using client.write(),


It's an SPI write.  A packet is something else.  The distinction is important.

Quote
Any way you look at the math, delay(100) is a 100ms delay.


Yes, I get what delay(100) does.  What you don't appear to be getting is the bus write is decoupled from the network write.  What role is that gert big AT32UC1512 playing in all this?

Quote
However, the internet computers that surprised me downloaded the files fast, noticeably faster than mine.


You do not know whether those computers downloaded anything at all.

Quote
It is not difficult to tell the difference when talking about 20+ seconds difference.


So try to explain the variation to me.  What mechanism could cause the throughput to go from an average <20Kbps to over 500Kbps?  The most likely answer is, it doesn't.

Quote
If I start a download with one computer, then try to download with another computer, I get a "connecting" message until the current download is finished, then I get a "connected" message and the download starts.


Yes.  The TCP session handling appears to be borked.

Quote
According to them, the ethernet shield does use all 4 sockets, and the wifi shield uses only one.


Server_Drv.h contains the prototypes for  ServerDrv::getClientStatus(socketIndex) and ServerDrv::getServerStatus(socketIndex), which return values enumerated to TCP Socket states. 
0 = CLOSED, 1 = LISTENING, 4 = ESTABLISHED.

The state transition looks like this
Code: [Select]

status: Client, Server
        0       0           //Closed
        0       1           //Listen
        4       1           //borked! 

A TCP Socket can not be ESTABLISHED and LISTENing at the same time.

Calling ServerDrv::startServer on a Socket which is already LISTENing causes new connection attempts to be rejected.  But I can not for the life of me get another socket to start listening.  As far as I can tell, the problem is on the other side of the SPI bus - Beyond my ability to debug or do anything about it.

Quote
You seem to be the only other person here besides PaulS and myself that really cares anything about this.


LOL.  I guess I care that you don't post sarcastic comments alluding to my having made stuff up!

I also care not to encourage people to waste money on a device, which is unlikely to meet their expectations.  The WiFi shield is a candidate for the draw of shame - You know, that draw full of stuff that is never used.   The shield is not entirely useless but reliably serving interactive web pages onto the internet, is currently beyond it. 

Apart from that, call it a professional interest.  Poking around with the WiFi shield has been reminding me of what I take for granted.  Sockets being no more than data structures in software, for instance.

Quote
Nobody else has responded, so it is difficult to tell how it is actually working on the client end.   Check with your wireshark and let me know what you see.


I write my own clients.  The compiler I am using is paid for but there are plenty of free tools, including Processing.  You can download Wireshark for free too.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 29, 2013, 01:24 pm
It was down. I was playing with it for a few minutes. It is up now.

I think the difference is the browser. I get different delays every time I switch web browsers. I would like to hear from any users about the web browser they use to download the images.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 29, 2013, 02:36 pm
Whoever just downloaded the soccer pic, you had minimal delay. Only the first delay had a 1.5 second delay. All other delays in that download had only one '+'.

The second download had only a one second delay the first delay. Al others were 1/10th second.

edit: And another download that had a 1.5 second first delay (+++++++++++++++), and the rest were 1/5th second (++).
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 29, 2013, 06:30 pm
Just saw another soccer image download. Very fast. The first delay was 1.5 seconds. The rest were 1/10th second.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 30, 2013, 12:03 pm
Thought I might point one of me benchmarking tools at your WiFi Shield

Heres the log file.

Code: [Select]

R#, LEC, Bytes, ms, Kbps, Resource
R1 102 27199 5934 36.669 r1-skt2-img-wolver.jpg
R2 102 0 12217 0 r2-skt1-IMG-WATERFAL.JPG
R3 102 24319 3456 56.294 r3-skt3-IMG-WATERFAL.JPG
R4 102 27199 13559 16.048 r4-skt4-img-wolver.jpg
R5 102 0 18927 0 r5-skt6-img-wolver.jpg
R6 102 0 25252 0 r6-skt5-IMG-WATERFAL.JPG
R7 102 17504 4147 33.767 r7-skt7-IMG-WATERFAL.JPG
R8 102 0 10487 0 r8-skt8-img-wolver.jpg
R9 102 17504 2674 52.368 r9-skt9-IMG-WATERFAL.JPG
R10 102 27199 11842 18.375 r10-skt11-IMG-WATERFAL.JPG
R11 102 0 17073 0 r11-skt14-img-wolver.jpg
R12 102 27199 26167 8.316 r12-skt13-IMG-WATERFAL.JPG
R13 102 0 30300 0 r13-skt12-img-wolver.jpg
R14 102 0 19905 0 r14-skt10-img-wolver.jpg
R15 102 27199 4010 54.262 r15-skt16-img-wolver.jpg
R16 102 0 11724 0 r16-skt15-IMG-WATERFAL.JPG


First of all, there are more failures than successes - 0 bytes, 0 Kbps and Request 3 came in short.

Now look at the byte counts for R10 and R12.
WATERFAL.JPG is a 17KB file.  Wolver.jpg is a 27KB file

See Attached screenshot
Sure enough, I have files named WATERFAL,JPG on my disk, containing a picture of the South Bay Wolverines.
Which pretty much proves the session state is borked.

Quote from: surferTim

I think the difference is the browser.

Hows that gonna work then?  The protocols are documented, so you should be able to hypothesise the mechanism.  If you can not, you might as well blame the internet pixies.   

Good luck with your experiments but the WiFi Shield's TCP is seriously broken.  I don't think it is worth any more energy investigating the extents of the brokenness.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 12:12 pm
Thanks for the help so far, Matt. I do appreciate what you have done so far.

If that was you downloading less than an hour ago, you caught me in the middle of timeout experiments. If that was you, then your download was fast. Faster than any of mine. You kept the little blue light on almost constantly, where my downloads only make the blue light blink on about 1/4 of the time.

The favicon.ico download is the problem here. It is the third request, and with only one socket, it times out before anyone downloads it. I am certain that is due to the server's use of only one socket. If the client could establish the connection almost immediately, but must wait for the icon download, the client will wait much longer than if it cannot connect right away.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 30, 2013, 12:32 pm
It may have been me downloading around an hour ago but I am not using a browser and I am not requesting favicon.
My ip will be 212.159.25.??

Here is the request log, line breaks are replaced with "|"

Code: [Select]

R#, Resource, Request, Headers
R1 r1-skt2-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R2 r2-skt1-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R3 r3-skt3-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R4 r4-skt4-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R5 r5-skt6-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R6 r6-skt5-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R7 r7-skt7-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R8 r8-skt8-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R9 r9-skt9-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R10 r10-skt11-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R11 r11-skt14-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R12 r12-skt13-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R13 r13-skt12-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R14 r14-skt10-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R15 r15-skt16-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R16 r16-skt15-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||


As you can see, I am requesting the jpegs directly.

I suspect what you are seeing as rapid downloads, are the failures where no headers were returned.


Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 12:39 pm
I saw only two requests. I haven't seen any requests since I stopped my experiments.

The bad part is I am using the standard library, and I can't retrieve the client ip.  :( Do you have a way to get the client ip with the wifi library?

edit: If you did not receive a header, then you probably were attempting the download while I was downloading the images also. One socket is all I see being used, so you may be timing out before the one socket becomes available again.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 30, 2013, 01:17 pm

edit: If you did not receive a header, then you probably were attempting the download while I was downloading the images also.


You are in denial ;)

My test this morning was a practical verification of a problem I pointed out a couple posts ago, after investigating the behaviour of my own shield.   I have seen the same problem occurring every time I have sent more than one request to your Shield but I couldn't record it until this morning.  So yes, the 0 byte downloads could be you fiddling at your end but they probably are not.

Quote

One socket is all I see being used, so you may be timing out before the one socket becomes available again.

I end up with the wrong pictures in the files because two sockets at my end are connected to the same socket at your end.  Such should never be allowed to happen with a TCP connection.

Please go read up on TCP state transition and the three way handshake as you don't appear to want to believe me. 

Here, I found a picture
http://www4.cs.fau.de/Projects/JX/Projects/TCP/tcpstate.html
A TCP Socket CAN NOT be simultaneously ESTABLISHED and LISTENing.

The bug you are chasing is in the IP stack implemented in the AT32UC firmware. 

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 01:34 pm
I seems to me that my web browsers are in denial also. None will establish a connection while I am downloading the images.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: PaulS on Nov 30, 2013, 01:50 pm
Quote
Thanks for the help so far, Matt. I do appreciate what you have done so far.

But, you could curb the attitude. There have been plenty of opportunities for you to have helped. You haven't taken advantage of them. Until SurferTim volunteered, no one has. All that I've seen you do is call him a liar and an idiot. You could contribute by knocking off the attitude. It isn't helping anything.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 01:54 pm

All that I've seen you do is call him a liar and an idiot.


I must have missed this. Where exactly?


Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 02:02 pm
Let's not get into this type stuff. I am trying to get the wifi shield working. That is all. I see Matt being a bit stubborn, but I don't mind. A good disagreement sometimes helps. I might not be seeing the whole picture yet.

I see one socket being used by the server. None of my web browsers will establish a connection while I am downloading the images. The wifi shield (yes, Paul, it is your shield I am torturing) is online for all to abuse.
http://68.99.58.119
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 02:09 pm

I see Matt being a bit stubborn, but I don't mind.


What about, exactly? I've seen him patiently repeat the same point a few times, but I don't think that's quite the same thing as stubbornness.

It would be a pity if this becomes about ego. So far it's been an interesting experiment, even if the results so far seem to confirm that the fundamental problems are only fixable if the fundamental firmware issues are addressed.

Which Matt (and others) have pointed to as the basic issue several times. I don't know that he (or anyone else) is being "stubborn".

Facts are notoriously stubborn things*, however.

(* paraphrasing John Adams, apparently.)

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 02:23 pm
Yes, pico, you are correct. If the shield is using only one socket, it is probably a firmware issue. I don't deny that. This is NOT an ego issue. I am looking for a solution, no matter who comes up with it.

But if someone keeps repeating the same thing over and over, despite what I am seeing on this end, that is being a bit stubborn.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 02:35 pm

But if someone keeps repeating the same thing over and over, despite what I am seeing on this end, that is being a bit stubborn.


That's inconclusive. Look at it from the other person's point of view -- if I have to tell a person the same thing over and over again, but they are refusing to accept it, who's being stubborn then?

I've seen Matt make the same points a few times, but I got the impression it was because he believed you hadn't appreciated their full import after the first time he made them. I don't think that constitutes either "attitude" or "stubbornness".

Matt is reasonably new here, and he strikes me as a very knowledgeable and experienced person with much to contribute. I think the community would be doing itself a disservice to  discourage him from contributing. After all, it's not the number of posts, but the quality of those posts that counts, I think we would all agree.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 02:44 pm
Ok, pico, what have you tried? And I still see nobody trying any of these experiments on a wifi shield exposed to the internet for all to play with. Once again, here is the ip of this shield. Show me!!
http://68.99.58.119
Can you establish a connection with a web browser while you are downloading either of those images?

I saw many requests over the last few days, and NOBODY has said anything, positive or negative, except Matt. I have seen lots of successful downloads from other users besides me.

Once again I will thank Matt for taking the time to respond. I do admire his persistence. How about that word instead of stubborn?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 03:02 pm

Ok, pico, what have you tried? And I still see nobody trying any of these experiments on a wifi shield exposed to the internet for all to play with. Once again, here is the ip of this shield. Show me!!
http://68.99.58.119
Can you establish a connection with a web browser while you are downloading either of those images?


To be honest Tim, I haven't tried to download anything from your webserver. Matt seemed to have that side of things more than covered.


I saw many requests over the last few days, and NOBODY has said anything, positive or negative, except Matt. I have seen lots of successful downloads from other users besides me.


Have you considered that at least some of the downloaders might actually have been bots? They are not likely to give much feedback, I'm afraid.

BTW, just out of interest, how can be sure those downloads were "successful". That seems to be a key point raised earlier by Matt in the discussion. Are you running wireshark or similar to check what is actually being sent by the WIFi shield, or are you just surmising based on things like LED activity lights?


Once again I will thank Matt for taking the time to respond. I do admire his persistence. How about that word instead of stubborn?


Call it what you like, but if the meaning is the same, who cares? Really, I think it's futile to try to argue who is being "persistent" and who isn't in the discussion. If it takes a bit of back and forth before viewpoints converge, so be it.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 03:08 pm
@pico: Some were bots. They request the /robots.txt file. It appears their requests were successful. But since they are bots, they don't know that I am looking for an opinion on the performance.

I am still sitting here on "Client request #27" on the serial monitor, waiting for someone to assist me, but...
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 03:14 pm

It appears their requests were successful.


At the risk of being accused of being "persistent", I'll repeat my question: How do you know? Are you actually seeing your WiFi shield's responses using wireshark or similar, or are you surmising "success" from less direct evidence?
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 03:18 pm
You are not "stubborn" or "persistent" yet, but I presume that was you that requested the robots.txt file. It doesn't exist, so the bot would download everything it finds. I saw no other downloads.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: PaulS on Nov 30, 2013, 03:22 pm
Quote
How do you know?

I think that's the whole point. Tim is asking people to hammer on his server AND report the results (successfully downloaded the picture; tried but got nothing, tried but got a nude picture of Brtiney Spears instead, etc.).

It isn't clear to me whether Tim wants people using PCs with browsers to participate, or if he wants only people with Arduinos with Ethernet or WiFi shields to participate. Given that the server contains pictures, and the Arduino doesn't display pictures, I'm guessing the former is the intent.

I've downloaded the pictures, early on, with no issues. This was before I became aware of the timing issue that he and Matt are having a discussion over.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 03:23 pm

but I presume that was you that requested the robots.txt file.


Nope, wasn't me. As I said, I haven't tried to download anything from your server.

And remember, only "polite" bots request robots.txt. Not all bots are equally polite. And some are just downright rude. Just like everything else on the Internet, I suppose! ;)
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: PaulS on Nov 30, 2013, 03:26 pm
I just tried downloading both pictures again, using Firefox on Win7. Both pictures downloaded correctly. The form works, too.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 03:29 pm
@pico: Then my apology. I thought it was you trying to help, but you didn't. You just stand by and do nothing.

@PaulS: It was you hitting that shield hard. That is what I am looking for. Don't be shy. Give it all you got. But let me know how it did. It went from request #29 to request #53 in less than a minute, including the images. Thanks!  :)
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 03:41 pm

@pico: Then my apology. I thought it was you trying to help, but you didn't. You just stand by and do nothing.


Not at all. I'm trying to help. While I don't see much point in trying to connect to your WiFi shield server, (can't see what it would prove since you've already had fairly detailed reports from MattS of it working sometimes but not others, consistent with known firmware problems), I do see some value in trying to untangle some of the basic methodological points that seem to have been glossed over. Like: How do you know all the responses are successful?

If my contribution isn't entirely to your taste, sorry about that. We all contribute where we think it will actually make a material difference. And if you disagree, and prefer not to answer "how do you know?", I'll respect that, and will not persist any further on that line of investigation.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 03:43 pm
Now I am getting some action. Up to request #99 in short order. I saw no fails or timeouts. Who is that?

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: PaulS on Nov 30, 2013, 03:46 pm
I opened two tabs in Firefox. I pointed both at your server, and got the home page, with the Waterfall, Soccer, and Test form links. In one tab, I clicked the Soccer link. Then, I went to the other tab, and clicked Waterfall. The soccer picture loaded successfully. The waterfall picture not. I got TestHTML on a white page. Nothing else. I hit the back button, and clicked the Waterfall link again. Got the picture that time.

There is a definite delay in downloading a second picture, while one is downloading in another tab. That is to be expected, knowing that the server is not a multi-threaded, multi-core, processor.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 03:51 pm

The soccer picture loaded successfully. The waterfall picture not.

But Tim said he "saw no fails or timeouts".

What does this tell us? Hmmm...

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 03:55 pm
Thanks, Paul. You are correct about the second image download. Since it is not threading the connections, it services only one request at a time. The ethernet shield is different. My experiments there show the second image request will show on the browser as "connected" with a pause before the download starts because it will accept your connection with another socket. My experiments with the wifi shield show the browser NOT connecting until the previous download is finished. Mine whirs the "connecting" icon until the previous image download is finished.


The soccer picture loaded successfully. The waterfall picture not.

But Tim said he "saw no fails or timeouts".

What does this tell us? Hmmm...

That tells me that the wifi shield is using only one socket. Now you are being stubborn.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 04:00 pm

Now you are being stubborn.


LOL. And I too admire your "persistence" on not answering the simple "How do you know?" question.  :smiley-mr-green:

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 04:04 pm
I know because I have a section of my code that tells me how many sockets are active.  :)

And despite someone's attempt to eat all my sockets, you failed. It is still up and running, but using only one socket. Socket 0.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pico on Nov 30, 2013, 04:10 pm

I know because I have a section of my code that tells me how many sockets are active.  :)


But a socket being active isn't the same thing as the socket sending the correct output, is it?

If you really want to get a handle on things, I suggest you use something like wireshark as a basic debugging tool to see what the shield is _really_ doing, rather than surmising from sections of code that tell you "how many sockets are active".

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 04:13 pm
You didn't get all any of my sockets. You didn't crash my sketch. You didn't download anything. Just a message of "Got socket 1" several times.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 06:21 pm
Here is something interesting I just found. The wifi radio just disconnected from my router. I think this is the same thing that happened a couple days ago, but I thought it was my computer crashing that caused it. It appears from the network that it has failed, but the led shows it is still connected. I am adding more debug functions to check the connection.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: zoomkat on Nov 30, 2013, 06:48 pm
if the original issue is some type of ~2 second delay, then evaluating performance with large files may not be appropriate. I'd use something that would download quickly to evaluate the time latency. You might try loading the below web page (or something simpler with a counter) on your arduino and see how the wifi shield handles the request. In the past I opened the below page in five separate instances of IE, then clicked the fast data on each IE page. I don't remember any page not appropriately refreshing, but didn't run the test for long. Anybody got any salted peanuts?  :)

Code: [Select]

// zoomkat's meta refresh data frame test page 8/17/13
// use http://192.168.1.102:84 in your brouser for main page
// http://192.168.1.102:84/data static data page
// http://192.168.1.102:84/datastart meta refresh data page
// for use with W5100 based ethernet shields
// set the refresh rate to 0 for fastest update
// use STOP for single data updates

#include <SPI.h>
#include <Ethernet.h>

const int analogInPin0 = A0;
const int analogInPin1 = A1;
const int analogInPin2 = A2;
const int analogInPin3 = A3;
const int analogInPin4 = A4;
const int analogInPin5 = A5;

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; //physical mac address
byte ip[] = { 192, 168, 1, 102 }; // arduino ip in lan
byte gateway[] = { 192, 168, 1, 1 }; // internet access via router
byte subnet[] = { 255, 255, 255, 0 }; //subnet mask
EthernetServer server(84); //server port
unsigned long int x=0; //set refresh counter to 0
String readString;

//////////////////////

void setup(){
  Serial.begin(9600);
    // disable SD SPI if memory card in the uSD slot
  pinMode(4,OUTPUT);
  digitalWrite(4,HIGH);

  Ethernet.begin(mac, ip, gateway, gateway, subnet);
  server.begin();
  Serial.println("meta refresh data frame test 8/17/13"); // so I can keep track of what is loaded
}

void loop(){
  EthernetClient client = server.available();
  if (client) {
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
         if (readString.length() < 100) {
          readString += c;
         }
        //check if HTTP request has ended
        if (c == '\n') {

          //check get atring received
          Serial.println(readString);

          //output HTML data header
          //client.println("HTTP/1.1 200 OK");
          //client.println("Content-Type: text/html");
          //client.println();
         
          client.print(F("HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n"));

          //generate data page
          if(readString.indexOf("data") >0) {  //checks for "data" page
            x=x+1; //page upload counter
            client.print(F("<HTML><HEAD>"));
            //meta-refresh page every 1 seconds if "datastart" page
            if(readString.indexOf("datastart") >0) client.print(F("<meta http-equiv='refresh' content='1'>"));
            //meta-refresh 0 for fast data
            if(readString.indexOf("datafast") >0) client.print(F("<meta http-equiv='refresh' content='0'>"));
            client.print(F("<title>Zoomkat's meta-refresh test</title></head><BODY><br>"));
            client.print(F("page refresh number: "));
            client.print(x); //current refresh count
            client.print(F("<br><br>"));
           
              //output the value of each analog input pin
            client.print(F("analog input0 is: "));
            client.print(analogRead(analogInPin0));
           
            client.print(F("<br>analog input1 is: "));
            client.print(analogRead(analogInPin1));
                       
            client.print(F("<br>analog input2 is: "));
            client.print(analogRead(analogInPin2));
           
            client.print(F("<br>analog input3 is: "));
            client.print(analogRead(analogInPin3));
                                   
            client.print(F("<br>analog input4 is: "));
            client.print(analogRead(analogInPin4));
           
            client.print(F("<br>analog input5 is: "));
            client.print(analogRead(analogInPin5));
            client.print(F("<br></BODY></HTML>"));
           }
          //generate main page with iframe
          else
          {
            client.print(F("<HTML><HEAD><TITLE>Zoomkat's frame refresh test</TITLE></HEAD>"
            "Zoomkat's Arduino frame meta refresh test 8/17/13"
            "<BR><BR>Arduino analog input data frame:<BR>"
            "&nbsp;&nbsp;<a href='/datastart' target='DataBox' title=''yy''>META-REFRESH</a>"
            "&nbsp;&nbsp;&nbsp;&nbsp;<a href='/data' target='DataBox' title=''xx''>SINGLE-STOP</a>"
            "&nbsp;&nbsp;&nbsp;&nbsp;<a href='/datafast' target='DataBox' title=''zz''>FAST-DATA</a><BR>"
            "<iframe src='/data' width='350' height='250' name='DataBox'>"
            "</iframe><BR></HTML>"));
          }
          delay(1);
          //stopping client
          client.stop();
          //clearing string for next read
          readString="";
        }
      }
    }
  }
}

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 06:55 pm
Hey, zoomkat! Good to see another friendly face!  :)

It was doing fine. A bunch of abuse earlier in the day, and it survived that. It wasn't doing anything that I could tell when it disconnected. I'm not certain if this is related to the TCP stack or not. I appreciate the offer, but I don't need any salted peanuts. I just did a dance and sprinkled some magic pixie dust on it.  LOL ;)

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Nov 30, 2013, 07:13 pm

Let's not get into this type stuff.

Thank you.  You saved me a long reply.  I would rather not have to talk about personalities and how we all might feel.  I certainly won't be taking advice about such things from PaulS.  

Thank you too Pico, a fair summary.

Quote
I am trying to get the wifi shield working. That is all. I see Matt being a bit stubborn, but I don't mind. A good disagreement sometimes helps. I might not be seeing the whole picture yet.


This is where I am at Tim.  I am new to Arduino and my C++ is extremely rusty.  I am not new to networks or writing sockets applications.  I have about 20 years working in the field behind me.   I won't call you stupid or a liar but I do think the off hand way you dismissed my conclusion was just a little bit rude, after I had gone to quite some trouble to document exactly how I arrived at my conclusion and the limitation of my conclusion.   By all means point out flaws in my reasoning or methods, but don't just say I am wrong without explanation or evidence.

From my point of view, the single ended empirical test you are performing is naive and your reasoning attempts to bypass a fundamental principle of the OSI conceptual model.  Protocols travel vertically and communicate horizontally.  

The analogy I have used before to explain what travelling vertically and communicating horizontally means, is a telephone call overseas.  Imagine I dialled a number in France, my telephone sends the right signals to the wall socket, which sends the right signals to the exchange, which sends the right signals onto the wire and so the far end exchange  gets the right signals, to send to the far end wall socket, to ring the phone at the far end.  The call has travelled down the stack at my end, across the physical layer, up the stack the other end.  Each signalling protocol in the stack having a matching peer at the far end.

The phone get's picked up by someone who only speaks French.  That would be a horizontal protocol mismatch issue. Despite my call travelling across the telephone network perfectly correctly, I can not book my hotel room for next week, unless I conform with the French speaking protocol.  

The web browsers connecting to your WiFi shield are conforming to the TCP protocol.  Your shield is not conforming to the TCP protocol.  What might then happen at the application layer is undefined.

Imagine after the phone was answered, I did not wait for an acknowledgement and just blurted out my booking and put the phone down.   There are a finite number of possible outcomes.  
+ The receptionist somehow made sense of my booking and I get my room next week.  
+ The receptionist made some sense of the booking and I get the broom cupboard, sometime next year.  
+ The receptionist made no sense of my booking and ignored the call.
I can not know what happened without reference to the other end.

As it is with your application.  It might work some of the time in some condition but it will not work all of the time in all conditions.  You can not tell when it has and has not worked by looking at the application layer at your end, in isolation.

Quote
I see one socket being used by the server. None of my web browsers will establish a connection while I am downloading the images.

Your empirical observation is the web browsers do not download the image.  You do not know what state the client sockets are in.  You can keep guessing, or you can download Wireshark, see what order the SYNs, FINs, RSTs and ACKs occur in and have some clues to work with.  I could do it for you but I am not in any need of a TCP primer.

BTW the latest logs. Still getting the wrong pictures in the wrong files.  A couple requests in quick succession, is all it takes.  No I have not tried to crash your shield.  I have been careful to limit my end to make no more than four simultaneous requests.

Code: [Select]

R#, LEC, Bytes, ms, Kbps, Resource
R1 102 27199 5689 38.248 r1-skt2-img-wolver.jpg
R2 102 0 13406 0 r2-skt1-IMG-WATERFAL.JPG
R3 102 17504 2635 53.143 r3-skt5-IMG-WATERFAL.JPG
R4 102 27199 12044 18.066 r4-skt4-img-wolver.jpg
R5 102 0 18711 0 r5-skt7-IMG-WATERFAL.JPG
R6 102 17504 26738 5.237 r6-skt10-img-wolver.jpg
R7 102 0 32299 0 r7-skt8-img-wolver.jpg
R8 102 27199 25985 8.374 r8-skt9-IMG-WATERFAL.JPG
R9 102 0 33677 0 r9-skt3-IMG-WATERFAL.JPG
R10 102 0 24768 0 r10-skt6-img-wolver.jpg

R#, Resource, Request, Headers
R1 r1-skt2-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R2 r2-skt1-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R3 r3-skt5-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R4 r4-skt4-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R5 r5-skt7-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R6 r6-skt10-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R7 r7-skt8-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||
R8 r8-skt9-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close|| HTTP/1.0 200 OK|Content-Type: image/jpeg|Connection: close||
R9 r9-skt3-IMG-WATERFAL.JPG GET /IMG/WATERFAL.JPG HTTP/1.1|Host:68.99.58.119|Connection:close||
R10 r10-skt6-img-wolver.jpg GET /img/wolver.jpg HTTP/1.1|Host:68.99.58.119|Connection:close||


Quote
Since it is not threading the connections, it services only one request at a time.


Sorry but you are wrong.  You may not have thought out how it can be done but it can be done.  Multiplexing has been around a lot longer than multi-cored PCs running multi-threaded operating systems.  Squirt a bunch of data into a bunch of buffers, each intended for a different target address.  Apportion the CPU time between the buffers, pull the data out in frames, add the target address, write the frame to the wire, move on to the next buffer.  The frames appear interleaved on the wire.  One CPU, one thread of execution, producing multiple streams, with the CPU time divided between all streams.  TCP is session based, which infers communicating session state, which is what the shield is failing to do.


Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 07:42 pm
Thanks for the help Matt. I appreciate your input. You have been working with the wifi shield longer than I have, so I hope I can get a little more insight from you. I don't mind if you try to crash it. I try, and sometimes I can, but not lately. My only request is if you can crash it, please tell me how you did it. Maybe we can work out a way to prevent it.

If the Mega is not threading, the shield can't thread. I have been working with that for a while with Linux boxes. I have a couple years with the ethernet shield, and it "threads" the connections by accepting the connection before the Mega can get to it, but the ethernet library will service only one of those sockets at a time. I am familiar with how my web browsers respond to that, and this is not the same. I have experimented with servicing multiple sockets with the w5100, but the Mega and the SPI bus is a bit too slow for that.

The disconnect did not appear to crash the Mega, but I wasn't set up to check the wifi connection, so I don't know what happened to the wireless connection. It could be TCP related, and just manifested itself after the workout it got this morning.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Nov 30, 2013, 07:49 pm
It just disconnected again, and the Mega is not responding to the serial port.  :(

edit: MY BAD!! The Mega is responding, but the wifi shield isn't.
edit2: The wifi shield just started responding again, and shows no connection to the router. Let me work on that. The odd part is the connection LED is still green, and remains green even if I disable the wifi radio in the router. ??

Fortunately, I enabled wireless debugging in my router before restarting the Arduino. It shows "disconnected, group key exchange timeout". That is normally related to WPA2 encryption.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 04:42 am
Quote
BTW the latest logs. Still getting the wrong pictures in the wrong files.  A couple requests in quick succession, is all it takes.

My apology for not reading more carefully, I didn't read this correctly the first time through. I have never gotten the waterfal.jpg image when requesting the wolver.jpg image, or vice versa. It has always been the correct image. Has anyone else gotten the wrong image? Give it a try.
Soccer picture http://68.99.58.119/img/wolver.jpg
Waterfall picture http://68.99.58.119/img/waterfal.jpg

I just requested both images 3 times in quick succession, and got the correct image each time.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 01, 2013, 07:25 am
I tried the same test, not only where the file names mismatched, but there was significant data corruption. Check out the images I have attached. I couldn't save the images directly in the browser as the cache only keeps the last downloaded version.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: zoomkat on Dec 01, 2013, 09:41 am
I tried a simple test where I made five instances of IE with the waterfall.jpg url loaded, then clicked go in quick succession. Four of the five request would download one at a time. The last IE instance clicked will finally time out after the first four have finished downloading. I would suspect that maybe the first four IEs got a socket on the server, and no socket may have been available for the fifth IE instance. None of the pix were corrupted. Screen capture attached.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 12:25 pm
All my test are similar to zoomkat's. I have never gotten corruption or the wrong image. Ever. And I have tried to duplicate the fails here, but I can't, even after dozens of attempts. It times out if I try multiple image downloads, but doesn't get the wrong image nor are the images corrupted.

However, I am having another challenge with the shield. It is crashing after about 100 image downloads. It crashed twice yesterday, and again this morning. WiFi.status() reports "no shield" (255).

edit: So there is corruption and incorrect images in Australia and the U.K., but not in North America? Is that what I am hearing? I am wondering if there is something I can add to the header to prevent caching of the images.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 01, 2013, 01:19 pm
Quote
So there is corruption and incorrect images in Australia and the U.K., but not in North America? Is that what I am hearing? I am wondering if there is something I can add to the header to prevent caching of the images.


This is how I do it in PHP, you can translate the headers to suit your needs.

Code: [Select]
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, max-age=0, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");


If you have a time source, use the current time (GMT)  for 'Last-Modified'
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 01:28 pm
Thanks pYro_65. I think the expires, pragma, and cache-control may do it.

I am working on why it is crashing right now. It does no good to prevent caching if the dang thing is crashing. Wow, that almost rhymes! Maybe a new song? LOL
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 01, 2013, 01:37 pm

Thanks pYro_65. I think the expires, pragma, and cache-control may do it.


Different header combinations of the above set are used by different browsers/version implementations. Without the last-modified, some systems/proxies may still cache the file until they are sure there is new content, not just the possibility.

But caching doesn't seem to be the problem here, and would alleviate a lot of excess connections of a feature full website served from the Arduino.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 01:46 pm
Thanks for your input, pYro_65. I don't know what else to try. I see others downloading the images, so maybe I can get some feedback from them. It is up to 33 downloads and hasn't crashed yet. That is a good thing, I guess. But it usually malfunctions around 100. Then it will need a power cycle to get it running again.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 01, 2013, 02:04 pm
Here is some useful debug info. I have received a few more corrupt images, but just received the favicon instead.
From looking at the headers, it appears it may be a bug in your code, as it sends an icon type, not just wrong data.

Quote
Request URL:http://68.99.58.119/img/waterfal.jpg
Request Method:GET
Status Code:200 OK
Request Headers
GET /img/waterfal.jpg HTTP/1.1
Host: 68.99.58.119
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.1.0.0 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
DNT: 1


Response Headers
HTTP/1.0 200 OK
Content-Type: image/x-icon
Connection: close
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 02:12 pm
I just checked my code, and it is correct, but I show the client requested the waterfall image, and then immediately requested the favicon.ico file. It must be getting messed up in the wifi shield firmware somehow.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 01, 2013, 02:18 pm
Lucky I didn't let the browser page close, cos as you say it did load the favicon. After a short delay the tab changed its icon to that of the waterfall picture. If the wifi shield is at fault, then that is a huge blunder, no need to hack security if you can just steal someones socket.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 01, 2013, 02:30 pm
That may be the challenge. I show both images were downloaded correctly, but one immediately after the other. Maybe the firmware is overwriting the first send with the second. but that would be a very serious bug in the firmware. That means it is sending TCP stuff like UDP. The shield is saying "yes, I delivered it", when in fact it hasn't even started to send it yet.

Maybe I owe Matt an apology.

edit: I don't think you stole anybody's socket. I think the firmware overwrote your socket when your web browser requested the icon. That may be what Matt was trying to get across to me.

It would be extremely helpful if I could access the remote IP and port requesting the files. If they are the same on both requests, that would explain a lot, and maybe help fix this.

@MattS_UK: If I haven't pissed you off to the point you quit reading this thread, can you tell me if your software uses the same port to request the images? Maybe that will help fix this. BTW, I apologize for not understanding what you were trying to tell me.

That could be causing the crashes. I don't know how much internal memory the wifi shield has, but if a client requested two images like the waterfall and the soccer pics back-to-back, the resulting memory use could overflow the internal memory and crash the processor.
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: pYro_65 on Dec 02, 2013, 01:49 am
Quote
edit: I don't think you stole anybody's socket. I think the firmware overwrote your socket when your web browser requested the icon. That may be what Matt was trying to get across to me.


Yeah, not stole, but If the wrong remote socket data can be sent to my local socket, then someone could effectively receive my potentially private/secure page that I have requested.

Quote
It would be extremely helpful if I could access the remote IP and port requesting the files. If they are the same on both requests, that would explain a lot, and maybe help fix this.


You could mimic the session ID with a sequential ID, then browsers, will respond with the ID string you provide. Not useful for a first request, but subsequent requests should contain the ID.

Why not just do the mods you where talking about ( or was that the Ethernet shield only ).
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: SurferTim on Dec 02, 2013, 03:07 am
The mods I talk about are to the ethernet library. The w5100.h file has code that I can get the remote ip and port of a client TCP connection. Unfortunately, the library code for the wifi shield does not have the same type code to retrieve those for a TCP connection, at least not that I have discovered yet. I'm still looking tho. There is code to get the remote ip and port for UDP packets, but it doesn't work for TCP connections.

I don't think any connection to an Arduino will be very secure. I use UDP packets with a passphrase to identify my packets from others, but that is not really secure. Any competent hacker somewhere between my computer or cellphone and the Arduino could get it with wireshark or a packet sniffer. A "man-in-the-middle" attack is a common hack. Only a localnet wired connection is anywhere close to safe. As long as there is nothing to be gained by a hacker breaking your security, you are ok.

edit: I am starting a separate thread for the server problem
http://forum.arduino.cc/index.php?topic=202302.0

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: msssltd on Dec 03, 2013, 03:38 pm
Quote from: SurferTim
Maybe I owe Matt an apology.


:smile:  Thank you.  Very much appreciated.

Quote
@MattS_UK: If I haven't pissed you off to the point you quit reading this thread, can you tell me if your software uses the same port to request the images? Maybe that will help fix this. BTW, I apologize for not understanding what you were trying to tell me.


You haven't pissed me off Tim.  You just frustrate me.  I don't like blowing my own trumpet  but honestly, after 20 years in the  business, I have learnt a thing or two.

In my client application (running on a PC), I create a new socket for each request.  A new source port number is assigned to each new socket, by the Sockets API.  The HTTP request is sent within the socket's Connected event handler.

As I said previously, Wirshark shows the Shield does not adhere to the TCP protocol. The issues you are seeing at the application layer are 'just' symptoms of the poor TCP implementation.  The shield may have other bugs but they can not be properly diagnosed until the bug in the TCP implementation has been fixed.

Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: cantore on Dec 04, 2013, 05:30 pm
I totally agree with liudr. in my opinion arduino wifi shield is not ready for the market.
I suggest you to use wifi_dnld.elf version 2.7 with wifiHD.elf version 26 March 2013 with libraries included in ide 1.0.5. This combination is the one that gives me no problems with wifi shiled that uses ATMEL 32UC3A1512-U (wifi v023-Rev3.B). Does anyone know the right combination of firmware/drivers for the model with ATMEL 32UC3A1256-U (wifi v023-Rev3.A)?
Thanks

I suggest to read this post about wifi shield
http://forum.arduino.cc/index.php?topic=167742.0
Title: Re: Thumbs way down for Arduino WiFi shield. Read before you buy
Post by: Ries on Jan 03, 2014, 04:54 pm
Unfortunately I read your post only after I purchased the Arduino WiFi shield. I can only confirm everything. The first results were encouraging until I found out that the WiFiShield is unreliable. The well known server hangs issue discussed a year ago. It cost me a lot of time as I tried many workarounds. The documentation is lousy as mentioned.  I updated the firmware to the latest stable (1.0.5) .  I need WiFiUdp for synchronizing time so I can not use the previous ( 1.0.4). The main Arduino was working fine only the server hang at intervals ranging from 1 hour to three days.  I tried using the watchdog <avr/wdt.h>  for a reset if  server.status() != 1.  Even that did not work: apparently the shield is not reset this way, but only the main board ( Arduino mega )  and  WiFi.begin(ssid, pass);  fails in the setup() after restart from watchdog. I give up very angry and frustrated and will order a shield from another vendor.