Bug in TCP client?

[m_mikula]

Hi mark,

I compile new uTasker 1.4 for freescale, and I find out some strange behaviour (I dont know if this bevaviour is also in 1.3): When I enable TIME_SERVER, the result in wireshark is quiet strange... Creation of connection is ok, data comes OK, but next server send request with FIN bit enabled, but uTasker reply only with ACK (TCP requires FIN+ACK), so the connection is still opened, and no notification cames to application... Can you please check if it's really a bug?

Code: [Select]

192.168.64.209 | 192.168.64.2   | TCP | 61264 > time [SYN] Seq=0 Win=1460 Len=0 MSS=1460
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460
192.168.64.209 | 192.168.64.2   | TCP | 61264 > time [ACK] Seq=1 Ack=1 Win=1460 Len=0
192.168.64.2   | 192.168.64.209 | TIME | TIME response
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.209 | 192.168.64.2   | TCP | 61264 > time [ACK] Seq=1 Ack=5 Win=1460 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0
192.168.64.2   | 192.168.64.209 | TCP | time > 61264 [FIN, ACK] Seq=5 Ack=1 Win=5840 Len=0Problematic is sixth line.

Thanks,
Martin

[mark]

Hi Martin

Are you using the latest CW version (CW7.1.2 Patch)?
It seems as though there is an error in the compiler which causes a very strange effect in not generating the code correctly at the line detecting a TCP close (the FIN flag). This means that the connection remains open (the same is seem with any TCP based application, eg. HTTP or FTP, etc.).
The workaround found was to modify the routine fnHandleTCP() in tcp.c as follows:

extern void fnHandleTCP(unsigned char *tcp_data, IP_PACKET *received_ip_packet, unsigned short usLen)
{
#define _WORKAROUND_CW_7_1_2
#ifdef _WORKAROUND_CW_7_1_2
    register unsigned short _usHeaderLengthAndFlags;
#endif

...

    rx_tcp_packet.usHeaderLengthAndFlags   = *tcp_data++;                // not that CW7.1.2 puts this variable at SP + 25, which is normal
    rx_tcp_packet.usHeaderLengthAndFlags <<= 8;
    rx_tcp_packet.usHeaderLengthAndFlags  |= *tcp_data++;
   
#ifdef _WORKAROUND_CW_7_1_2
    _usHeaderLengthAndFlags = rx_tcp_packet.usHeaderLengthAndFlags;      // we make a backup of this variable in a register
#endif   

...

#ifdef _WORKAROUND_CW_7_1_2
            if (_usHeaderLengthAndFlags & TCP_FLAG_FIN)                  // use the backup value from the register
#else                         
            if (rx_tcp_packet.usHeaderLengthAndFlags & TCP_FLAG_FIN)     // CW7.1.2 otherwise takes the variabel from SP + 30, which is 5 bytes from its real location and no TCP FINs are ever recognised!!
#endif



As you can see, the value rx_tcp_packet.usHeaderLengthAndFlags (which is in fact correct) is copied to a register. When the check is made it is then correct. It was found that the compiler was in fact retrieving the rx_tcp_packet.usHeaderLengthAndFlags from an offset of about 6 bytes from where it actually is and so never recognized the flag correctly.

This is strange because other checks of rx_tcp_packet.usHeaderLengthAndFlags do indeed collect the value from the correct location.

A service request was made to Freescale about this since the code otherwise works correctly with CW6.x and CW7.0 or CW7.1.1 (as well as a number of other compilers).

Give this a try and I expect that it will then work normally again.

By the way, the same also happens with the uTaskerV1.3 project when compiled with CW7.1.2 .....

Regards

Mark

[m_mikula]

Hi Mark,

Yes, it's make a sense... By the way, I solved similar problem two days later...

Code: [Select]

if ((value == 0x01) || (value == 0x02) || (value == 0x03)) - on some special location this condition was always false... But few lines later this condition works fine (or works if I changed code before or after)... I think that this bug is also depending on code around problematic lines, so in this moment I downgrade CW.

Thanks for your help...

Martin