From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 01:23:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C86647AF; Thu, 14 Feb 2013 01:23:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCFBBFC; Thu, 14 Feb 2013 01:23:49 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id e20so839288dak.0 for ; Wed, 13 Feb 2013 17:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=+xscmwQkbocDgBUqwTzZuK4bG0dFWJ5F+Pq6AcFh9AQ=; b=mbALlj/H0wWhDybLaC9xPGA8Trm2wanS8gf9UXkZvJQPzc0M/F6MvwaqPzbdpiFckb LNyEIRLa3B1t3BrvTHig4yZUs5u0hgjcu7k3vDa9svsNMouX1+GjBX587M10lI3D1lcE dYsdE0kXPjm3bYeJZ3F25vfgmnSFHkQqH1jfgh+k9cKnlnJhvyLNRXbaDj3mIcNbj8l2 q3rXLhozMhKBa+R3+tJb5VhKo7gM93hKEoZJE551ulsraLQTs5vq5+MxsOLi69QSQKKM nf6mHcRbr6YMx+rFqPaOIfFF58SQyL6lSP9zh7U7GVIIr2VxSpN52g+5vHyOWoBI5iWO Vz8A== X-Received: by 10.66.82.163 with SMTP id j3mr69729290pay.31.1360805028753; Wed, 13 Feb 2013 17:23:48 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id f9sm87611929paz.12.2013.02.13.17.23.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 17:23:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Feb 2013 10:23:39 +0900 From: YongHyeon PYUN Date: Thu, 14 Feb 2013 10:23:39 +0900 To: Jeremy Chadwick Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214012339.GA2945@michelle.cdnetworks.com> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> <20130213220132.GA68113@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213220132.GA68113@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Eugene Grosbein , yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 14 Feb 2013 01:23:49 -0000 On Wed, Feb 13, 2013 at 02:01:32PM -0800, Jeremy Chadwick wrote: > On Wed, Feb 13, 2013 at 01:57:38PM -0800, Doug Hardie wrote: > > > > On 13 February 2013, at 02:29, Eugene Grosbein wrote: > > > > > 13.02.2013 17:25, Doug Hardie ??????????: > > >> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > >> > > >> msk0: flags=8843 metric 0 mtu 1500 > > >> options=c011b > > >> ether 00:11:2f:2a:c7:03 > > >> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > > >> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > > >> nd6 options=29 > > >> media: Ethernet autoselect (100baseTX ) > > >> status: active > > >> > > >> > > >> It sent the following packet: (data content abbreviated) > > >> > > >> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > > >> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > > >> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > > >> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > > >> > > >> > > >> The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > > > > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > > > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > > > > Thanks. Now all the packets are 1500 or under. They all are received with a SSL header. > > If disabling TSO on msk(4) fixed the issue of the remote end > dropping/ignoring the packet, that sounds like a bug in msk(4). > > Yong-Hyeon, do you have any recent msk(4) patches relating to TSO? No, I'm not aware of msk(4) related TSO issues. For some controllers, msk(4) used to touch reserved registers which in turn resulted in unexpected results. This was fixed long time ago but it would be good idea to cold-boot the box and see whether that makes any difference.