AsyncLabs Forums

[shard7]

Overall, the new stack is nice and stable, but every now and then my code has been acting strangely. A few print statements showed that some of my data was getting corrupted in RAM (and of course my code would never do such a thing )

To verify this, I malloc'd 32 bytes right after the stack was initialized, set all to 0, and then checked the content each time the app callback function is called by the stack. Sure enough, 7 bytes are being overwritten by the stack code (looks like the last 7 bytes of received data when the packet size is maxed out).

I added some code to the zg_process_isr() function in g2100.c to monitor how much data was being written into the uip buffer in the ZG_INTR_ST_RD_CTRL_REG state where it reads the contents of a received data packet and stores it in the uip buffer. Sure enough, with the default UIP_CONF_BUFFER_SIZE of 400 bytes, I was seeing rx_byte_cnt values of 416! With the extra byte for the command at element 0, that means 417 bytes were being written in the 400 byte uIP buffer. When this occurred, the received data at the app level was reported to be 346 bytes (the correct maximum payload for a 400 byte buffer).

This is a pretty serious bug, so I hope you guys will be able to fix it soon (do let me know if I can be of further assistance). In the meantime, I'll probably keep my malloc(32) as a safety buffer between the stack and my data.

[shard7]

Looks like one possible 'fix' for this issue is to add the following in uip-conf.h:

#define UIP_CONF_RECEIVE_WINDOW 329

This overrides the default 'calculated size' generate by uIP. It appears that there's a 71 byte overhead including the command byte for the wifi module, so with a 400 byte buffer, 329 works like a champ (even with the safety malloc removed!)

I'm sure there's a nicer way to arrive at this number by adding a bunch of #defines together, but this seems to work for now.

[gsxrex]

Hmmm, we'll look into it. Is this easily reproducible, or something that just happens every so often?

[shard7]

It happens every time a large packet is received that fills the entire buffer. I added some instrumentation and the bytes read in from the module in g2100.c are consistently 71 more than the size of the data itself. So, with a 400 byte buffer and the default mss calculated at 346, it consistently writes 417 bytes into the buffer. Smaller packets don't run over the end of the buffer, but they do exhibit the same 71 byte overhead.

The fix I suggested by specifying a smaller receive window is working very well (I currently have three different browsers on two machines reloading a page every 15 seconds, seems really solid now).

[benquark]

That was a very good catch . You're right, there is a 71 byte overhead for each TCP packet. This is how it adds up,

Code: Select all

#define ZG_CMD_LEN            1
#define ZG_CMD_TYPE_LEN       1
#define ZG_CMD_SUBTYPE_LEN    1
#define ZG_RX_IND_LEN         20
#define LLC_802_11            8
#define UIP_TCPIP_HLEN        40


The following lines in uipopt.h can be added/modified to fix this bug,

Code: Select all

#define ZG_RX_HDR_LEN     17    // ZeroG G2100 RX Indicate header length
#define UIP_TCP_MSS      (UIP_BUFSIZE - UIP_LLH_LEN - UIP_TCPIP_HLEN - ZG_RX_HDR_LEN)


Surprising how this sneaked into our thoroughly SQA'd source code . Thanks for the work.

[shard7]

Excellent, that makes sense. Glad I could help out.