Send dummy byte fix
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: Send dummy byte fix
by lawrence WIZnet ·
Hi, BruceTanner
At the result, if your W5300 running as only receiver and server can not accept dummy byte, there is no way for zero window size problem…
In case of W5300, if it sends packet, there is no problem with window size.
but if it is running only receiver(no sending packet), the only way to notice window size to server is sending dummy byte or any acceptable packet data with window size.
And w5300 can not send zero window size packet.
// M_15052008 : Replace Sn_CR_SEND with Sn_CR_SEND_KEEP. //if(!(getSn_IR(s) & Sn_IR_SENDOK)) //{ // setSn_TX_WRSR(s,0); // size = 0 // setSn_CR(s,Sn_CR_SEND); // send // while(!(getSn_IR(s) & Sn_IR_SENDOK)); // wait SEND command completion // setSn_IR(s,Sn_IR_SENDOK); // clear Sn_IR_SENDOK bit //}I wonder how it works in your lab…
So, If you keep using W5300 as only receiver in this case, find a server which can accept dummy packet data or there is no way…
In this case, I recommend w5500 or w5200… because it is ok to send zero window size but before that please compare the spec with w5300.
I hope it will be helpful.
Thank you.
lawrence
RE: Send dummy byte fix
by BruceTanner ·
Hi Lawrence,
Thank you for your reply. Can I show you two packet captures from Wireshark please? The first is the known problem: the window size reaches 0 at packet 251 and the server then pauses for 5 seconds. This what we would expect with the known w5300 problem.
The second capture is with a zero-length send at packet 73, sent when the receiver has no packets to read, and which Wireshark helpfully decodes as “TCP window update”! (And again at 82). This fixes the problem: there is no server pause.
(Please note there are two sockets active here: the data and the control. So ignore anything between ports 20 and 21 - these are the control socket packets),
So a zero length send fixes the problem in this situation. Looking at WIZnet’s socket.c, it looks like that was WIZnet’s first fix too, but then it was changed to a fix involving Keep Alives, and then changed again to actually sending one byte.
So my question is: what were the circumstances where WIZnet’s original zero-length-send fix did not work? It would be useful to know the details so that I know when my own zero-length send fix might not work.
RE: Send dummy byte fix
by ab0tj ·
I’m curious if this worked for you long-term? I tried sending zero-byte packets when Sn_RX_RSR reaches zero like in the code snippet, and this seems to work for a while. Eventually, though, sends stop working because the SENDOK flag never gets set.
RE: Send dummy byte fix
by BruceTanner ·
It worked “well enough” for a while, not a high-traffic application, but long term…I designed a pin-compatible module using an ESP8266 and Xylinx CPLD that has 5V compatible i/o! It works properly, protocol code is stored in updatable FLASH, wifi, simpler host interface. Quicker to re-write your own code (and you always do it better the second time) than constantly tripping up on other people’s unfixed bugs and trying to work around them!