Date: Mon, 4 Jul 2011 14:12:20 +0100 (BST) From: Christopher Key <cjk32@cam.ac.uk> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/158635: TSO breaks BPF packet captures with em driver Message-ID: <201107041312.p64DCKQD059830@chacal.wzl33> Resent-Message-ID: <201107041320.p64DK8uZ065302@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 158635 >Category: kern >Synopsis: TSO breaks BPF packet captures with em driver >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 04 13:20:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Christopher Key >Release: FreeBSD 8.2-RC3 amd64 >Organization: >Environment: System: FreeBSD chacal.wzl33 8.2-RC3 FreeBSD 8.2-RC3 #6: Mon Feb 14 00:36:21 GMT 2011 root@chacal.wzl33:/usr/obj/usr/src/sys/CHACAL amd64 >Description: When using the em driver, any packets sent that use TCP segmentation offload (TSO) and that are captured through the Berkeley Packet Filter (BPF) will have a packet length of zero. This affects many applications, e.g. iftop shows zero upload bandwidth, tcpdump reports "IP bad-len 0". The same problem may affect network drivers other than em, but this has not been tested. >How-To-Repeat: >Fix: A trivial workaround is, ifconfig emX -tso but this clearly removes the benefits provided by TSO. There seems to be many possible solutions: 1) em should massage the data supplied to bpf to pretend one large packet was sent 2) em should massage the data supplied to bpf to supply data as it is assumed the hardware will segment it 3) BPF should detect TSO packets, and massage the data to supply a valid length 4) BPF clients should detect TSO packets and behave accordingly 5) BPF and TSO are mutually incompatible, and BPF should disable/re-enable TSO when starting/stopping a capture 6) BPF and TSO are mutually incompatible, and BPF clients should emit a warning where appropriate 7) BPS and TSO are mutually incompatible, users should know this, and nothing need be done Which of these is most appropriate seems to depend on where BPF sits, conceptually, within the stack: whether it's supposed to report what the upper layers supply to the interface driver, what actually comes out of the physical interface, or something in between; and how much effort it appropriate to make to supply the 'correct' data for this location to BPF clients. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107041312.p64DCKQD059830>