/bugzilla3/ Bug 447 – dom0 netfilter DNAT rule that rewrites the destination port doesn't work with domU TX checksum offload
Bug 447 - dom0 netfilter DNAT rule that rewrites the destination port doesn't work with domU TX checksum offload
: dom0 netfilter DNAT rule that rewrites the destination port doesn't work with...
Status: RESOLVED FIXED
Product: Xen
Unspecified
: 3.0.1
: x86 Linux-2.6
: P2 major
Assigned To: Xen Bug List
:
:
:
  Show dependency treegraph
 
Reported: 2005-12-10 12:06 CST by Mark Goodman
Modified: 2006-03-30 16:33 CST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Goodman 2005-12-10 12:06:56 CST
A rule like this in dom0:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination
$DOMU_IP:7800

doesn't work unless in the domU, I run:

ethtool -K eth0 tx off

If the DNAT rule preserves the destination port, it works.
Comment 1 Thomas Steinacher 2005-12-31 20:08:27 CST
I can confirm this behaviour.

Below you'll find a tcpdump. Note the bad checksum in packet 4. 192.168.1.1 is
the IP of the bridge and 192.168.1.2 is the virtual machine.

I did "nc -l -p 2000" on the virtual machine and "telnet 192.168.1.2 2000" on xen0:

20:42:33.410533 IP (tos 0x10, ttl  63, id 18592, offset 0, flags [DF], proto:
TCP (6), length: 60) 192.168.1.1.42780 > 192.168.1.2.2000: S, cksum 0xc6c2
(correct), 2674143109:2674143109(0) win 5840 <mss 1460,sackOK,timestamp 35874597
0,nop,wscale 2>
20:42:33.410606 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 192.168.1.2.2000 > 192.168.1.1.42780: S, cksum 0x65a6
(correct), 967998467:967998467(0) ack 2674143110 win 5792 <mss
1460,sackOK,timestamp 568189 35874597,nop,wscale 2>
20:42:33.410942 IP (tos 0x10, ttl  63, id 18593, offset 0, flags [DF], proto:
TCP (6), length: 52) 192.168.1.1.42780 > 192.168.1.2.2000: ., cksum 0xa559
(correct), 1:1(0) ack 1 win 1460 <nop,nop,timestamp 35874597 568189>

Then I try send a packet from xenU to xen0:

20:42:34.451945 IP (tos 0x0, ttl  64, id 55161, offset 0, flags [DF], proto: TCP
(6), length: 53) 192.168.1.2.2000 > 192.168.1.1.42780: P, cksum 0x837b
(incorrect (-> 0x9af3), 1:2(1) ack 1 win 1448 <nop,nop,timestamp 568294 35874597>
20:42:34.452261 IP (tos 0x10, ttl  63, id 18594, offset 0, flags [DF], proto:
TCP (6), length: 52) 192.168.1.1.42780 > 192.168.1.2.2000: ., cksum 0xa0dd
(correct), 1:1(0) ack 2 win 1460 <nop,nop,timestamp 35875639 568294>

"ethtool -K eth0 tx off" fixes the problem.
Comment 2 Wensheng Wang 2006-02-22 19:22:57 CST
I confirm too.  see:
http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00749.html

I didn't submit bug because I didn't thought it was one.
Comment 3 Martin Schaller 2006-02-28 21:46:55 CST
Same problem occurs if you set up a bridge with a 802.1q vlan device in dom0
Comment 4 Martin Schaller 2006-02-28 21:47:56 CST
*** Bug 495 has been marked as a duplicate of this bug. ***
Comment 5 Jon Mason 2006-02-28 22:16:12 CST
http://lists.xensource.com/archives/html/xen-devel/2006-02/msg00285.html

This patch should have fixed the problem.  Are you still seeing it?
Comment 6 Uwe Jans 2006-03-10 12:40:55 CST
(In reply to comment #3)
> Same problem occurs if you set up a bridge with a 802.1q vlan device in dom0

I can confirm this behaviour with Xen3.01 and a 802.1q vlan device in dom0
This Problem is in domU.
Dom0 works if I start tcpdump on the Interface of Dom0 eth0.2
 
Comment 7 Mark Goodman 2006-03-30 16:33:51 CST
The current net-csum.patch fixes the problem for me.