TCP Data Position Relocation Over VPN Network

[ctkian]

Hi All,

A bit of current environment info: we are using uTasker_v1.3_SP6 on MCF5223X.

Under VPN network, the TCP data send into MCF5223X has been reposition. For example, in the sender side we send "ABCDEFG" but in the MCF5223X, what we received is "ACBDEFG". We replaced MCF5223X with a PC and load with a simple TCP-receiver software and there is no problem on it. This problem only happen when the MCF5223X is put under VPN network. If VPN is remove, then the unit is working without problem.

I would like to know what would be the possible cause and advices to resolve this issues is appreciate.

Best regards,
ctkian

[mark]

Hi

Have you tried watching the TCP data using Wireshark (after VPN step so that its is pain text again)?

I would expect that the frame at this point would in fact be the same, but maybe the frame size changes since the VPN uses some protocol header space and then the receiving application is piecing the frames back together differently?

Regards

Mark

[ctkian]

Hi,

In order to troubleshoot this problem, I have put another PC (IP: 192.168.1.200) on the same subnet as the MCF5223X(IP: 192.168.1.203). Then instead of sending data to MCF5223X, the TCP data is send to PC and I captured received data using wireshark. I did not observed any suspicious data in wireshark. Kindly refer to attached file for wireshark data.

In the attached file, the actual TCP data sent happen on item 4 - '\xd0'C0A802C8001DF100AACA'\x0d'.

Best regards,
Cheng

[mark]

Hi Cheng

In the frame in question how does it get received at the M522xx? (with inverted byte content?))

Is it possible to put a check in the following locations?:
- TCP reception fnHandleTCP()
- TCP listeren - the callback receiving the event TCP_EVENT_DATA

Note that fnHandleTCP() is called only when the IP header and checksum is OK. It is passed a pointer to the data in the Ethernet input buffer (as it was received) and it checks that the TCP checksum is OK.
In the TCP listener a pointer to the data (also in the original Ethernet reception buffer is passed).

This means that the data content of the Ethernet buffer should not change on the way from reception to the lister. Also the TCP checksum is calculated and any change to the buffer content (and theoretically to the originally sent contant) should result in the frame being recognised as being corrupted - and being silently dropped.

If you are using a "TELNET-like" socket make sure that it is configured to RAW mode so that it won't be trying to do IAC interpretation (although this would only happen when 0xff is received in the data stream).

Perhaps you can identify at which step the content could change since I wouldn't expect that it can be before the TCP checksum calculation since this would cause the frame to already be dropped.

Regards

Mark

[ctkian]

Hi Mark,

Currently the checking is done on TCP listener (callback function upon receiving data on event TCP_EVENT_DATA).

I will check on fnHandleTCP section and reported back. I would like to know if fnHandleTCP data is still showing byte position shift, can I conclude that it is the TCP sender that send corrupted data into M522xx?

Besides that, I found out TCP header does include a checksum for TCP header+data validation (http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation). Can you advise me if the checksum validation is implement in uTasker and where is it implemented?

Best regards,
Cheng

[mark]

Hi Cheng

The TCP checksum is verified in fnHandleTCP() by fnCalculateTCP_checksum().
If the data content has changed during transmission it will normally be able to detect it and drop the frame (so that it will be repetaed).

Regards

Mark

[ctkian]

Hi Mark,

After verification on data received on fnHandleTCP(), there is no byte position shift as I claim on first post. Further investigation reveal that it is indeed a mistake during data collection that cause the byte shift. Thus, in the stack everything is in correct order!

Thanks again for pointing out the places for my troubleshooting.

By the way, the VPN network is not working is due to the application layer that perform a check bewteen 'TCP source IP'  against MCF522xx internal server ip settings. And this is due to the server side have 2 network card. Once the server is move into another PC with single network card, the problem is resolved.

Thanks again for your good support.