Dear Support team, I am trying to port FreeRTOS+TCP on some board with NXP LPC1788. I’ve set static parameters for the ethernet: IP addr: 10.0.0.120, Subnet Mask: 255.0.0.0, Gateway: 10.10.10.203, etc. Pings work. I can’t connect to www.google.pl properly on port 80. Traffic (simple) from WireShark: No. Time Source Destination Protocol Length Info 17260 218.560781000 10.0.0.120 216.58.215.99 TCP 66 62613 > http [SYN] Seq=0 Win=1160 Len=0 MSS=1160 WS=1 SACK_PERM=1 17264 218.706837000 10.0.0.120 216.58.215.99 TCP 60 62613 > http [ACK] Seq=1 Ack=1 Win=1000 Len=0 18108 233.896105000 10.0.0.120 216.58.215.99 TCP 60 62613 > http [FIN, ACK] Seq=1 Ack=1 Win=1000 Len=0 18110 233.909657000 216.58.215.99 10.0.0.120 TCP 60 http > 62613 [FIN, ACK] Seq=1 Ack=2 Win=238 Len=0 Log from program: prvIPTask started FreeRTOSconnect: 62613 to d83ad763ip:80 Socket 62613 -> d83ad763ip:80 State eCLOSED->eCONNECTSYN ARP for d83ad763ip (using a0a0acbip): rc=0 00:00:00 00:00:00 Connect[d83ad763ip:80]: next timeout 1: 500 ms ARP for d83ad763ip (using a0a0acbip): rc=0 00:00:00 00:00:00 Connect[d83ad763ip:80]: next timeout 2: 500 ms prvSocketSetMSS: 1160 bytes for d83ad763ip:80 Limits (using): TCP Win size 1160 Water 0 <= 0 <= 1000 vTCPWindowCreate: for WinLen = Rx/Tx: 1160/1160 prvWinScaleFactor: uxRxWinSize 1 MSS 1160 Factor 0 Connect[d83ad763ip:80]: next timeout 1: 3000 ms MSS change 1160 -> 1380 TCP: active 62613 => d83ad763ip:80 set ESTAB (scaling 1) Socket 62613 -> d83ad763ip:80 State eCONNECTSYN->eESTABLISHED Send[62613->80] imm ACK 1 SEQ 1 (len 40) Socket 62613 -> d83ad763ip:80 State eESTABLISHED->eFINWAIT1 GO : d83ad763ip:80: [0 < 0] winSize 0 FreeRTOSclosesocket[62613 to d83ad763ip:80]: buffers 143 socks 0 The code for simple client:

Socket_t xSocket;
struct freertos_sockaddr xServerAddress;
int16_t ret=0;

xServerAddress.sin_port = FreeRTOS_htons(80);
xServerAddress.sin_addr = FreeRTOS_inet_addr_quick(216,58,215,99);

for(;;)
{
    xSocket = FreeRTOS_socket( FREERTOS_AF_INET, FREERTOS_SOCK_STREAM, FREERTOS_IPPROTO_TCP );

    if(xSocket==NULL)
    {
        while(1);
    }

    ret=FreeRTOS_connect( xSocket, &xServerAddress, sizeof( xServerAddress ));

    if( ret == 0 )
    {
        vTaskDelay(15000);

        FreeRTOS_shutdown( xSocket, FREERTOS_SHUT_RDWR );

        for(uint8_t j=0; j<3; j++)
        {
            ret=FreeRTOS_recv(xSocket, (void *)RecvBuf, 0x30, 0);
            if((ret==FREERTOS_EINVAL) || (ret==FREERTOS_ECLOSED))
                break;
        }
    }
    FreeRTOS_closesocket( xSocket );

    ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
}

TCP stack doesn’t wait for SYN+ACK from server. Could anyone give me some advice how to solve this problem? Thanks, Kamil

Hi Kamil, that is a very strange TCP conversation. Could you save the data in a PCAP file and post it here? I’m missing the time stamps. When using WireShark, you can filter the data of interest with e.g. “ip.addr==216.58.215.99”

Hi Hein, thank you for reply. I moved to another computer and increased the time between connect and disconnet. I got this log from WireShark: No. Time Source Destination Protocol Length Info 28921 28.555858 10.0.0.120 216.58.215.99 TCP 66 62615 → 80 [SYN] Seq=0 Win=1160 Len=0 MSS=1160 WS=1 SACKPERM=1 28947 28.569736 216.58.215.99 10.0.0.120 TCP 66 80 → 62615 [SYN, ACK] Seq=0 Ack=1 Win=60720 Len=0 MSS=1380 SACKPERM=1 WS=256 29080 28.703008 10.0.0.120 216.58.215.99 TCP 60 62615 → 80 [ACK] Seq=1 Ack=1 Win=1000 Len=0 43494 52.433765 10.0.0.120 216.58.215.99 TCP 60 [TCP Keep-Alive] 62615 → 80 [ACK] Seq=0 Ack=1 Win=1000 Len=0 43496 52.446884 216.58.215.99 10.0.0.120 TCP 60 [TCP Window Update] 80 → 62615 [ACK] Seq=1 Ack=1 Win=60928 Len=0 45774 74.963763 10.0.0.120 216.58.215.99 TCP 60 [TCP Keep-Alive] 62615 → 80 [ACK] Seq=0 Ack=1 Win=1000 Len=0 45775 74.978074 216.58.215.99 10.0.0.120 TCP 60 [TCP Keep-Alive ACK] 80 → 62615 [ACK] Seq=1 Ack=1 Win=60928 Len=0 57846 97.559412 10.0.0.120 216.58.215.99 TCP 60 [TCP Keep-Alive] 62615 → 80 [ACK] Seq=0 Ack=1 Win=1000 Len=0 57962 97.607215 216.58.215.99 10.0.0.120 TCP 60 [TCP Keep-Alive ACK] 80 → 62615 [ACK] Seq=1 Ack=1 Win=60928 Len=0 96086 120.025047 10.0.0.120 216.58.215.99 TCP 60 [TCP Keep-Alive] 62615 → 80 [ACK] Seq=0 Ack=1 Win=1000 Len=0 96088 120.038673 216.58.215.99 10.0.0.120 TCP 60 [TCP Keep-Alive ACK] 80 → 62615 [ACK] Seq=1 Ack=1 Win=60928 Len=0 111706 129.593765 10.0.0.120 216.58.215.99 TCP 60 62615 → 80 [FIN, ACK] Seq=1 Ack=1 Win=1000 Len=0 111867 129.661462 216.58.215.99 10.0.0.120 TCP 60 80 → 62615 [FIN, ACK] Seq=1 Ack=2 Win=60928 Len=0 112053 129.752738 10.0.0.120 216.58.215.99 TCP 60 62615 → 80 [ACK] Seq=2 Ack=2 Win=1000 Len=0 It looks better than the first log. I use the same version of WireShark on both computers. Firewall is turned off. I suppose that eth card is cutting packets. It cuts ARP Gratitious packets also. But this problem is for different topic. Thanks, Kamil

28921 28.555858 10.0.0.120 216.58.215.99 TCP 66 62615 → 80 [SYN] Seq=0 Win=1160 Len=0 MSS=1160 WS=1 SACKPERM=1 28947 28.569736 216.58.215.99 10.0.0.120 TCP 66 80 → 62615 [SYN, ACK] Seq=0 Ack=1 Win=60720 Len=0 MSS=1380 SACKPERM=1 WS=256 29080 28.703008 10.0.0.120 216.58.215.99 TCP 60 62615 → 80 [ACK] Seq=1 Ack=1 Win=1000 Len=0 It looks better than the first log.

This looks like a good TCP conversation.

I suppose that eth card is cutting packets.

Why do you think that? The above TCP conversation looks OK to me.

It cuts ARP Gratitious packets also

Can you check in xNetworkInterfaceOutput() if some packets are sent too small, i.e. less than 60 bytes? Some EMAC’s have a possibility to extend packets to a minimum of N bytes, if not there is this setting: ~~~ #define ipconfigETHERNETMINIMUMPACKET_BYTES ( 60 ) ~~~

But this problem is for different topic.

No need for a new topic. 🙂

My situation is presented on attached figure. For example PC1 give me log from post 1 and PC 2 give me log presented in post 3. Both PCs run Windows but with different hardwares. So the problem is why the PC1 cuts off some packets?

The box in the middle is probably not a hub, but an intelligent “network switch”. The task of a network switch is to separate sub-networks. Normally all ARP traffic, UDP broadcasts, and multi-cast packets will pass through. UDP ( unicast ) and TCP packets will be forwarded to their proper targets only.