Can't tell if this is the client or the server, but either way, make
sure your Windows system is configured to disable Ack Delay, You can
Google TCPAckFrequency and TCPNoDelay, or see
http://us.battle.net/d3/en/forum/topic/5578595314 for instructions. You
will have to reboot your Windows box
Mike He wrote:
If my understanding is correct, the pbuf that is passed to our recv callback
is only the first in a chain, where we must traverse the chain to obtain the
full packet?
[..]
Why would there be two conditions? Is ever one true when the other isn't? How
do the lengths add up
Hi, following is MY opinion (and experience)
1: Since the callback function is called by the stack as I instructed, I
wouldn´t answer with ERR_ARG, since arg is just as I instructed the
stack to call me... so, if you still do it because you don't trust the
stack, then don't rely on it to stop
Thanks Sergio,
1. Can you point me to a description of how to use the different error
codes, then?
3. I just located the httpserver_raw in vendor's lwip package. It also
doesn't call tcp_accepted. Perhaps the problem is that my vendor is
using an outdated version, 1.3.2?
On 5/30/2014
Thanks Sergio,
1. Can you point me to a description of how to use the different error
codes, then?
3. I just located the httpserver_raw in vendor's lwip package. It also
doesn't call tcp_accepted. Perhaps the problem is that my vendor is
using an outdated version, 1.3.2?
On 5/30/2014
Mike He wrote:
3. I just located the httpserver_raw in vendor's lwip package. It also
doesn't call tcp_accepted. Perhaps the problem is that my vendor is using an
outdated version, 1.3.2?
That could well be. Tcp_accepted is our implementation of a listen backlog. You
don't need to call it
Thanks so much for your help Simon.
I'd like to upgrade to the latest version. To your knowledge, have there
been major changes since 1.3.2 with respect to how to write driver code
to interface with our hardware?
Thanks,
Mike
On 5/30/2014 12:53 PM, Simon Goldschmidt wrote:
Mike He wrote:
1. Can you point me to a description of how to use the different error
codes, then?
Just follow the goto 3
1: [...] goto 3;
3: [...] check the available examples in the contrib tree: SMTP for a
client, netio/httpserver_raw for a server
AFAIK callback functions return ERR_OK when they do
At long last, I understand the problem. The lesson I learned is that you can't
trust the packet ether addresses -- they were being faked by the Cisco hardware
(sending a packet with someone else's source address). The problem itself is a
case of a poorly designed ARP proxy/optimization within
