From cjk32@cam.ac.uk  Mon Jul  4 13:12:23 2011
Return-Path: <cjk32@cam.ac.uk>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4A0201065679
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  4 Jul 2011 13:12:23 +0000 (UTC)
	(envelope-from cjk32@cam.ac.uk)
Received: from chacal.cjkey.org.uk (chacal.cjkey.org.uk [88.97.163.217])
	by mx1.freebsd.org (Postfix) with ESMTP id B6AFE8FC16
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  4 Jul 2011 13:12:22 +0000 (UTC)
Received: from chacal.wzl33 (localhost [127.0.0.1])
	by chacal.cjkey.org.uk (8.14.4/8.14.4) with ESMTP id p64DCKJc059831
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 4 Jul 2011 14:12:20 +0100 (BST)
	(envelope-from chris@chacal.wzl33)
Received: (from chris@localhost)
	by chacal.wzl33 (8.14.4/8.14.4/Submit) id p64DCKQD059830;
	Mon, 4 Jul 2011 14:12:20 +0100 (BST)
	(envelope-from chris)
Message-Id: <201107041312.p64DCKQD059830@chacal.wzl33>
Date: Mon, 4 Jul 2011 14:12:20 +0100 (BST)
From: Christopher Key <cjk32@cam.ac.uk>
Reply-To: Christopher Key <cjk32@cam.ac.uk>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: TSO breaks BPF packet captures with em driver
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         158635
>Category:       kern
>Synopsis:       [em] TSO breaks BPF packet captures with em driver
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>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:  Wed Jul 06 21:54:37 UTC 2011
>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:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jul 6 21:53:02 UTC 2011 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=158635 
>Unformatted:
