AsyncLabs Forums

[John_Ryan]

So it flashes on and off every 1 second?

[GregEigsti]

Nope, it loses WiFi connection (board seems to reset) every time the large UDP packet is sent by the PC/Mac. Only happens with WiServer so my guess is that WiServer needs a little attention around how it filters out "bad" packets. Looked at the WiServer code for a tiny bit and saw nothing obvious.

Greg

[aerodyno]

How do we get the WiServer author to pay attention? I am reaching the point where I want to pay him to fix these problems. Perhaps we can get a little fund going?

-s

[John_Ryan]

I'm sure they are observing the issues people are having, and probably having the same problems themselves.

I think there needs to be a more formal approach to dealing with these 'bugs'. Perhaps a section of the forum can be created with a dedicated thread to register known issues, although some are rather difficult to summarize because they appear to happen only occasionally without any good reason.

Stability is a big concern, but I personally believe the remedy is to keep user applications separate from the Arduino that's connected to the WiFi, and once I get the time, I'll be testing the yellowjacket connected over i2c to my spare NG to determine if that eliminates some of these occasional bugs.

[mfm219]

Greg -

My experience was that the resetting problem occurred for multiple applications: WebServer, Socket and WiServer. I cannot reproduce the problem currently, but I believe you are correct that WiServer was the most reproducible. The resets would start happening immediately as soon as the offending computer issuing the UDP broadcasts became active. Sometimes the WebServer would work for a while (<30 min) before starting to reset. Since this is from memory, I can't be too definitive but I know I tried switching to other apps to see if I could avoid the problem and was not successful.

Mike

[GregEigsti]

mfm219, thanks! Good input. The other night I could not repro with the TCP or UDP socket app that I had running on a "spare" WiShield (sitting on the couch next to me) but the WiServer app reset everytime. Also have several minion WiShields running at the house (TCP socket apps) and they kept on running during my UDP blasting.

I'd really be a lot more interested in a non-WiServer reproduce case.
Greg

[GregEigsti]

FWIW - here is the PC/Mac based "udp blaster" app that I was running to repro the problem. Its a command line app that just sends a single large UDP broadcast. It was built/run on a Mac and should translate directly to *nix. It will mostly work on Windows but will need a couple tweaks.

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define BROADCAST
#define LOCAL_PORT      6647
#define REMOTE_PORT      6646

#ifdef BROADCAST
//#define MAXDATASIZE      1472
#define MAXDATASIZE      1320
#else
#define MAXDATASIZE      8192
#endif // BROADCAST


int main()
{
   int iter;
   int sockfd;
   int numbytes;
   int nOptVal;
   int nOptLen = sizeof(int);
   struct sockaddr_in local;
   struct sockaddr_in remote;
   char buf[MAXDATASIZE];
   
   for(iter = 0; iter < 10; iter++) {
      memset(&remote, 56, sizeof(remote));
      
      // setup IP address of WiShield
      remote.sin_family = AF_INET;
      remote.sin_port = htons(REMOTE_PORT);
#ifdef BROADCAST
      inet_pton(AF_INET, "255.255.255.255", &remote.sin_addr);
#else
      inet_pton(AF_INET, "192.168.1.248", &remote.sin_addr);
#endif // BROADCAST   
      
      // setup socket and connect
      if ((sockfd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1) {
         perror("socket");
         exit(0);
      }
      
#ifdef BROADCAST
      //set broadcast socket option
      nOptVal = 1;
      if(-1 == setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &nOptVal, nOptLen)) {
         perror("setsockopt");
         close(sockfd);
         exit(0);
      }   
#endif // BROADCAST   
      
      //set the packet size
      nOptVal = 65535;
      if(-1 == setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &nOptVal, nOptLen)) {
         perror("setsockopt");
         close(sockfd);
         exit(0);
      }   

      // bind to a specific port on the PC
      local.sin_family = AF_INET;
      local.sin_port = htons(LOCAL_PORT);
      local.sin_addr.s_addr = INADDR_ANY;
         
      if ( bind(sockfd, (struct sockaddr *)&local, sizeof(local)) == -1) {
         perror("bind");
         exit(0);
      }

      // send "Hello" to WiShield
      if ((numbytes = sendto(sockfd, buf, MAXDATASIZE, 0, (struct sockaddr *)&remote, sizeof(remote))) == -1) {
         perror("sendto");
         exit(1);
      }

      printf("iter: %d, total: %d, sent %d to port %d\n", iter, MAXDATASIZE, numbytes, REMOTE_PORT);   
      close(sockfd);
      sleep(20);
   }

   return 0;
}

[ghostbust555]

How many people with this problem have at least one computer on your network that runs McAffee? Because the McAffee Network Agent service (McNASvc) is what was causing my board to reset. try disabling this service on all computers with McAffee and see if it doesn't make a difference.

[spidermonkey04]

Good thing I remembered this thread, I think I found the culprit. From what I can tell, the zg2100 modules internal buffer can hold a packet up to 4096 bytes. If a packet is destined for the WiShield ( be it multicast or whatever ), the driver blindly copies the whole packet into the uip_buf (400 byte default?). So if the packet was 1300 bytes, some other important stuff could be overwritten which might cause a board reset. Here's the code from g2100.c that does it. ( in zg_process_isr() )

Code: Select all

case ZG_INTR_ST_RD_CTRL_REG:
      {
         U16 rx_byte_cnt = (0x0000 | (hdr[1] << 8) | hdr[2]) & 0x0fff; // only 12bits matter (0-4095)

         zg_buf[0] = ZG_CMD_RD_FIFO;
         spi_transfer(zg_buf, rx_byte_cnt + 1, 1); // copy ZG2100 buffer contents into zg_buf

         hdr[0] = ZG_CMD_RD_FIFO_DONE; // Tell zg2100 we're done reading from it's buffer
         spi_transfer(hdr, 1, 1);

         intr_valid = 1;

         intr_state = 0;
         break;
      }

Now, I haven't had this problem. I was just going through the driver code. So I'm hoping someone else could give this a try. Let's just add a simple check to see if the packet will fit in our buffer before trying to put it there.

Code: Select all

case ZG_INTR_ST_RD_CTRL_REG:
      {
         U16 rx_byte_cnt = (0x0000 | (hdr[1] << 8) | hdr[2]) & 0x0fff; // only 12bits matter (0-4095)
           
         if ( rx_byte_cnt < (U16)UIP_BUFSIZE ){ // Check if our buffer is large enough for packet

               zg_buf[0] = ZG_CMD_RD_FIFO;
               spi_transfer(zg_buf, rx_byte_cnt + 1, 1); // copy ZG2100 buffer contents into zg_buf (uip_buf)
   
               hdr[0] = ZG_CMD_RD_FIFO_DONE; // Tell ZG2100 we're done reading from it's buffer
               spi_transfer(hdr, 1, 1);
   
               intr_valid = 1;
   
               intr_state = 0;
               break;
            }else{ // Too Big, ignore it and continue
                 intr_valid = 0;
                 intr_state = 0;
                 break;
                 }
      }

Hope this works, it would definitely make the WiShield more robust.
---Jared

[spidermonkey04]

Well I feel like an a-hole. MarkV basically pinpointed the problem in that other Fios thread referenced earlier. This code should fix it though...

---Jared