From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 03:44:44 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD87C1065672 for ; Sat, 11 Apr 2009 03:44:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8298FC0A for ; Sat, 11 Apr 2009 03:44:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1228427tia.3 for ; Fri, 10 Apr 2009 20:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=K6o41FTq03I4bnFVcP0P1kQmpiU8fGERQ8+pBVcFGiQ=; b=oEuk7u6nHpWWVPleyS2HxZYqVtr+IuT7zy/ACuxlOyx65259YTeE5AtjbS7sQa6crs Pc3MksD5uFO1E0tk3fMBHJWzgdwvIRmveBSrlGS2SyjUd2kH6DWbSmxJgEHWSnCad/mq MEiWxSJQz1NJQb6aKbTRkBJDB1UHRI7RqwNLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=an+1qNh8pn4TluyM1ae1aKr6qDyjh9dbbYdxv4+jCFPH+Mo3vKN7zLJiYZ+gAVYbnG aUu6gKLFBpJD4d4euaz4owjAk212m8Wn8C2E9wN8eupm2R9dlaVOrQ4y3qKrqE7q5fwC 8NRPo/pE6AaDidsTOhhtVXj8vq2h41Gmf/cGU= Received: by 10.110.103.16 with SMTP id a16mr5823571tic.7.1239421481032; Fri, 10 Apr 2009 20:44:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id 25sm3785870tif.32.2009.04.10.20.44.38 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Apr 2009 20:44:39 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 11 Apr 2009 12:46:13 +0900 From: Pyun YongHyeon Date: Sat, 11 Apr 2009 12:46:13 +0900 To: Bjoern Koenig Message-ID: <20090411034613.GA54253@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20090410101445.GL37714@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 03:44:44 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 10, 2009 at 07:14:45PM +0900, Pyun YongHyeon wrote: > On Fri, Apr 10, 2009 at 08:46:08AM +0200, Bjoern Koenig wrote: > > I wrote: > > > > > >> If you can easily reproduce the issue, can you capture stalled TCP > > >> session with tcpdump on receiving host?(Make sure to disable Rx > > >> checksum offload prior to capturing the session.) > > > > > > I transferred a 256 kiB file and these are the tcpdumps: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > > > > > Actually the transfer doesn't stall although ftp and scp told me so. It > > > becomes incredibly slow. It seems like that the chunks are too large and a > > > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > > > it works fine with TSO enabled. > > > > > > I also captured the traffic on my router: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > > > > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > > > > > I almost suppose that this is a PPPoE-related configuration issue and the > > > fxp driver is not necessarily the problem since decreasing the MTU of the > > > LAN host solves it. > > > > Hello, it's me again. :) > > > > It's not PPPoE-related. I was able to reproduce the behaviour within a > > regular LAN from host to host. I also have another symptom which denies > > the PPPoE assumption: > > > > If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll > > get the message "N bytes missing!" in the tcpdump output. For example: > > > > ifconfig fxp0 mtu 1448 # works > > ifconfig fxp0 mtu 1412 # still works > > ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) > > ifconfig fxp0 mtu 1400 # works > > ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) > > > > Hmm, I can't reproduce this. Can you send me a URL to captured > data for broken case? Ok, I've reproduced it, it seems that it happens when sender and receiver has advertised different MSS. Try attached patch and let me know how it goes on your setup. --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fxp.tso.patch" Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 190876) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -1485,7 +1485,8 @@ * checksum in the first frame driver should compute it. */ ip->ip_sum = 0; - ip->ip_len = htons(ifp->if_mtu); + ip->ip_len = htons(m->m_pkthdr.tso_segsz + (ip->ip_hl << 2) + + (tcp->th_off << 2)); tcp->th_sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, htons(IPPROTO_TCP + (tcp->th_off << 2) + m->m_pkthdr.tso_segsz)); --X1bOJ3K7DJ5YkBrT--