heinbali01 wrote on Thursday, August 11, 2016:
About ‘ipconfigTCP_HANG_PROTECTION’ : I don’t think there is an issue with the anti-hanging protection. There is indeed a difference in behaviour, and for good reasons:
#if( ipconfigTCP_HANG_PROTECTION != 0 )
/* You will only see a new socket as soon as the 3-way hand-shake is ready. */
/* You will receive a new socket immediately after its creation,
i.e. after the first SYN. */
With anti-hanging protection, the IP-stack takes care of the new socket until it is fully connected. In case it fails, the socket will be closed by the stack. It will have a timer running, so incase the peer dies, the socket will be closed by the stack.
Without the anti-hanging protection, the application is made responsible for closing the new socket in case the 3-way handshake was not successful.
With ‘ipconfigTCP_HANG_PROTECTION == 0’ your select() will return a READ event, and accept() does succeed, but the 3-way handshake is still failing.
Later we found why the handshake didn’t work: there was a misconception about
xNetworkInterfaceOutput() should work.
NetworkBufferDescriptor_t * const pxNetworkBuffer,
BaseType_t xReleaseAfterSend )
xReleaseAfterSend is false, it means that the NetworkBuffer is passed as read-only. Once the function
xNetworkInterfaceOutput() returns, the NetworkBuffer may not be accessed any more.
xReleaseAfterSend is true, the ownership of the NetworkBuffer is passed to the driver and the driver may (must) release the buffer after using it. It may still be accessed after returning from the function.
A driver that works with so-called zero-copy transmissions will define:
#define ipconfigZERO_COPY_TX_DRIVER ( 1 )
These drivers will always be called with
xReleaseAfterSend == true. The Network Buffers will be passed to DMA. When DMA is ready transmitting a buffer, it shall be released by the driver.