On 2015-07-15 00:54:25 (-0700), Colin Percival <cperc...@freebsd.org> wrote: > In my tests, deleting these lines from pf_ioctl.c > > 3570 /* We need a proper CSUM befor we start (s. OpenBSD ip_output) */ > 3571 if ((*m)->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > 3572 in_delayed_cksum(*m); > 3573 (*m)->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > 3574 } > > unbreaks pf+TSO on EC2 instances. I'm not entirely sure why these lines > are there in the first place, which is why I didn't want to simply go in > and remove them -- but it may be that wrapping those lines in something > like "if ((csum_flags & CSUM_TSO) == 0)" would solve the problem without > breaking anything else. > I think the reason for this checksum calculation is that pf sometimes modifies the packet, so it also updates the checksum. In case of TSO (or CSUM_TCP) that doesn't actually work because the TCP checksum is the pseudo IP(6) header checksum, not the final checksum. Starting from a full checksum the update is correct however, so that's why pf works on non-TSO interfaces. It doesn't work on Xen TSO interfaces because (I assume) it expects to get the pseudo header checksum, not the full checksum. It's not entirely clear to my why it's not broken on my hardware (which claims TSO support), but perhaps Xen is more picky than actual hardware.
Adding the if (CSUM_TSO) check will improve matters, but it will still break on packets which get changed by pf (rdr/nat/...). I think the real solution is to make pf_cksum_fixup() a bit more intelligent. It should look at m->m_pkthdr.csum_flags to determine if it should touch the checksum or not. If CSUM_TCP is set we know we've got a pseudo header checksum and we shouldn't touch it unless we've modified the source or destination IP address (or length or protocol, but that's less likely). If CSUM_TCP is not set we should have a full checksum and should do the fixup as before. Actually, perhaps CSUM_DELAY_DATA is better than CSUM_TCP, because we'll have to do the same for UDP. Regards, Kristof _______________________________________________ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"