[ovs-discuss] Fwd: TCP Checksum issue on OVS 2.6.1

[John Hurley]

Further information:
The patch and test were applied to OVS 2.6 commit
tag 71e2a07ad0b694a87ce6d6b4cd218ae9a1cab6a9

---------- Forwarded message ----------
From: John Hurley <john.hurley at netronome.com>
Date: Thu, Dec 22, 2016 at 1:32 PM
Subject: Fwd: TCP Checksum issue on OVS 2.6.1
To: bugs at openvswitch.org


Hi,

Regarding the issue below.

I ran more tests and found that setting the CHECKSUM_PARTIAL flag corrupts
the checksum in non mangled NAT packets when hitting the
queue_userspace_packet() function (as reported below).
When I tried to reset the flag after the helper function call, non mangled
packets had the correct checksum but mangled FTP packets were still
incorrect.
Instead of setting the CHECKSUM_PARTIAL to avoid hitting the skb_dst on pre
kernel 4.5, I have attached a patch that gives the skb the required skb_dst
and the flags that are checked in the kernel checksum calculation.
This essentially causes the pre kernel 4.5 version to hit the same code as
post 4.5 and recalculate the layer 4 checksums in the Netfilter modules.
I have tested this and the checksums are now correct for both mangled and
non mangled NATed packet that go through the FTP helper.

Is it ok to submit this patch here? If this approach seems valid I can
prepare it for the dev email list.

Thanks,
John



---------- Forwarded message ----------
From: John Hurley <john.hurley at netronome.com>
Date: Tue, Dec 20, 2016 at 5:22 PM
Subject: TCP Checksum issue on OVS 2.6.1
To: bugs at openvswitch.org


Hi,

I am playing about with NAT in OVS 2.6.1 and have come across an issue with
TCP checksums when helpers are being used.

I have a setup of client -> OVS -> ftp server (all physical ports with no
checksum offloading enabled the network cards). OVS is running kernel
version 3.13.

I am using rules such as these for testing purposes:

 cookie=0x0, duration=121.467s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=-trk,ip,in_port=4 actions=ct(commit,table=0,nat)
 cookie=0x0, duration=121.453s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=-trk,ip,in_port=3 actions=ct(commit,table=0,nat(
src=10.0.0.5))
 cookie=0x0, duration=121.462s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=+rel+trk,in_port=4 actions=output:3
 cookie=0x0, duration=121.458s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=-rel+trk,in_port=4 actions=output:3
 cookie=0x0, duration=121.449s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=+rel+trk,in_port=3 actions=output:4
 cookie=0x0, duration=121.444s, table=0, n_packets=0, n_bytes=0,
idle_age=121, ct_state=-rel+trk,in_port=3 actions=output:4
 cookie=0x0, duration=121.440s, table=0, n_packets=0, n_bytes=0,
idle_age=121, priority=0,arp,in_port=3 actions=output:4
 cookie=0x0, duration=121.435s, table=0, n_packets=0, n_bytes=0,
idle_age=121, priority=0,arp,in_port=4 actions=output:3


This works fine and I can establish FTP connections between client and
server. However, when I introduce helper modules, I can no longer connect.
I've narrowed this down to bad TCP checksums.

Tracing through the code, the marking of the skb checksum data in the
he ovs_ct_helper (datapath/conntrack.c) seems to be the cause (only happens
in kernels < 4.6). When the packet is recirculated and upcalled to
user-space, the following code ends up corrupting the TCP checksum:

in datapath.c/queue_userspace_packet()

/* Complete checksum if needed */
if (skb->ip_summed == CHECKSUM_PARTIAL &&
   (err = skb_checksum_help(skb)))

I have verified the checksums before and after this call and it goes from
correct (taking into account the address translation) to invalid.

In this case, it is the SYN packet of the FTP connection that has the bad
checksum so there should be no payload changes involved from the helper.
The checksum is updated correctly from the Netfilter NAT code so should not
need CHECKSUM_PARTIAL set here? This will, obviously, not cover cases where
the packet is modified by the helper.

I will try to dig a bit more into this and report any further information.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161222/c748d64f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conntrack_nat_checksum.patch
Type: text/x-patch
Size: 2504 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161222/c748d64f/attachment.bin>